DCG und Arbitrary-Funktion

[psclab38]

Bitte zahlreich ausprobieren und Erfahrungen hier posten.

Na, da werden die meisten wohl auf dem Karneval oder Fasching gewesen sein.

Ich schiebe hier eine neue Version der DCG2-C-Firmware nach, die kann jetzt auch Arbitrary-Sequenzen aus dem RAM darstellen! Die werden zwar bislang noch aus dem ROM befüllt, aber das Look-and-Feel über das Menü ist schon mal vorhanden und die "Mechanik" funktioniert auch schon.

Mit dem Speicher hab ich mich wohl etwas verschätzt . Der reicht momentan für 75 RAM-Sequenz-Schritte, in die man aber quasi beliebig viele Sequenzen unterbringen kann. Eine Sequenz kann max. 50 Schritte lang sein. Die Firmware sucht sich aber selbsttätig die Anfangs- und Endpunkte raus, d. h. mit anderen Worten, man wird die 75 Schritte einfach in einem Rutsch laden können. Die Strom-Parameter können wir aber vermutlich knicken, da reicht der Platz derzeit absolut nicht.

Was den Speicher angeht, man kann den Compilerangaben wohl nicht so hunderprozentig glauben. Bei 100 Schritten kam ein RAM-usage (.data+.bss+.noinit) von 2006 Bytes raus, was eigentlich noch reichen sollte, aber die Firmware schmierte beim Booten ab und blieb hängen. Man kann sicher die Stützwerte z. B. nicht in double sondern in uint16_t (unter Verlust von etwas Genauigkeit) speichern, aber derzeit möchte ich erst einmal die prinzipielle Funktion herstellen.

Für die freie Arbitrary-Funktion fehlt jetzt als nächster Schritt das Laden der Sequenzen über den Opto-Bus. Da muß ich mir aber noch was einfallen lassen, wie man das mit den Kommandos hinbekommt. Ich muß da wohl doch mal über der Kommandosyntax brüten. Als krönender Abschluß sollen die Parameter natürlich ins EEProm. Für die angedeutete Konfiguration sollte da aber noch Platz sein.

Jetzt ist jedenfalls erstmal Schicht!
Viele Grüße
Paul

[FlyHigh]

Hallo psclab38,

ich habe die DCG2 Version vom 11.02 auf einem 16bit DCG installiert. Im Gegensatz zu den "normalen" DCGs hat dieses einen geänderten Ausgangsspannungsbereich (0 - 45 Volt).
Bei der Arbritary Einstellung Graetz sehe ich auf dem Scope einen angenäherten Sinus, d.h. die negative Halbwelle ist nicht wie bei einer Vollwellengleichrichtung umgeklappt.
Bei der Installation gab es noch ein kleineres Problem, da Teile des EEPROMs überschrieben waren, z.b. die Parameter OPT3 und OPT6.

Beim upgraden des EDL auf EDL2 habe ich leider auch ein Problem, das mit dem Programmer gesicherte EEPROM ist nicht mit EDL2 kompatibel, gibt es dafür ausser einem komplett neuen Abgleich eine Lösung? Der Weg über LabView ist für mich auch sehr umständlich, da ich am ctLab einen älteren Mac benutze auf dem die ct Version von LabView nicht läuft.

Grüße
Frieder

[psclab38]

Hi Frieder,

ich habe die DCG2 Version vom 11.02 auf einem 16bit DCG installiert. Im Gegensatz zu den "normalen" DCGs hat dieses einen geänderten Ausgangsspannungsbereich (0 - 45 Volt).
Bei der Arbritary Einstellung Graetz sehe ich auf dem Scope einen angenäherten Sinus, d.h. die negative Halbwelle ist nicht wie bei einer Vollwellengleichrichtung umgeklappt.

Sehr schön, ein aufgebohrtes DCG!
Frage: die anderen ROM-Sequenzen sehen einigermaßen vernünftig aus? Wenn ja, dann könnte das mit dem "Sinus" an den zu langen Zeitkonstanten für die Sample+Hold-Glieder R19/C13 liegen. Wenn Du da noch Original-Bestückung hast und die nicht etwa wegen der schwachen Flankensteilheit beim Ripple verändert hast, dann könnte das die Ursache sein.

Das "Sinus"-Signal sollte 100Hz haben. Kannst Du das bestätigen? Ich nehme mal an, daß Du keine Dual-DACs drin hast.

Ansonsten wäre ein Oszillogramm hilfreich, u. U. auch vom ganz normalen Ripple von 100% runter auf 0%. Wenn letzteres deutliche Stufen hat, dann wäre meine Theorie bestätigt.

Bei der Installation gab es noch ein kleineres Problem, da Teile des EEPROMs überschrieben waren, z.b. die Parameter OPT3 und OPT6.

Beim upgraden des EDL auf EDL2 habe ich leider auch ein Problem, das mit dem Programmer gesicherte EEPROM ist nicht mit EDL2 kompatibel, gibt es dafür ausser einem komplett neuen Abgleich eine Lösung? Der Weg über LabView ist für mich auch sehr umständlich, da ich am ctLab einen älteren Mac benutze auf dem die ct Version von LabView nicht läuft.

Die Sache mit dem EEPROM ist leider eine Hürde, die nicht wirklich lösbar ist. Ich kann nicht den C-Compiler dazu überreden, die Daten genau in die gleiche Position wie der originale Pascal-Compiler zu legen. Wenn für Dich Labview nicht funktioniert, dann wäre noch eine manuelle Methode denkbar, die paar Kalibrierwerte auszulesen und zu übertragen. Die passen zwar nicht ganz 100%ig aber fast. Schlußendlich müßtest Du vielleicht nochmal nachkalibrieren (aber nur einmal, wenn Du bei der C-Firmware bleibst )


Die Hex-Files von gestern haben übrigens noch einen Bug, der dazu führt, daß sich das Modul auf dem Bus nicht anständig benimmt. Da kommt irgendwie außer dem IDN nix raus. Das hat mit dem Speicher zu tun, scheinbar muß ich noch mehr SRAM freilassen als ich bisher befürchtet habe. Ich bin derzeit bei ca. 15% SRAM frei und da geht alles. Sehr seltsam, den Speicherfresser hab ich leider noch nicht gefunden.

@alle: Ich bitte um Geduld und Nachsicht, wenn Bugs bei den derzeit hochgeladenen Versionen auftreten. Das Projekt mit dem Arbitrary-Code ist doch etwas aufwendiger als ich gedacht habe. Aber ich möchte es durchziehen. Bitte nicht vom Testen abhalten lassen, dann geht's schneller.

Ich kann nach etlichen Schweißperlen heute abend kann ich aber schon manuell über den Bus schon Arbitrary-Sequenzen ins RAM laden. Es wird.

Viele Grüße
Paul

[psclab38]

So, gute Nachrichten für die zukünftigen Arbitrary-Anwender:

- der Bug mit dem Speicher ist zumindest für die nächste Zeit mal ausgeräumt und:
- man kann die Arbitrary-Sequenzen jetzt endlich via Buskommandos ins RAM laden!

Das Problem mit dem Speicher ist ganz simpel, aber nicht minder dramatisch: Stack overruns Heap (oder umgekehrt). Der Output von Compiler und Linker bezieht sich nur auf den statischen Speicherverbrauch, den sie halt so berechnen können. Die zur Laufzeit dynamisch ablaufenden Verkettungen von Funktionsaufrufen und im Hintergrund von den Bibliotheken mal dynamisch angeforderten Speicherbereiche lassen sich zur Compilezeit nicht erfassen, deponieren aber nicht gerade wenig im SRAM.

Mir ist es nach Durchsicht - was so alles im SRAM rumlungert - gelungen, die größten Schlawiner ins ROM zu bringen. Neben ein paar noch vergessenen einfachen konstanten Strings waren das die Klartext-Fehlermeldungen für den Bus (simpel) und die Mnemonics für die Kurzbefehle auf dem Bus (oh Mann, structs im PROGMEM mit Zeigern auf PROGMEM-Strings). Alles in allem konnte ich so ca. 340 Bytes im SRAM einsparen!!! (Jetzt ist aber die Luft raus in dieser Hinsicht. Die beiden verbliebenen Strings sind ganz kurz, dafür wäre das ins ROM auslagern etwas verzwickt.)

Nun aber zum Laden der Arbitrary-Sequenzen über den Bus:

Code: Alles auswählen

x:wen=1
x:188=1

x:186=1.0 
x:187=100

x:186=0.3
x:187=100

x:186=1.0 
x:187=100

x:186=1.0 
x:187=0

x:wen=1
x:188=2

Das gibt eine Rampe von 1.0 bis 0.3 runter und wieder zurück nach 1.0, jeweils mit 100ms Rampenlänge, danach 100ms Level 1.0:

TEK0043.JPG (24.37 KiB) 16274 mal betrachtet

Wie funktionierts?
- Die Werte für Parameter 186 sind die Spannungen V im Wertebereich zwischen 0.0 und 1.0.
- Der Spannungsverlauf ergibt sich immer von V nach V[i+1] innerhalb der Zeit T
- Die Werte für Parameter 187 sind die Zeiten T im Wertebereich zwischen 1 und 65000 ms.

- Einleitung mit wen=1 und 188=1
- Die Eingabe der Sequenz-Parameter erfolgt immer im Wechsel V, T, V[i+1], T[i+1]
- Der letzte Wert T muß immer Null sein (wird notfalls automatisch auf Null gesetzt mit 188=2)
- Abschluß mit wen=1 und 188=2. Beim Abschließen des Vorgangs mit 188=2 wird der Rest des Arrays (der nicht mit Werten gefüllt wurde) gelöscht.
- 188 muß jeweils mit wen=1 "Unlocked" werden.
- Es können mehrere Sequenzen nacheinander geladen werden, direkt nach dem letzten Zeitschritt=0 der ersten Folge, die nächste anhängen. Das 188=2 kommt erst ganz am Schluß.
- Insgesamt maximal 75 Schritte (die Null-Schritte inclusive), maximale Länge einer einzelnen Sequenz 50.
- ach ja, und bitte immer die Moduladresse angeben In dem Beispiel oben ist x: die Moduladresse, also z.B. 3:
- und wenn man im Panel-Menü auf ArbMode = RAM einstellt, dann kann man das Prozedere am Oszi live beobachten (das ist kein Feature, sondern noch ein Bug, den ich einfach mal so gelassen habe.)

So, das war's. Der Rest ist Bugfixing und Aufräumen. Naja, die Sache mit dem EEPROM fehlt noch.
Viel wichtiger ist jetzt aber: Wer schreibt ein Tool, mit dem man das Laden der Sequenzen über den Bus automatisieren kann? Freiwillige vor!

Der oben beschriebene Stand ist jetzt online. Viel Spaß!

Viele Grüße
Paul

[Lennart]

ich glaub du hast eindeutig zu viel zeit

ich beschäftige mich zurzeit mit dem at91sam7s und nem dogm display .. aber ich hab noch nichtmal den init-code und die ansteuerung vom display fertig .. ich frag mich echt wo du die zeit her nimmst

[psclab38]

ich glaub du hast eindeutig zu viel zeit

Für Euch tu' ich doch alles!

ich beschäftige mich zurzeit mit dem at91sam7s und nem dogm display .. aber ich hab noch nichtmal den init-code und die ansteuerung vom display fertig .. ich frag mich echt wo du die zeit her nimmst

Der Anfang ist immer schwer, und die Kleinigkeiten machen oft Ärger. So wie dieses Array von structs im ROM, mit Strings im ROM. Oh Mann.

Die Zeit dafür ist aber echt ein Problem.

[psclab38]

Update zum Arbitrary Mode für DCG2-C:

* EEPROM Zugriff implementiert:
- abspeichern vom RAM ins EEPROM mit

Code: Alles auswählen

x:wen=1
x:188=3

- zurückholen vom EEPROM ins RAM mit

Code: Alles auswählen

x:wen=1
x:188=4

* neuer Parameter 185: ArbDelay, fügt eine einstellbare Pause zwischen den Arbitrary Code Durchläufen ein; verfügbar auf dem Bus und Panel
* Parameter 189 (ArbSelectRAM) jetzt auch auf dem Bus verfügbar (hat noch gefehlt)
* ein neues optisches Feature implementiert. Hoffentlich ist es einigermaßen selbsterklärend. Mal sehen, wer's als erstes findet.

Die neuen Quellen und Hexfiles sind online. Bugs (insbesondere für die Standardhardware) bitte posten.

Viel Spaß!
Paul

PS: Parallel zu den Änderungen am DCG2-C sind auch jede Menge Dinge für EDL2-C (und auch DDS-C) angefallen. Die hab ich auch heute eingecheckt.

[psclab38]

Es gibt wieder eine neue Version mit ein paar kleinen Fehlerbehebungen, aber als Goodie auch ein verbessertes Encoderverhalten z. B. für die Zeit-Parameter (z.B.bis 30000ms).

Ich hoffe letztere Änderung gefällt allgemein und hat sonst keine Nebeneffekte. Sie bringt eigentlich nur eine Entlastung für den Controller, weil die Routine für´s Panel nicht mehr alle 4ms, sondern nur noch alle 50ms aufgerufen wird. In der Zeit kann man dann die Encoderimpulse sammeln und hat auch was zum Auswerten. Vorher hat die Panelroutine immer alle Encoderimpulse direkt wegverarbeitet, da gab´s nix zum Sammeln.

Es sieht wohl so aus, als müßte ich derzeit die Bugs alle selbst entdecken. Aber wenn Interesse an Verbesserungen besteht, dann schaut Euch doch die Firmware bitte an, sonst fällt mein aktuelles Wissen bald wieder der Vergesslichkeit anheim.

Die gewünschten Features sind jetzt m. W. alle implementiert.

Viele Grüße
Paul

[gewo]

Hallo Paul,

die Relaisumschaltung funktioniert bei mir (16bit DCG+DCP) nicht.
Sobald die mit Parameter 170 (12.5) eingestellte Spannung überschritten wird fangen die/das Relais
an zu "flattern" .

Gerhard

[psclab38]

Hallo Paul,

die Relaisumschaltung funktioniert bei mir (16bit DCG+DCP) nicht.
Sobald die mit Parameter 170 (12.5) eingestellte Spannung überschritten wird fangen die/das Relais
an zu "flattern" .

Gerhard

Hallo Gerhard,
hmm, seeehr eigenartig. Hast Du die aktuelle Version von heute abend verwendet? Welche Betriebsart? Ripple? Sonstige Parameter? Sollstrom? Last? Auch im Leerlauf?

Ich habe extra nochmal das Oszi angeworfen und auch die Firmware in ein "leeres" DCG geladen, aber da flattert nichts. (Ich kann ja an den beiden Anschlüssen Pin7/8 vom PL6 messen.) Und die Debugausgabe, die ich nochmal aktiviert habe, verhält sich auch absolut brav. Eigentlich genauso, wie es sein soll.

Ich will jetzt nicht behaupten, daß die Code-Ecke fehlerfrei ist (Du hattest ja schon einen ähnlich gelagerten Bug entdeckt) aber irgendwas muß bei Dir anders sein als bei meinem Testaufbau.
Kannst Du mir vielleicht noch eine nähere Beschreibung zu den Begleitumständen geben?

Viele Grüße
Paul

EDIT: Ich glaub' ich weiß jetzt, was Du gesehen hast: Im >Arbitrary-Mode< flatterten tatsächlich die Relais. Wie peinlich ! Fehler erkannt und behoben, Files sind online. Schlußendlich müßten wir die verschiedenen Modi nochmal im Lastfall (speziell nach Eintritt der Strombegrenzung) begutachten, wie die Relais da "richtig" reagieren sollen. Es ist echt zu dumm, daß ich keine passende Testhardware dazu habe.

Aber danke Dir für die Rückmeldung. Das ist genau der Grund, warum ich um Feedback gebeten habe. Da ich mir die Zeit für diese Arbeit auch woanders absparen muß, kann man nicht immer so konzentriert arbeiten und alle Optionen bis ins Detail austesten...

Viele Grüße
Paul

[gewo]

Hallo Paul,

hmm, seeehr eigenartig. Hast Du die aktuelle Version von heute abend verwendet? Welche Betriebsart? Ripple? Sonstige Parameter? Sollstrom? Last? Auch im Leerlauf?

Kannst Du mir vielleicht noch eine nähere Beschreibung zu den Begleitumständen geben?

Tschuldigung, eigentlich hatte ich noch etwas mehr schreiben wollen...
Teste z. Zt. mit frisch ge"flashten" DCG ohne Abgleich lediglich Parameter 167 auf 7 (für DCP) geändert und ohne Last. Natürlich meinte ich im Arbitrary-Mode.

EDIT: Ich glaub' ich weiß jetzt, was Du gesehen hast: Im >Arbitrary-Mode< flatterten tatsächlich die Relais. Wie peinlich ! Fehler erkannt und behoben, Files sind online. Schlußendlich müßten wir die verschiedenen Modi nochmal im Lastfall (speziell nach Eintritt der Strombegrenzung) begutachten, wie die Relais da "richtig" reagieren sollen. Es ist echt zu dumm, daß ich keine passende Testhardware dazu habe.

Aber danke Dir für die Rückmeldung. Das ist genau der Grund, warum ich um Feedback gebeten habe. Da ich mir die Zeit für diese Arbeit auch woanders absparen muß, kann man nicht immer so konzentriert arbeiten und alle Optionen bis ins Detail austesten...

Viele Grüße
Paul

Ge"flasht" -> funktioniert!

Den angenäherten Sinus bei der Arbritary Einstellung Graetz den Frieder weiter oben beschreibt habe ich auch manchmal. Ich mache mal ein paar Bilder.
Was soll eigentlich die "IST-Spannung" im Panel anzeigen im Ripple- bzw. ArbritaryMode?
Ich bekomme da mal ungefähr den Mittelwert der Sollspannung und mal die Sollspannung angezeigt.

Gerhard

[gewo]

Hier mal die Bilder vom ArbritaryMode = Graetz mit DCG/DCP ohne DualDAC.

Erstmal so wie es wohl aussehen soll

Arbitrary_Graetz_ok.png (4.86 KiB) 16058 mal betrachtet

Und mit Fehler

Arbitrary_Graetz_falsch.png (4.79 KiB) 16058 mal betrachtet

Läßt sich bei mir reproduzieren im ArbritaryMode -> ROM -> ArbritarySelect und dann mit dem Drehencoder durch die Modi schalten. ISO4, ISO4m funktionieren immer, Graetz mal ok und mal falsch, 3Peaks mal ok und mal nicht vorhanden.

Gerhard

[psclab38]

Läßt sich bei mir reproduzieren im ArbritaryMode -> ROM -> ArbritarySelect und dann mit dem Drehencoder durch die Modi schalten. ISO4, ISO4m funktionieren immer, Graetz mal ok und mal falsch, 3Peaks mal ok und mal nicht vorhanden.

Hi Gerhard, danke für die Bilder und für die Beschreibung. Hatte grade schon das Tippen angefangen um diesbezüglich Fragen zu stellen.

Ich hab da einen Verdacht: es wird ja im Standardmodus in 2ms-Schritten gearbeitet, bei Dual-DAC in 1ms-Schritten. Weil bei Graetz und 3Peaks die Samples im 1ms-Raster vorliegen, nimmt die Routine immer jedes zweite. Und beim Umschalten scheint es beim Standard-Mode mal die geraden und mal die ungeraden Indizes zu erwischen. Bei 3Peaks ist dann natürlich alles Faktor 1.0. Ich muß den Indexzähler beim Kurvenumschalten wohl noch etwas zähmen.

Viele Grüße
Paul

Nachtrag:

Was soll eigentlich die "IST-Spannung" im Panel anzeigen im Ripple- bzw. ArbritaryMode?
Ich bekomme da mal ungefähr den Mittelwert der Sollspannung und mal die Sollspannung angezeigt.

Das hängt vom Samplingzeitpunkt ab. Ich muß zugeben, ich hab mich noch nicht wirklich genau drum gekümmert. Bei den "langsamen" Kurven ISO etc. konnte ich schon schön beobachten, wie die Kurve langsam abgefahren wurde.
Also momentan ist das unsynchronisiert bzw. freilaufend. Wie sollte es denn sein? Ist irgendwie schwierig, bei freidefinierbaren Kurven allgemeingültig zu bestimmen. Auf's erste Sample z.B.? Ist ja meistens 1.0... Dann wäre auch die Relaisschalterei einfacher (aber jetzt, wo's funktioniert...?)

[gewo]

Nachtrag:

Was soll eigentlich die "IST-Spannung" im Panel anzeigen im Ripple- bzw. ArbritaryMode?
Ich bekomme da mal ungefähr den Mittelwert der Sollspannung und mal die Sollspannung angezeigt.

Das hängt vom Samplingzeitpunkt ab. Ich muß zugeben, ich hab mich noch nicht wirklich genau drum gekümmert. Bei den "langsamen" Kurven ISO etc. konnte ich schon schön beobachten, wie die Kurve langsam abgefahren wurde.
Also momentan ist das unsynchronisiert bzw. freilaufend. Wie sollte es denn sein? Ist irgendwie schwierig, bei freidefinierbaren Kurven allgemeingültig zu bestimmen. Auf's erste Sample z.B.? Ist ja meistens 1.0... Dann wäre auch die Relaisschalterei einfacher (aber jetzt, wo's funktioniert...?)

Die Pascal FW zeigt im RippleMode abwechselnd den Min/Max Wert der der Spannung an, finde ich eigentlich ganz gut. Wie es im ArbritaryMode sein sollte weiß ich nicht, habe noch nie ein Gerät mit solchen Modi's benutzt. Vielleicht ist Min/Max auch nicht schlecht so sieht man zumindest den Spannungsbereich der benutzt wird.

Gerhard

[psclab38]

Die Pascal FW zeigt im RippleMode abwechselnd den Min/Max Wert der der Spannung an, finde ich eigentlich ganz gut. Wie es im ArbritaryMode sein sollte weiß ich nicht, habe noch nie ein Gerät mit solchen Modi's benutzt. Vielleicht ist Min/Max auch nicht schlecht so sieht man zumindest den Spannungsbereich der benutzt wird.

Das mit der Spannungsanzeige ist schon lange auf der ToDo-Liste, wie ich vorhin festgestellt habe. Die PascalFW hab ich dahingehend noch gar nicht genau angesehen (zu lange schon auf dem C-Trip ). Für den Ripplemode mit Zeiten über 400ms funktioniert das aber schon so ähnlich, wie Du gesagt hast. Die Werte werden momentan nur on-the-fly gemessen und angezeigt. Für Deinen Vorschlag müßte ich die Werte abspeichern und dann im Displayrhythmus anzeigen. Mal drüber nachdenken...

Bezüglich des Arbitrary-Mode: Für die Standardhardware hab ich die Änderungen eingecheckt. Das ist leider ein wenig wie Blindflug, ich kann's nicht testen. Quasi Programmieren durch Nachdenken. (und das, nach DEM Arbeitstag den ich heute hatte. ). Der Fix ist nicht hundertprozentig ideal. Weil die Samples der ISR während dem vollen Lauf (ja, schon atomar) ausgetauscht werden, weiß diese zur Laufzeit (also mitten in der Sequenz) nicht, wo sie exakt steht. Sie macht also weiter bis zum Ende, und wird jetzt hart resetet (auf Index 0, auch wenn der eigentlich bei 1 hätte weitermachen wollen. Aber ungerade gibt's halt bei Standard-HW nicht.
Der Arbitrary-Delayparameter für die Standardhardware sollte jetzt auch richtig eingreifen, da war mir vor ein paar Tagen eine Zeile verrutzzzt.

Wichtigste Konsequenz des Fixes von heute: Bei der Standardhardware muss die Summe der Sampleparameter-Zeiten GERADE sein. Wäre sie ungerade, dann hätte in dem "Graetz"-Beispiel von oben eine Periode wie der erste Screenshot und die andere wie der zweite Screenshot ausgesehen.

NB: Weil's beim allerersten Einschalten wegen dem Initialisieren des EEPROM ziemlich dauert, gibt's jetzt auch eine Displayanzeige. Damit die Ungeduldigen nicht gleich wieder ausschalten...

So, dann mal gute Nacht.
Paul