DCG Firmware Update

[Rainer]

Hi zusammen,

nachdem ich endlich mal wieder etwas Zeit habe, wollte ich die Firmware in meinem DCG mal aktualisieren. Ich habe noch eine ältere Version von CM drauf, würde aber gerne auf die neue DCG2-C Variante mit Arbitrary Funktion umstellen.
Wenn ich das richtig sehe, dann liegt der aktuelle C-Quellcode für das DCG hier. Leider gibt es dot keine vorcompilierte Hex Files, weshalb ich vermute, dass ich mir erst die AVR Toolchain installieren müsste. Ich arbeite zwar auch mit Mikrocontrollern, aber eben nicht mit den AVR. Deshalb müsste ich mich dann erst mal in die Toolchain reinlesen, bevor ich die Firmware vermutlich korrekt compilieren kann.

Vielleicht gibt es ja Jemanden der dies schon getan hat und mir die compilierten Hex Files geben kann?
Dann wäre noch interessant zu wissen, ob ich die DCG2-C Firmware mit den original VI's von CM kalibrieren kann nach dem ersten Start?

Ciao,
Rainer

[psclab38]

Vielleicht gibt es ja Jemanden der dies schon getan hat und mir die compilierten Hex Files geben kann?
Dann wäre noch interessant zu wissen, ob ich die DCG2-C Firmware mit den original VI's von CM kalibrieren kann nach dem ersten Start?

Hi Rainer,

freut mich, daß sich noch jemand für die Arbitrary-Funktion interessiert

Die vorcompilierten Hex-Files liegen alle hier http://dcg-firmware.cvs.sourceforge.net ... -firmware/. Wenn Du die Standardhardware für's DCG hast, dann ist dieses das richtige File: DCG2Firmware-m32_Std.hex

Die alten Kalibrierdaten kannst Du mit dem BackupRestore.vi aus der Pascal-FW auslesen und dann später in die DCG-Firmware zurückspielen. Die Parameter sind in dieser Richtung kompatibel. Andersrum geht's nicht und auch das EEP-File ist NICHTkompatibel.

Grüße
Paul

PS: Die C-Firmwaren sind auch kompatibel mit den anderen Original-Kalibrier-vi's ...

[Rainer]

Danke für die schnelle Antwort.

Wenn ich das richtig sehe, dann sind die compilierten Hex Files 7 Monate alt und die letzte Änderung im DCG2 Zweig ist gerade mal 4 Monate alt. Es scheint dadurch nur das neue Feature "introduced bus subch 16+17 for mean values of voltage and current" zu fehlen. Aber ich werde auf jeden Fall gleich mal die vorcompilierte Version ausprobieren.

Wenn ich die neue Firmware flashen will per Ponyprog, dann dürfte doch das Skript von hier noch funktionieren, wenn ich den Eintrag für die EEP Datei entferne, oder?

Gibt es eigentlich irgendwo eine grobe Übersicht, welche Unterschiede die DCG-C Firmware im Vergleich zu CM's Pascal Firmware hat?

Ciao,
Rainer

[psclab38]

Hi Rainer,

Wenn ich das richtig sehe, dann sind die compilierten Hex Files 7 Monate alt und die letzte Änderung im DCG2 Zweig ist gerade mal 4 Monate alt. Es scheint dadurch nur das neue Feature "introduced bus subch 16+17 for mean values of voltage and current" zu fehlen.

Touché! Ich habe die rumliegenden Änderungen grade eingecheckt und auch neue Hexfiles hochgeladen.

Aber ich werde auf jeden Fall gleich mal die vorcompilierte Version ausprobieren.

Wenn's Probleme gibt, bitte melden.

Wenn ich die neue Firmware flashen will per Ponyprog, dann dürfte doch das Skript von hier noch funktionieren, wenn ich den Eintrag für die EEP Datei entferne, oder?

Da kann ich Dir leider nicht helfen. Ponyprog verwende ich schon lange nicht mehr.

Gibt es eigentlich irgendwo eine grobe Übersicht, welche Unterschiede die DCG-C Firmware im Vergleich zu CM's Pascal Firmware hat?

Sollte man mal zusammenstellen. Das Changelog.txt gibt einstweilen mal Anhaltspunkte.

Grüße
Paul

[Rainer]

Also ich habe ein kleines Problem mit der DCG-C Firmware.

Nachdem ich jetzt beide DCG mit der DCG-C Firmware geflasht habe, funktioniert die Opto-Bus Kommunikation nicht mehr richtig. Ich habe an CH0 eine ADA Karte und auf CH1 und 2 jeweils ein DCG. Ich bekomme nun über die serielle Schnittstelle immer vom DCG an CH1 die Meldung OVRFLW, welche wohl auf einen internes Bufferproblem der Firmware hindeutet. Mit *:IDN? bekomme ich nur noch DCG1+2 gemeldet (+OVRFLW), aber nicht mehr die ADA Karte.
Wenn ich die beiden DCG in der Reihenfolge der Channels vertausche wird das Problem dann vom anderen DCG gemeldet. Entferne ich ein DCG, so dass ich nur noch ADA + 1 DCG dran habe kann ich auf die ADA Karte immer noch nicht zugreifen und das DCG meldet immer noch OVRFLW. Nur wenn die ADA Karte alleine dran ist kann ich wieder drauf zugreifen. Die Bedienung der DCG per Panel funktioniert weiterhin.
Ein direktes Identifizieren der ADA Karte per 0:IDN? liefert mir eine Antwort von DCG auf CH1 bezüglich OVRFLW zurück.

Anscheinend betrifft dies nur den IDN Befehl, da ich auf die ADA Karte mit z.B. 0:20? zugreifen kann und auch die Rückmeldung bekomme. Mit der original Firmware von cm funktioniert der Opto-Bus aller drei DCG problemlos zusammen.

Ich hoffe ich habe das Problem gut genug beschrieben. Leider kann ich mit der DCG-C Firmware nun nur noch per Panel bedienen und kein JLab oder Labview mehr benutzen.

Ciao,
Rainer

[psclab38]

Also ich habe ein kleines Problem mit der DCG-C Firmware.

Nachdem ich jetzt beide DCG mit der DCG-C Firmware geflasht habe, funktioniert die Opto-Bus Kommunikation nicht mehr richtig. Ich habe an CH0 eine ADA Karte und auf CH1 und 2 jeweils ein DCG. Ich bekomme nun über die serielle Schnittstelle immer vom DCG an CH1 die Meldung OVRFLW, welche wohl auf einen internes Bufferproblem der Firmware hindeutet. Mit *:IDN? bekomme ich nur noch DCG1+2 gemeldet (+OVRFLW), aber nicht mehr die ADA Karte.
Wenn ich die beiden DCG in der Reihenfolge der Channels vertausche wird das Problem dann vom anderen DCG gemeldet. Entferne ich ein DCG, so dass ich nur noch ADA + 1 DCG dran habe kann ich auf die ADA Karte immer noch nicht zugreifen und das DCG meldet immer noch OVRFLW. Nur wenn die ADA Karte alleine dran ist kann ich wieder drauf zugreifen. Die Bedienung der DCG per Panel funktioniert weiterhin.
Ein direktes Identifizieren der ADA Karte per 0:IDN? liefert mir eine Antwort von DCG auf CH1 bezüglich OVRFLW zurück.

Anscheinend betrifft dies nur den IDN Befehl, da ich auf die ADA Karte mit z.B. 0:20? zugreifen kann und auch die Rückmeldung bekomme. Mit der original Firmware von cm funktioniert der Opto-Bus aller drei DCG problemlos zusammen.

Ich hoffe ich habe das Problem gut genug beschrieben. Leider kann ich mit der DCG-C Firmware nun nur noch per Panel bedienen und kein JLab oder Labview mehr benutzen.

Ciao,
Rainer

Hi Rainer,

ich glaube, das Problem hat mit dem langen IDN-String zu tun, den die ADA-Firmware schickt. Der wird von der Original-Pascal-FW nachfolgender Module einfach abgeschnitten, wenn ich mich recht erinnere, ohne Kommentar. Die C-Firmwaren weisen halt auf den Umstand hin, daß es da einen Überlauf gegeben hat.

Das Problem sollte sich auch nur auf den IDN-String beschränken, sonst sollten die DCG-Module ganz brav über den Bus ansprechen lassen, auch wenn sie hinter der ADA hängen.

Der Vollständigkeit halber: poste doch bitte mal die IDN-Anworten von Deinen Modulen, bei ADA halt, wenn sie allein am Bus oder am Ende hängt.

Im Prinzip sollte die ADA mit dem langen IDN-String (also mit vielen gesteckten Modulen) physikalisch am Ende des Busses hängen, dabei kann die Adresse aber gerne bei 0 bleiben. Dann sollten auch Labview/JLab alle Module finden.

Gruß
Paul

[Rainer]

Hi,

danke für die schnelle Antwort.

Der Identifikationsstring des ADA ist wirklich ziemlich lang:

#0:254=1.732 [ADA by CM/c't 04/2007; I/O-Cards: DA16 AD16 IO32 LCD ]

Im Gegensatz zu den beiden DCG:

#1:254=0.4 [DCG2 by HB + PSC]
#2:254=0.4 [DCG2 by HB + PSC]

Momentan sind die Karten am Bus in der gleichen Reihenfolge wie die Kanalnummern angeordnet. Die physische Verbindung so zu ändern, so dass das ADA am Ende hängt würde zwar gehen, ist für mich aber unpraktisch. Ich habe IFP und ADA in einem 19" Rack und die beiden DCG in einem zweiten 19" Rack drin. Wenn ich das nun neu verkabel, dann müsste ich zwei anstatt nur einer Opto-Bus Leitung zwischen den beiden Racks verlegen.
Ganz abgesehen davon, dass das nur ein Hardware Bugfix für ein Problem in der Firmware wäre. Da fände ich es doch besser, wenn man das Problem an der Wurzel, also in der Firmware angehen würde, als an der Hardware, wo eigentlich gar kein Problem vorhanden ist.
Falls momentan aber keiner Zeit hat sich das Problem in der Firmware anzuschauen würde ich eben die Verkabelung solange ändern.

Ciao,
Rainer

Ciao,
Rainer

[psclab38]

Ganz abgesehen davon, dass das nur ein Hardware Bugfix für ein Problem in der Firmware wäre. Da fände ich es doch besser, wenn man das Problem an der Wurzel, also in der Firmware angehen würde, als an der Hardware, wo eigentlich gar kein Problem vorhanden ist.
Falls momentan aber keiner Zeit hat sich das Problem in der Firmware anzuschauen würde ich eben die Verkabelung solange ändern.

Hi Rainer,
IHMO ist der ADA-Antwortstring einfach zu lang, d.h. größer als 63 Bytes. Daher verhalten sich die C-Firmwaren in diesem Punkt korrekt und geben eine entsprechene Meldung aus.

Wenn ich mich recht entsinne, dann hatten wir das vor mehreren Jahren schon mal andiskutiert und eine Kürzung des IDN-Strings in der Pascal-ADA-Firmware angeregt. Dazu gibt es seit 2007 ein offizielles Ticket
siehe hier: http://www.heise.de/ct/projekte/machmit/ctlab/ticket/63

Das Problem wurde in der neuesten ADA-Version 1.742 wohl nicht gefixt. Der String "IO-Cards" taucht auch da noch im Quellcode auf.

Unter dem angegebenen Link beschreibt Ompf aber einen Patch für das Hexfile, der 11 Zeichen spart und dann sollte auch der String deiner ADA kurz genug sein.

Ich sehe erst mal keinen Grund, an den C-Firmwaren etwas zu ändern.

Gruß
Paul

[Rainer]

Das Problem wurde in der neuesten ADA-Version 1.742 so wie vorgeschlagen gefixt. Damit sollte auch der String Deiner Konfiguration kurz genug sein. Warum verwendest Du nicht die?
Ich sehe erst mal keinen Grund, an den C-Firmwaren etwas zu ändern.

Hi Paul,

da hast du natürlich recht. Ich habe an der ADA Firmware schon ewig nichts mehr aktualisiert und momentan nur am DCG herumgebastelt. Vieleicht sollte ich erst mal mein ADA aktualisieren und dann noch mal schauen. Danke für den Hinweis auf die neuere ADA Firmware.
Ich werde es morgen mal ausprobieren.

Ciao,
Rainer

[psclab38]

Ich werde es morgen mal ausprobieren.

Ich mußte mich korrigieren, siehe mein Posting oben; das hat sich jetzt gekreuzt. Ich denke, auch in der 1.742 ist das Problem noch drin.

[Rainer]

Also ich habe eben die letzte ADA-C Firmware V1.742 geflasht und siehe da, der IDN String ist deutlich kürzer und alle drei Karten melden sich wieder.

#0:254=1.742 [ADA by CM/c't 04/2007; DA16 AD16 IO32 LCD ]

Ich brauche also keine Bytes im Hexfile auszutauschen oder dergleichen.

Somit hat sich dieses Problem zumindest schon mal erledigt. Bleibt noch das andere, aber das werde ich im dazugehörigen Thread weiter besprechen.

Ciao,
Rainer