Hallo Horst,
inzwischen habe ich jetzt wieder einen klaren Durchblick, da ich endlich meine Reservekopie des Sourcecodes gefunden habe, so muss ich nicht mehr nur aus dem Gedächtnis (13 Jahre her) die Sachlage rekonstruieren.
ich gehe mal davon aus, dass deine Frage auf die Abfrage der Status-Bereitschaft abzielt. Zum Vergleich findest Du die (a) Routine der Funktion „GetStatus“ aus der 16Bit-DLL (gekürzt und etwas gestrafft), sowie den (b) Programmcode aus dem 14Bit-Anwendungsprogramm aufgelistet.
Auszug aus der DLL – 16 Bit
----------------------------------------------------------------------------------
int getStatus(uint8_t *statusFlags, uint16_t *framesInMemory,…)
report[0] = ZERO_REPORT_ID; -> 0
report[1] = STATUS_REQUEST; -> 1
result = _writeReadFunction(report,.., ….,…);
if (statusFlags) {*statusFlags = report[1]; }
if (framesInMemory) { *framesInMemory = (report[3] << "8") | (report[2]); }
| Auszug aus dem Hauptprogramm – 14 Bit
----------------------------------------------------------------------------------------------------
//*********** get status ***************
OutputReport(0) = 0 -> ZERO_REPORT_ID
OutputReport(1) = 2 -> STATUS_REQUEST
s = ReadAndWriteToDevice(V:InputReport(0), V:OutputReport(0), 1)
While InputReport(3) != 0
s = ReadAndWriteToDevice(V:InputReport(0), V:OutputReport(0), 1)
Wend
|
Der Programm-Aufbau und die „Verarbeitung“ (auf der PC-Ebene) sind sehr ähnlich. Die wesentlichen Unterschiede sind:
1) Das 16Bit- „GetStatus“ ist weiter abstrahiert und taucht eben nur noch als „Getstatus“ im Anwendungsprogramm auf. Anhand des Programm-Codes in der DLL, siehst du aber, dass das, was bei mir im Hauptprogramm steht (z.B. das „Reportfeld“), in die 16 Bit –DLL ausgelagert worden ist
2) Die Parameter-Werte sind teilweise anders (rot markiert)
Damit ist die Benutzung der DLL’s an die jeweiligen Gerätetypen gebunden und nicht austauschbar. Sicherlich wird ohnehin kein „16Bit-User“ die alte Bibliothek nutzen wollen, die „14Bit-User“ können aber auch nicht die neuere DLL benutzen. (Man könnte natürlich die 14 Bit-Bibliothek umschreiben, um so eine Angleichung zu erreichen…)
Die eigentlichen Befehle sind letztendlich die Windows-API-Funktionen „WriteFile“ und „Readfile“, welche mit dem Betriebsprogramm des Spektrometers kommunizieren. Diesen API-Funktionen werden die Parameter in einem Feld/Speicher („….Report“ bzw. OutputReport und InputReport) übergeben bzw. zurückgegeben. Die Funktion „writeReadFunction“ (16 Bit) bzw. „ReadWritetoDevice“ (14 Bit) sind nur Zwischenstationen zu den API-Funktionen.
Der Vollständigkeit halber, und zum Vergleich mit deinem Beispiel, die Routine im Haupt¬programm zum Spektrentransfer (welche sich an den oben gezeigten Sourcecode anschließen würde..):
For i = 1 To NScans
s = GetSpectra( _
V:SpecInt(0, i - 1), /* "Spectra" = 3653 elements (unsigned __int16) array */ _
1, /* "SpecNmb" = 1 */ _
0, /* "endPix" = 3652 */ _
3652, /* "StartPix" = 0 */ _
Fast, /* "Fast" = 0 or 1 */ _
0, /* "test1" = 0 */ _
33, /* "tot_startPix " = 33 */ _
3685) /* "tot_endPix" = 3685 */
OutputReport(1) = 9 //move address ?? (whatever that means …)
OutputReport(2) = &H01
OutputReport(3) = &H80
s = ReadAndWriteToDevice(V:InputReport(0), V:OutputReport(0), 1)
Next iDie Nutzer-Oberfläche der „ASEQ_16bits V1_13.exe“ (Abbildg., Beitrag #17) sieht zumindest so aus, wie die der „CheckTr.exe“. In der Menuleiste steht „ASEQ Software“ über „Help“ erhält man die Versionsnummer, bei mir Version 9.4.
Ja, in der Tat sind deine (im Flash-Speicher abgelegten) Werte etwas anders … So vorhanden, geh doch bitte mal in das Haupt-Menu „Calibration“, sowie zum Untermenü „Calibration“. Dort werden die drei Parameter A, B und C angezeigt, so vorhanden. Aber letztendlich bist du ja nicht auf den Parametersatz zur Berechnung der Wellenlänge = f(Pixel) angewiesen, da du ja eine WL-Wertetabelle hast. Mir ist jetzt nicht klar, ob du nach den Parametern A,B und C suchst, um deinen Wissensdurst zu stillen, oder ob dir der analytische Ansatz, via Polynom, symphatischer ist.
Aus dem Flash-Speicher werden die Werte der Aufzählung (1-3) (Antwort #18) ausgelesen. Das bekomme ich auch mit meinem Programm hin. Woher allerdings die Werte aus der Aufzählung (6) (Antwort #18) kommen (3553 mal den Wert= 51.199), ist mir aber noch unklar. Es ist nicht unbedingt zwingend, den Flash-Speicher im Anwendungsprogramm auszulesen. Letztendlich reicht auch eine „Verdrahtung“ der Daten in der (eigenen) Applikation bzw. das Einlesen der Daten vom Speichermedium, wenn man z.B. eine ganze Batterie von ASEQ-Spektrometern hat
.
Die unter der Aufzählg. (3) (Antwort #18) erwähnten, und in der Abbildung „Graph1c.jpg“ dargestellten Werte zur Intensitätskorrektur, nutze ich auch. Wer es ausprobieren möchte: In der „ASEQ software“ über die IconBar, das Icon „Schraubenschlüssel“ auswählen. Im „Settings“-Menu -> „Apply norm“ wählen (Standardeinstellung). Die angefügte Abbildung zeigt die Unterschiede welche mit einem LR1-14Bit zu beobachten sind.
Die Option „Test“ in der Funktion „GetSpectra“ (das 14Bit-Pendant für „GetFrame“) wurde anhand der 14Bit-DLL untersucht. Die Funktion besteht aus mehreren Seiten Programmier¬code, eine schnelle Analyse ist da nicht möglich. Ein Vergleich der beiden Sequenzen zeigt aber, dass der Testbereich wesentlich weniger umfangreich, und im Wesentlichen identisch, mit dem Anfang der normalen Routine, ist. Standardeinstellung für den Parameter „Test“ ist ja „0“, jeder andere Wert führt die Test-Routine aus. Es ist anzunehmen, dass die 16Bit-DLL kaum Überraschungen dahingehend bereithält. Im CheckTr-Programm („Settings“) ist diese Option übrigens auch verfügbar.
Noch mal zum Binning-Parameter der setFrameFormat()-Funktion (16 Bit). Du hattest es ja als „… eine Art von Binning“ bezeichnet. Ich hatte noch mal überlegt ob es jetzt ein Software-Binning ist oder doch ein Hardware-Binning sein könnte. In der Beschreibung des Parameters “reductionMode” steht: “reductionMode defines the mode of pixels averaging 0 - no average 1 - average of 2 2 - average of 4 3 - average of 8”. Was ja leider eher nach Software-Binning (reine Mittelwertbildung) aussieht. Ganz ausgeschlossen scheint mir das echte Binning (Hardware-) aber nicht zu sein. Sicherlich ist diese generelle Frage bei ASEQ besser aufgehoben, aber falls jemand
praktische Erfahrungen/Kenntnisse haben sollte, im Fall es ist Hardware-Binning, würde mich natürlich über eine Nachricht freuen.
Viele Grüße aus Berlin
Michael
