c't-Lab

Hi,

von psclab gibt es eine Überarbeitunge zur DCG-SW, die unter anderem auch die dual DAC-Variante von JCW implementiert. Da ich irgendwie gerade nicht dazu komme, irgendwas für das DCG zu machen, stelle ich einfach mal das Diff zum aktuellen Repository hier ein.

Gruß
amd-65

Hallo an alle,

dieser Patch enthält Unterstützung für
- DUAL_DAC von JCW
- Ripple-Mode (2ms Schrittweite Standard, 1ms Schrittweite mit DUAL_DAC)

Bitte vor der Compilierung in config.h: #define DUAL_DAC entsprechend Eurer Hardware einstellen.

Euer Feedback wird gerne entgegen genommen. Ich bin bloß bis Sonntag nicht da, also keine Panik, wenn nicht gleich eine Antwort kommt. (Ja, ich bin echt offline )

Die Spannungsanzeige für den Ripplemode ist noch recht "experimentell": Einerseits kann man bei kurzen Ripple-Pulsbreiten sowieso nicht richtig messen, da flackert der Wert sowieso.
Bei etwas breiteren High-Pulsen (100%) haben wir uns dann gedacht, es wäre gut, den High-Level zu messen, um eine stabile Anzeige zu bekommen. Wenn nun aber der Low-Pegel "zu breit" wird, z.B. mehrere Sekunden, dann macht es auch keinen Sinn für die Zeit quasi gar nicht zu messen.

Also ihr seht: Es ist noch Feedback nötig und wenn jemand eine gute Idee hat, dann bitte her damit !

Viele Grüße
Paul

P.S: Der Codestand hat den Status "works for me", es hatte leider bislang noch niemand Zeit, die Funktionen unabhängig zu überprüfen.

Hallo,
zu euerer neuen Version habe ich eine Frage:
CM hat ja eine neue DCG Firmware mit Ah und Wh Abfrage (wie in der EDL) veröffentlicht.
Wird es da von euch auch was geben?
Würde es gerne in die nächste JLab Version als Anzeige aufnehmen.

Gruss
Magic Roomy

Hi Volker,

hmm, ja, warum nicht? Ich hab's mir noch nicht im Detail angesehen, aber das wäre sicher mit vertretbarem Aufwand einbaubar....

Viele Grüße
Paul

Hallo Volker,
hallo DCG-Freunde,

ich hab' mich mal hingesetzt und noch einige Punkte im Vergleich zum letzten (o.g.) Stand hinzugefügt:

- Power, AmpHour und WattHour Anzeige, sowie die zugehörige Abfrage über den Bus.
Sieht gar nicht schlecht aus für diesen Schnellschuß, ein Lauf über Nacht zusammen mit der Original-FW in der EDL hat nur 0.2% bzw. 0.6% Abweichung zwischen den Modulen ergeben (wenn ich die Kalibrierungsabweichungen und den Spannungsabfall zwischen DCG und EDL herausrechne)

- Ich habe bei voll aktiviertem JLab (mit DDS, 2*DCG und EDL) festgestellt, daß sich der Bus langsam sättigt, wenn man mit 100ms Periode in JLab arbeitet. Das ergibt 24 Kommandos/Antworten in 100ms. Jetzt aber arbeitet der Kommandoparser in der DCG2/C mit 4ms Periode, d.h. er kann max. 25 Kommandos/Antworten pro 100ms ausführen bzw. an Folgemodule weiterleiten. Das führt in Kombination mit den 128 Byte Eingangspuffer zu gelegentlichen Fehlern.
Ich habe daher die Periode für die Kommandoabarbeitung mal auf 2ms heruntergesetzt, dann staut sich's im DCG nicht mehr. (Das DDS-C ist da anders gestrickt und sieht sowieso so oft wie möglich nach dem Eingangspuffer). Das geht jetzt so prima, daß sich meine beiden DCGs nicht mehr beschweren, dafür wird jetzt dem EDL am Ende der Kette manchmal der Eingangspuffer zu knapp.

Volker, ich glaube, da müssen wir wohl nochmal die Diskussion vom Frühjahr wieder aufnehmen. )

- Die Menüanzeigen für die Ripple-Features habe ich noch den Konventionen der Firmware angepaßt.

- Das Menü ist jetzt endlos und man kann sich in einer Schleife durchklicken.

Für Interessenten habe ich die Sourcen mal angehängt, da sie letztes Mal immerhin 8 mal runtergeladen wurden. Bitte meldet mal Eure Erfahrungen, außerdem hätte ich gerne gewußt,

a) welche Ideen Ihr bzgl. der Anzeigeoptionen der IST-Spannung beim Ripple habt
b) ob es Probleme mit dem Relais im Ripple-Mode gibt, z.B. Klappern etc. (CM hat in der Pascal-Firmware diesbezüglich was geändert, aber diese Maßnahme ist mir nicht völlig klar). Durchblicker oder Besitzer der DCP bitte vor

Viele Grüße
Paul

P.S: Der Codestand hat den Status "works for me", ich habe noch keine Erfahrungsberichte von anderen.
.

Hi Paul,

kurz zu den Problemen Optobus, JLab und c't Lab.
Das irgendwann eine Sättigung auf dem Bus eintreten kann hab ich mir schon von Anfang an gedacht. Ich habe auch versucht mit verschiedenen Mitteln entgegenzuarbeiten.

- Daten werden nur abgefragt, wenn die entsprechenden Moduloberflächen auf dem Bildschirm zu sehen sind => Daher gibt es die Arbeitsbereiche um das evtl. aufzuteilen.
- Über die Value Watch Konfig kann ich die abgefragten Werte weiter einschränken.
- Das Abfrageintervall ist einstellbar.

Das Abfrageintervall ist aber der problematische Teil.
Im Moment wirkt es so:
Warte n Millisekunden, dann frage alle Daten ungebremmst ab. Das ganze in einer Schleife.
=> Bei der Abfrage kommen die Datenabfragen direkt hintereinander. Da Sende- und Empfangsteil im JLab getrennt arbeiten warte ich noch nicht mal eine Antwort ab, sondern blase alle Anfragen en' block rein. Da ja die Anfragen für mehrere Module sein können, empfängt ein Modul einen Befehl für sich, während es parallel noch Anfragen für das nächste Modul weiterleiten muß.
Das es dabei zu Problemen mit vollgelaufenen Puffern kommen kann ist klar.

Was kann ich tun?

Strategie 1: Bessere Verteilung der Anfragen pro Abfrageintervall.
Da macht mir Java einen Strich durch die Rechnung.
Nach Deiner Beispielrechnung kommen 24 abgesetzte Kommandos in 100ms => etwa alle 5ms müsste ich ein Kommando absetzen. Leider arbeitet Java nicht so akkurat. Ich glaube unter Windows kann man mit diskreten Werten im 10ms Bereich arbeiten.
Ich werde es trotzdem mal probieren. Dann nehme ich das Abfrageintervall als reine Rechenhilfe um die Abstände beim Kommando Versenden zu ermitteln. Im obigen Beispiel errechne ich also eine Wartezeit von 5ms. Java wird 10ms daraus machen. => Alle Kommandos werden innerhalb 240ms verschickt und nicht der gewünschten 100ms.
Das muss ja aber nicht schlecht sein. Lieber korrekte Werte in längerer Zeit statt Fehler.

Strategie 2: Ich warte die Antworten ab. Das sollte die Situation auf dem Optobus auch entschärfen. Hier muss ich aber prüfen ob ich das einfach machen kann, oder ob es ein wenig Mehrarbeit erfordert.

Soviel erstmal dazu.

Gruss
Magic Roomy

psclab38 hat geschrieben: Ich habe daher die Periode für die Kommandoabarbeitung mal auf 2ms heruntergesetzt, dann staut sich's im DCG nicht mehr.

Das solltest Du nicht machen. Wenn ein Kommando an das Modul geht, dauert die Abarbeitung ca. 0.8 ... 1.8ms. Da in der 4ms Periode mehr gemacht wird, ist die dann komplett ausgefüllt.

Momentan bearbeitet der Parser max. 20 Zeichen oder 1 Kommando bzw. Antwort. Man könnte den Parser bei einem Kommando, was nur weitergeleitet wird, weiter schaffen lassen bis das Zeichenlimit erreicht wird. Dazu müßte man in dem Zweig, wo eine Antwort bzw. ein Kommando weitergeleitet wird, jeweils das 'break' in ein 'continue' ändern.

Gruß
amd-65

Hallo Volker,

im Prinzip sind Deine beiden vorgeschlagenen Strategien für mich in Ordnung. Hauptkriterium für mich wäre, daß es im regulären Betrieb auf dem Bus keine Datenverluste und Stauungen gibt, die schon vom Konzept her "einfach so" hingenommen werden.

Im Prinzip gefällt mir der Ansatz 2 am Besten, die Antworten abzuwarten. Das müßte man aber so hinkriegen, daß der Gesamt-Durchsatz nicht in die Knie geht, zumindest nicht dramatisch.

Das Senden der Kommandos sollte unter Berücksichtigung der Puffergröße von 128 Byte erfolgen. Allerdings sind die Antworten i. d. R. länger als die Kommandos.
Andererseits verteilen sich die Daten über die Puffer der einzelnen Module, insofern ist es schwer da eine Vorhersage zu treffen.

Ist nicht einfach zu knacken, aber uns wird schon noch was einfallen. Schau aber mal, was Dir Java da für Möglichkeiten bietet.



Hallo Hartmut,

Das solltest Du nicht machen. Wenn ein Kommando an das Modul geht, dauert die Abarbeitung ca. 0.8 ... 1.8ms. Da in der 4ms Periode mehr gemacht wird, ist die dann komplett ausgefüllt.

Mir war bei der Modifikation schon klar, daß es da eng werden kann. Damit sind die 2ms bzw. 4ms Schritte u. U. nicht mehr ganz so regelmäßig, es wird aber keine Zeit mit Warten vertrödelt. Bei meinem Test hat das aber so offensichtlich nichts ausgemacht. Es ist natürlich nicht "schön".

Momentan bearbeitet der Parser max. 20 Zeichen oder 1 Kommando bzw. Antwort.

So hab ich das auch verstanden.

Man könnte den Parser bei einem Kommando, was nur weitergeleitet wird, weiter schaffen lassen bis das Zeichenlimit erreicht wird.

Du hast natürlich Recht, daß man im Parser den Durchsatz erhöhen kann.
Ist wahrscheinlich die elegantere und wirklich die "schönere" Lösung. Ich werd's mir mal ansehen.

Viele Grüße
Paul

Hallo DCG-C -Freunde,

ich habe Hartmuts Idee bzgl. der Erhöhung des Kommandodurchsatzes aufgegriffen und eingebaut (und meine wieder ausgebaut), die Sourcen findet ihr im Anhang. Rein äußerlich verändert sich freilich erst mal nix, nur ist die DCG-C weiterhin nicht mehr das langsamste Modul in der Kette

Irgend ein Feedback, ob was geht oder nicht geht? s. o.

Viele Grüße
Paul