c't-Lab

Die Urversion zeigt das gleiche Verhalten:
Hier mal das Signal direkt am Ausgang des Multiplexers. Hier konnte ich das Nachschwingen nicht beobachten, bzw. das Scope kommt an seine Grenzen und triggert nur auf ein Signal. Trotz 24M Speichertiefe kann ich nicht bis zum nächsten Impuls scrollen... Das Rigol ist nicht schlecht für den Preis, aber kann nicht alles.

Allerdings kann das Nachschwingen durch die Konfiguration der R/C-Zeitkonstanten am Ausgang des Multiplexers verursacht sein, die ich mit 470R/1µf bestückt habe...
Die Signale vom Prozesser muss ich mir noch genauer anschauen, was etwas komplizierter ist. Da muss ich die Zugriffe vergleichen, was etwas aufwändiger ist. Schaffe ich heute nicht mehr. Fest steht jedoch, dass in der C-Version ein Schreibzugriff zusätzlich erfolgt.

psclab38 hat geschrieben:

AwA hat geschrieben:Ja, ich werde mal die oben verlinkte Software ausprobieren und berichten. Was mich wundert ist, dass es noch niemandem auffiel.

Wer betrachtet schon Gleichspannung am Oszi?
Bitte beim Oszillogramm aufnehmen darauf achten, dass jeweils genau die gleichen Strom und Spannungssollwerte eingestellt sind. Der DAC pendelt ja permanent zwischen den beiden Werten.

Warum sollte man keine Gleichspannungen am Oszi betrachten? Wie man sieht, spielt sich da doch einiges ab.
Natürlich habe ich nichts verändert, alles unter den gleichen Bedingungen aufgenommen. Da leistet mir ein altes Dummy-Load-Wattmeter vom Trödel gute Dienste.

AwA hat geschrieben:Die Urversion zeigt das gleiche Verhalten:

Also, dann hab' ich mit meinen Änderungen da nix verschlimmert. Puhh!

Ich habe auch kurz in den Code geschaut. Es gibt schon mal diesen Unterschied:

- die Pascal-Firmware hat einen 1ms Interrupt und schaltet so:
0,0ms: beide Analogschalter aus, DAC auf Spannungs-Sollwert, 10µs+delta trödeln, dann MPXU an --> C13 wird geladen
1,0ms: beide Analogschalter aus, DAC auf Strom-Sollwert 10µs+delta trödeln, dann MPXI an --> C20 wird geladen
delta ist die Zeit für ein paar Kommandos, die zwar was Nützliches machen aber an der Stelle parallel zur Stabilisierung des DAC laufen
die Schalter sind also wechselweise für ca. 980µs von 2000µs geschlossen

- die C-Firmware hat einen 500µs Interrupt und schaltet so:
0,0ms: beide Analogschalter aus, DAC auf Spannungs-Sollwert
0,5ms: MPXU an --> C13 wird geladen
1,0ms: beide Analogschalter aus, DAC auf Strom-Sollwert
1,5ms: MPXI an --> C20 wird geladen
die Schalter sind also immer nur 500µs von 2000µs geschlossen, die jeweils anderen 500µs bekommt der DAC zum Stabilisieren

Jetzt ist interessant, warum die C-Firmware so lange klingelt....

470R/1µF sind zwar dieselbe Zeitkonstante wie 4k7/100n, aber die Ladeströme sind für den DAC schon deutlich größer.

Danke für die Erläuterungen. Ich habe übrigens die Zeitkonstanten auf die ursprünglich im Schaltplan beziffeten Werte geändert, also 4,7K/100n. Da ändert sich nichts. Ich ging davon aus, dass der Peak etwas abgeschwächt wird, was jedoch nicht der Fall ist. Na ja, ich werde sowieso noch auf die Dual-Dac-Lösung umbauen, genügend DA-Wandler habe ich ja hier. Ich habe allerdings schon ewig keine Platinen mehr geätzt.

Ich hab mir heute kurz die Hardware auf Standardbestückung zurückgebaut. Dann mit dem Oszi mal die Signale MPXI und MPXU angeschaut und ich muß meine Darstellung zwei Posts weiter oben korrigieren. Die beiden Signale werden für die Standardkonfiguration mit nur einem DAC im 1ms-Raster getoggelt, ich habe mich da vom etwas unübersichtlich gewordenen Code verwirren lassen.
Die beiden folgenden Bilder enthalten zu den Multiplexersignalen noch das DAC-Signal. Das steigt und fällt ganz zahm. Ich weiß nicht, wo Dein zusätzliches Störsignal und das lange Klingeln herkommt.

Nun, ich weiß nur, dass es lediglich bei der C-Version auftritt, und das bei zwei DCG's. So richtig auf Fehlersuche habe ich mich noch nicht begeben. Die Oszi-Bilder zeigen das Verhalten am Geräteausgang und nicht direkt hinter oder vor dem Multiplexer. Die Signale MPXI und MPXU werden bei mir nicht anders aussehen als bei Dir. Kannst Du mal am Geräteausgang nachmessen?

AwA hat geschrieben:Kannst Du mal am Geräteausgang nachmessen?

Das Störsignal ist am Ausgang eher nicht-deterministisch; mein Oszi zeigt da kein festes Raster. Peak-Detect ist an. Hast Du das DCP mit dran oder nur DCG?

Ohne Last sieht es ähnlich aus wie bei Dir, jedoch zeigt auch dann das Oszi die Peaks, wenn auch sehr kleine. Es schafft, sie zumindest sauber zu triggern. Meine Bilder enstanden alle unter Last, 5V-ca. 200mA. Nein, kein DCP dran, die muss ich erst noch zusammenlöten.

Hallo psclab38,

vielen Dank dafür, dass Du in der Zischenzeit die C-Firmware aktualisiert und zum Download bereitgestellt hast. Ich wollte schon nach der On_Off-Firmware für die DualDac-Version anfragen und entdeckte dann, dass sie schon da ist. Super. In der Zwischenzeit habe ich die DualDac-Schaltung probehalber mal auf einer kleinen Steckplatine aufgebaut, nur kurz zum Test ohne Abblockkondensatoren und Drosseln. Das Signal sah dann auch etwas gestört aus, aber es funktionierte dennoch sehr gut. Bin nun dabei, mir die Platinen aufzubauen, geätzt sind sie sie schon. Mal schauen, ob ich dann zufrieden bin, oder weiter die zahlreichen Verbesserungsvorschläge umsetze, auch die fürs EDL. Man hat ja sonst nichts zu tun. Naja, Spaß machts dennoch. Hätte ich die Zeit, würde ich das DCG auf einer neudesignten Platine völlig neu aufbauen.

AwA hat geschrieben:vielen Dank dafür, dass Du in der Zwischenzeit die C-Firmware aktualisiert und zum Download bereitgestellt hast. Ich wollte schon nach der On_Off-Firmware für die DualDac-Version anfragen und entdeckte dann, dass sie schon da ist. Super.

Gerne. Ich versuche immer den Code zeitnah hochzuladen.