Neue Firmware DDS-C RC0

[psclab38]

Hi, das Problem geht nicht auf Paul zurück, sondern auf die alten Implementierungen von Thoralt und mir. Es gab hier das Problem, zu dem alten BST-Befehl von cm abwärts kompatibel zu bleiben. BST=1 hat eine Doppelfunktion und ist nicht primär für das Einschalten des Burst gedacht gewesen. Wenn ich mich recht erinnere, kann/konnte die Pascal Firmware nur gleiche BurstOn-Zeiten und BurstOff-Zeiten. Dieses Verhalten ist auch weiterhin gültig, wenn BST > 1 gesetzt wurde. BST = 1 erlaubt unterschiedliche ON/OFF-Zeiten und nutzt 10ms/10ms als Default (auch abwärtskompatibel). Damit wurde der Code oft mit einer Abfrage BST > 1 versehen.
So wie es aussieht, dummerweise auch, um zu bemerken, dass der Burst über UART abgeschaltet wurde. Ein >=1 anstelle von >1 in main.c an dieser Stelle sollte den Fehler fixen. Ich habe Paul das wohl nie erzählt und werde mich mit ihm einigen, wer das fixed.

Hallo Jörg,

ich kann den Fehler schon ausbauen. Ich frag' mich nur grade, ob der Codestand auf CVS verwendbar ist. Ihr habt doch da vor einiger Zeit komprimiert etc. Kann ich das verwenden (mit anderen Worten: ist das stabil?), oder muß ich interimsweise meinen alten Stand vom Januar hernehmen? Wenn Du die betreffende Codezeile schon gefunden hast, dann wäre mir ein Tipp ganz recht.

Ich glaube, er muss zum flashen der Testversion nicht das Gehäuse aufschrauben. Bei mir kostet das immer eine gewisse Überwindung.

Bei meinen Modulen hängen die isp-Anschlüsse mit Verlängerungen aus dem Gehäuse. Da ist das kein allzu großes Problem. Aber es wäre nett, wenn Du Dich dann irgendwann doch nochmal wegen dem DCG2-Test "überwinden" könntest.

@Kadun: Danke für Dein postives Feedback und die Fehlermeldung!

Viele Grüße
Paul

[kadun]

Hi Wikeltus
Entschuldigung daß ich mich schon wieder melde, aber man soll ja beta-testen....
Mir sind bei der Abfrage von IDN und STR (zum Beispiel 1:254? und 1:254? -Meine DDS hat Adresse1-) per Terminalprogramm oder Labview Unterschiede zu den anderen ct-Lab Modulen mit CM-Pascal Firmware aufgefallen.

Bei der Abfrage von IDN mit der C-Firmware werden 2 Werte zurückgegeben:
#1:254=1.0beta [DDS C.....]
#1:255=0 [OK]
Bei der Abfrage von STR mit der C-Firmware werden ebenfalls 2 Werte zurückgegeben:
#1:255=0 [OK]
#1:255=0 [OK]

Bei der Abfrage von IDN und STR bei meinen anderen ctLab-Modulen mit der Pascal-Firmware wird -wie ich erwartet habe-jeweils nur 1 Wert zurückgegeben.

Ist dieses Verhalten beabsichtigt?

Im Voraus vielen Dank für Eure Mühe
Gruß kadun

[psclab38]

Entschuldigung daß ich mich schon wieder melde, aber man soll ja beta-testen....
Mir sind bei der Abfrage von IDN und STR (zum Beispiel 1:254? und 1:254? -Meine DDS hat Adresse1-) per Terminalprogramm oder Labview Unterschiede zu den anderen ct-Lab Modulen mit CM-Pascal Firmware aufgefallen.

Bei der Abfrage von IDN mit der C-Firmware werden 2 Werte zurückgegeben:
#1:254=1.0beta [DDS C.....]
#1:255=0 [OK]
Bei der Abfrage von STR mit der C-Firmware werden ebenfalls 2 Werte zurückgegeben:
#1:255=0 [OK]
#1:255=0 [OK]

Bei der Abfrage von IDN und STR bei meinen anderen ctLab-Modulen mit der Pascal-Firmware wird -wie ich erwartet habe-jeweils nur 1 Wert zurückgegeben.

Ist dieses Verhalten beabsichtigt?

Hallo Kadun,

prima, daß Du testest; kein Problem.

Zu Deiner Frage: Wenn ich das Modul einschalte und die Anfrage schicke "1:IDN?", dann bekomme ich genau eine Zeile zur Antwort.
Dto für STR. Gibt es eine Vorgeschichte zu dem Verhalten, das du beschreibst?

Noch eine Rückfrage zu dem von Dir beschriebenen Problem mit 1:BST=1 und 1:BST=0. Ich hab's heute abend ausprobiert und kann es leider nicht nachvollziehen, weder mit dem aktuellen Codestand noch mit dem alten Hexfile vom Januar.

Ich bin nur beim Rumprobieren auf ein sehr merkwürdiges Verhalten gestoßen, das sich aber nicht mit Deiner Beschreibung deckt. Die Umschaltung auf Burst-On wird da erst nach sehr langer Verzögerung vollzogen. Kannst Du einfach mal warten, ob das bei Dir ähnlich irgendwann von selbst kommt?

Kannst Du bitte auch genau angeben, was Du nach dem Einschalten machst, und auch welche Werte Du für Burst-On und Burst-Off eingestellt hast. Diese beiden Werte kann man auch mit 30 bzw. BSP und 31 bzw. BSB abfragen, da ist das syntax.xls aus dem CVS noch falsch!

Viele Grüße
Paul

[psclab38]

Hallo Kadun und alle DDS-Fans,

ich habe den Bug beim Burst- Ein-und Ausschalten, den ich gestern selbst nachstellen konnte, ausgebaut. Kein Bug ohne Feature: Es gibt jetzt auf dem Sync-Anschluß auch im Burst-Modus ein Signal, dann kann man besser drauf triggern.

Ein paar Kleinigkeiten habe ich noch gefunden und auch gleich behoben.
Ein Wort zum Status: Es gibt derzeit im Code eine offene Baustelle im Code, eine interne Umstellung u.a. bei der Offsetspannung. Die Einstellung per Encoder geht, aber per Labbus werden derzeit Millivolt (integer) und nicht Volt(float) erwartet. Daher geht evtl. eine Fernsteuerung mit JLab u.a. für den Offset nicht korrekt. Das gleiche gilt für Logik-High und Logik-Lowpegel. Das ist aber alles auf der Todoliste.

Hier gibt's wieder Hex-Futter zum Ausprobieren (1.0RC0a):
http://dcg-firmware.cvs.sourceforge.net ... -firmware/

Die Quellen sind auch passend eingecheckt.

Viele Grüße
Paul

[kadun]

Hallo pcslab38 und alle anderen DDS Fans,
Vielen Dank für die schnelle Antwort.
Bei mir hat es etwas länger gedauert, Bill G. hat mich beschäftigt und der Computer zickte.

Meine DDS ist gegenwärtig ohne Effektivwertmodul, aber das ist hier wohl unerheblich. Das Problem mit den Doppelausgaben (Channel 255 der DDS) habe ich immer noch.

Im Hyperterm benutze ich 38400-8-N-1 sowie lokales Echo. Am Zeilenende (und bei Betätigung der Return-Taste) wird LF ausgegeben, also alles ganz normal. Ebenso die Einstellungen in Labview.

Bestückung meines ctLab ADR0: ADA
ADR1:DDS (elektrisch am Ende der Kette)
ADR2: DSG (elektrisch in der Mitte der Kette)

Wenn ich die Kette beim DDS beende (Stecken von 2 Jumpern) verhält sich das ctLab ganz normal, keine unerwünschten zusätzlichen Ausgaben, die IFP-Baugruppe ist daher wohl okay.

Wenn ich die Kette wieder bis zum DDS laufen lasse ergibt sich folgendes:

0:0 ; Syntaxfehler

#0:255=4 [CMDERR] ; wie zu erwarten
#1:255=0 [OK] ; unerwünschte Ausgabe
--------------------------------------------------------
0:1? ; Abfrage channel 1 der ADA

#0:1= 3.5700 ; wie zu erwarten
#1:255=0 [OK] ; unerwünschte Ausgabe
----------------------------------------------------------
1:0? ; Abfrage der Frequenz der DDS
#1:0= 1597.000 ; wie zu erwarten
#1:255=0 [OK] ; unerwünschte Ausgabe
----------------------------------------------------------
1:0 ; „?“ fehlt, Syntax zweifelhaft
#1:0= 1597.000 ; denkt sich die DDS das „?“ dazu?
-----------------------------------------------------------
1:0?? ; Abfrage der Frequenz der DDS, zweites „?“ wird ignoriert
#1:0= 1597.000 ; wie zu erwarten?
#1:255=0 [OK] ; unerwünschte Ausgabe
----------------------------------------------------------
1:0=5000! ;Frequenzvorgabe
#1:255=0 [OK] ; unerwünschte Ausgabe
#1:255=0 [OK] ; unerwünschte Ausgabe
-------------------------------------------------------------
1:0? ; Abfrage der Frequenz der DDS
#1:0= 5000.000 ; wie zu erwarten
#1:255=0 [OK] ; unerwünschte Ausgabe
---------------------------------------------------------------
1:30?
#1:30 = 20 ;BSP
#1:255=0 [OK] ; unerwünschte Ausgabe
--------------------------------------------------------------
1:31?
#1:30 = 1 ; BSB
#1:255=0 [OK] ; unerwünschte Ausgabe
--------------------------------------------------------------
Benutze ich das Demo-Programm IDENT.VI antwortet die DDS ebenfalls mit 2 Ausgaben (channel 254 und 255)

Eine deutliche Verzögerung beim Umschalten auf Burst habe ich nicht beobachtet, aber ich habe ja nauch keinen Vergleichsmaßstab.

In der Hoffnung nicht allzu viel Verwirrung gestiftet zu haben und mit freundlichen Grüßen
kadun

[psclab38]

Hallo Kadun,

Meine DDS ist gegenwärtig ohne Effektivwertmodul, aber das ist hier wohl unerheblich.

Das sollte egal sein.

Das Problem mit den Doppelausgaben (Channel 255 der DDS) habe ich immer noch.

Heißt das, daß das Problem mit dem Burst ein- und ausschalten weg ist?

Eine deutliche Verzögerung beim Umschalten auf Burst habe ich nicht beobachtet, aber ich habe ja nauch keinen Vergleichsmaßstab.

Das waren etliche Sekunden, bis irgendein Ereignis dann schlußendlich doch dazu geführt hat, daß die Variablen alle frisch an die Interruptroutine weitergereicht wurden.

Im Hyperterm benutze ich 38400-8-N-1 sowie lokales Echo. Am Zeilenende (und bei Betätigung der Return-Taste) wird LF ausgegeben, also alles ganz normal. Ebenso die Einstellungen in Labview.

Bestückung meines ctLab ADR0: ADA
ADR1:DDS (elektrisch am Ende der Kette)
ADR2: DSG (elektrisch in der Mitte der Kette)

Wenn ich die Kette beim DDS beende (Stecken von 2 Jumpern) verhält sich das ctLab ganz normal, keine unerwünschten zusätzlichen Ausgaben, die IFP-Baugruppe ist daher wohl okay.

DSG? Meinst Du das DCG?

ADR0: ADA
ADR2: >DCG< (elektrisch in der Mitte der Kette)
ADR1: DDS (elektrisch am Ende der Kette)


Und damit :
Wenn ich die Kette beim >DCG< beende (Stecken von 2 Jumpern) verhält sich das ctLab ganz normal, keine unerwünschten zusätzlichen Ausgaben, die IFP-Baugruppe ist daher wohl okay.

Welche Firmware ist in dem DCG drin? Pascal oder C?
Schick' doch mal bitte die Antwort auf:
*:idn?

----------------------------------------------------------
1:0 ; „?“ fehlt, Syntax zweifelhaft
#1:0= 1597.000 ; denkt sich die DDS das „?“ dazu?
-----------------------------------------------------------

Ja! Das Kriterium ist das Gleichheitszeichen. Wenn es nicht vorhanden ist, dann wird's 'ne Abfrage, sonst eine Zuweisung. Ist schon in der Ur-Implementierung des DCG-C drin gewesen, hat sich bislang niemand "beschwert". Vereinfacht das Tippen im Terminalprogramm, wenn man's weiß


Nochmal die Frage: Passiert das "#1:255=0 [OK]" auch wenn Du die Module frisch eingeschaltet hast und nur mit dem Hyperterm klimperst?
Und: was ist, wenn das DDS ganz alleine an der IFP hängt?
Verwendest Du das Hexfile, das ich gestern hochgeladen habe oder compilierst Du selbst?

Ganz ehrlich, ich hab noch keinen blassen Schimmer, was für einen Effekt Du da beobachtest. Da muß ich wohl nochmal drüber brüten.

[EDIT1]
Mir kömmt es so vor, daß es eventuell ein CR/LF-Problem ist.
[/EDIT1]

[EDIT2]
Mögliche Erklärung: Die C-Firmwaren akzeptieren als Kommandoanschluß "CR", "LF oder "CRLF". Wenn so ein Kommandoabschluß an ein Modul mit C-Firmware geht, ohne daß ein Kommando codiert ist, dann gibt es "#1:255=0 [OK]". Ob das nun ein Bug oder (eher) ein Feature ist, kann ich grad nicht sagen. Merkwürdig ist nur, daß die DDS eigentlich das letzte Modul in Deiner Kette ist, daher auch meine Frage nach der Firmware in ADR2 (DCG?).
Da Du das Problem scheinbar auch in Labview siehst, hat das aber wohl nix mit der Einstellung in Hyperterm zu tun.
[/EDIT2]

Viele Grüße
Paul

[kadun]

Hallo Paul

Vielen Dank für Deine schnelle Antwort.

Du hast recht, die Baugruppe mit der Adresse 2 in meinem ctLab ist eine DCG, das war ein Tippfehler von mir, sorry.

Bis auf die DDS habe ich bei meinen Baugruppen die jeweils aktuelle Pascal-Firmware von cm. verwendet.

Es ist mir offenbar erst heute gelungen, die neueste DDS Firmware 0.1RC0a (Version 1.9 vom 13.10.2009) korrekt zu flashen (trau keinem über 65!), und damit sind meine Probleme beim Umschalten von BST=1 auf BST=0 komplett beseitigt. Vielen Dank!

Das Problem mit der unerwünschten Ausgabe von „#1:255=0 [OK]“ ist mit der neuen Firmware auf meiner DDS nun ebenfalls gelöst!

Bei den Abfragen kann man ein „?“ nach der Abfrage setzen oder es lassen; bei korrekter Syntax (gleichgültig ob man die mnenomics oder die sub.-channel # verwendet) erhält man nur eine 1-zeilige Antwort mit der gewünschten Auskunft. Es spielt auch keine Rolle, wo sich die DDS in der Kette befindet oder ob sie allein an der IFP angeschlossen ist. Bei Syntaxfehlern wird die Fehlernummer im sub.-channel 255 angegeben. Das Verhalten bei Labview ist identisch. Meine Baugruppen mit Pascal-Firmware verhalten sich genau so. Alles Bestens.

Bei den Zuweisungen ist das Verhalten unterschiedlich, je nachdem, ob man am Ende der Befehls ein „!“ angibt oder nicht. Ohne „!“ gibt es bei korrekter Syntax keinen Rückgabewert, andernfalls wird die Fehlernummer in sub.-channel 255 zurück¬gegeben. Mit „!“ wird stets der Inhalt von sub.-channel 255 zurückgegeben, auch dieses entspricht dem Verhalten meiner Baugruppen mit Pascal-Firmware. Ebenfalls alles bestens.

Nochmals vielen Dank und ein dickes Lob für Deine Hilfe.

Mit freundlichen Grüßen
kadun

[psclab38]

Es ist mir offenbar erst heute gelungen, die neueste DDS Firmware 0.1RC0a (Version 1.9 vom 13.10.2009) korrekt zu flashen (trau keinem über 65!), und damit sind meine Probleme beim Umschalten von BST=1 auf BST=0 komplett beseitigt. Vielen Dank!

Prima. Mit ein wenig Übung geht's in Zukunft noch besser!

Das Problem mit der unerwünschten Ausgabe von „#1:255=0 [OK]“ ist mit der neuen Firmware auf meiner DDS nun ebenfalls gelöst!

Sehr schön. Ich wundere mich trotzdem, was Du da reingeladen hattest. Es hat ja irgendwie funktioniert, aber scheinbar doch nicht so richtig.

Bei den Abfragen kann man ein „?“ nach der Abfrage setzen oder es lassen; bei korrekter Syntax (gleichgültig ob man die mnenomics oder die sub.-channel # verwendet) erhält man nur eine 1-zeilige Antwort mit der gewünschten Auskunft. Es spielt auch keine Rolle, wo sich die DDS in der Kette befindet oder ob sie allein an der IFP angeschlossen ist. Bei Syntaxfehlern wird die Fehlernummer im sub.-channel 255 angegeben. Das Verhalten bei Labview ist identisch. Meine Baugruppen mit Pascal-Firmware verhalten sich genau so. Alles Bestens.

So soll es sein.

Bei den Zuweisungen ist das Verhalten unterschiedlich, je nachdem, ob man am Ende der Befehls ein „!“ angibt oder nicht. Ohne „!“ gibt es bei korrekter Syntax keinen Rückgabewert, andernfalls wird die Fehlernummer in sub.-channel 255 zurück¬gegeben. Mit „!“ wird stets der Inhalt von sub.-channel 255 zurückgegeben, auch dieses entspricht dem Verhalten meiner Baugruppen mit Pascal-Firmware. Ebenfalls alles bestens.

Das Verhalten mit dem "!" ist auch von CM offiziell so dokumentiert.

Nochmals vielen Dank und ein dickes Lob für Deine Hilfe.

Danke! Gerne geschehen und wie Du siehst, hab ich allein beim "Drüberschauen" ein paar andere Fehler gefunden und auch gleich ein neues Feature eingebaut. Wie erwähnt: es gibt jetzt auch beim Burst auf dem Sync-Ausgang ein Signal. Das war vorher nur beim Sweep verfügbar.

An dem Todo mit den Burstparametern bin ich dran. Kostet leider wieder ein wenig Platz (ist aber dafür allgemeingültig). Thoralt wird's wohl nicht so toll finden.

[UPDATE]
Ok, der Code ist hochgeladen, das neue Hexfile auch (RC0b). Wenn's noch Probleme geben sollte, dann meldet Euch bitte.
[/UPDATE]

Viele Grüße
Paul

[thoralt]

Hallöchen,

[...] Thoralt wird's wohl nicht so toll finden.

na, wieviele Bytes hast Du denn gekillt? *g*

Viele Grüße
Thoralt

PS: Mein Einzug ins neue Haus ist in ziemlich genau 14 Tagen. Danach geht es aufwärts und ich werde mich auch wieder dem DDS widmen, denn die Sache mit dem PWM-SIgnal ist immer noch offen...

[psclab38]

Hi Thoralt,

na, wieviele Bytes hast Du denn gekillt? *g*

Ich hab den Zettel schon weggeworfen, aber so 200 Bytes für die Konvertierung in beiden Richtungen waren es dann schon so etwa. Ich hab mal kurz gebrütet und bin dann auf eine simple Lösung in dds-parser gekommen. Ist auch wieder leicht rückgängig zu machen, wenn Dir was Besseres einfällt.
[EDIT]
Ich hab nochmal eben die Hexfiles verglichen: 116 Bytes. Also gar nicht soo schlimm
[/EDIT]

PS: Mein Einzug ins neue Haus ist in ziemlich genau 14 Tagen. Danach geht es aufwärts und ich werde mich auch wieder dem DDS widmen, denn die Sache mit dem PWM-SIgnal ist immer noch offen...

Ja, der Einzug ist ja quasi genau rechtzeitig zum "Wintereinbruch". Deine Vorbereitungen für die PWM-option habe ich schon gesehen (nur einstweilen für das Hexfile abgeschaltet). Du mußt uns dann nur noch irgendwann verraten, welcher zusätzliche Draht zu ziehen ist.

Da fällt mir ein, bei JLab 2.5 wird der Wert für den Offset nicht automatisch upgedated, wenn die Werteüberwachung eingeschaltet ist und ich am Encoder am Modul drehe. Ist mir beim Debuggen aufgefallen. Da fehlt die regelmäßige Abfrage für Parameter 20, JLab macht das nach dem Starten nur genau einmal. Irgendwie kann ich auch bei der Werteüberwachung konfigurieren, was ich will, es werden immer alle Parameter (außer eben 20) abgefragt, ist mein Eindruck. Das können wir ja mal bei Gelegenheit vertiefen, wenn Volker Zeit hat.

Viele Grüße
Paul