Problem mit PStrings

[DaPeta]

Hallo zusammen,

sitze jetzt hier schon eine ganze Weile und komm nicht weiter.
Ich programmiere hier an einer DLL für eine Hardware die hier bei uns entwickelt wird. Unter anderem kann man aus verschiedenen Prozessoren und FPGAs die Versionen auslesen. Mit einer kleinen Beispiel-DLL funktioniert das auch sehr schön.

Wenn ich jedoch meine "ernste" DLL benutze erscheint als Ausgabe String meistens eine '0' oder '5'. Nur ganz selten die Version selber. Ich arbeite mit Delphi 2005.

Die Zuweisung der Version sieht bei mir so aus

Code: Alles auswählen

PStrings^[VersionOutBIdx]            := PAnsiChar( Cmd.VersionB );

In Cmd.Version steht der richtige String. Nach der Zuweisung auch in dem PStrings Array einwandfrei.
Das bleibt alles richtig bis an das Ende der CalculateEx Funktion. Beim nächsten Aufruf von CalculateEx steht dann eine '5' oder eine '0' dort (sieht fast nach dem Takt oder sowas aus).

Ich habe in meinem Programm mal alles auskommentiert außer dem "Version per RS232 holen" und der Zuweisung.

Ich habe den Verdacht, dass bei 37 Ausgängen und 10 Eingängen irgendetwas überschrieben wird?

LG
Peter

[Mike D]

Die analogen Eingänge und Ausgänge haben getrennte Arrays, so dass ein einmal gesetzter Ausgangswert bei erneuten Aufrufen von CalculateEx bzw. Calculate erhalten bleibt.

Bei den Strings ist das anders! Offenbar aus Platzgründen liegen die String-Eingänge und -Ausgänge im selben Array. Dieses wird vor jedem Aufruf von CalculateEx neu initialisiert. Dadurch ist der eben gesetzte Inhalt verloren. Deine Stringzuweisung muss also bei jedem Aufruf von CalculateEx gemacht werden damit der Wert dauerhaft am String-Ausgang anliegt.
Da hab ich auch eine Weile gebraucht um das zu begreifen.

Mike

[DaPeta]

Hallo Mike und vielen Dank für deine schnelle Antwort.

Meine CalculateEx macht mittlerweile nix anderes mehr als String aus Hardware holen und dem PString-Array zuzuweisen. Sobald meine Funktion verlassen wird und es zurück nach PL geht sehe ich in der Anzeige $Display oder einem Testpunkt nur die Ziffern 0 bzw. 5. Der String kommt nur ab und zu durch.

War es also leider nicht, da bei jedem Aufruf PStrings^[...] einen gültigen Wert zugewiesen bekommt.

LG
Peter

[Mike D]

Den String aus der Hardware auslesen brauchst du ja nur einmal zu machen. Du musst ihn dann aber in einer Variablen speichern, die das Beenden und Neuaufrufen von CalculateEx überlebt, also entweder static oder in der DLL global ist.

[Mike D]

Ist dir klar, das CalculateEx mit jedem Durchlauf von PL, also mit etliche kHz aufgerufen wird?

[DaPeta]

Hallo Mike

vielen Dank, dass Du Dich meiner annimmst !!!

Ist dir klar, das CalculateEx mit jedem Durchlauf von PL, also mit etliche kHz aufgerufen wird?

kHz Traum für Wahr. Ich habe es intuitiv so verstanden, dass PL die Calculate bzw. CalculateEx jeder eingebundenden DLL der Reihe nach aufruft und die resultierende Geschwindigkeit sich danach richtet? Ist doch richtig so oder? Blöderweise kann ich mit der Hardware mit max. 38400 Baud reden (olle abwärtskompatibilität).

Natürlich hast Du Recht damit, dass es genügt den Versionsstring nur einmal abzuholen und dann per globaler Variable auszugeben. Was mir nur auffiel ist die Tatsache das eine DLL mit wenig Ein/Ausgaben einwandfrei funktioniert, aber bei höheren Anzahlen sich merkwürdig verhält. Ich habe mir heute abend mal eine DLL gebastelt welche nur einen "Takt" Eingang und eine "Version Strings" Ausgabe enthält gebastelt. Das geht perfekt mit bis zu 5kHz.

Morgen mal weiter forschen
Bedankt und lG

Peter

[Mike D]

um eine vernünftige Simulationsgeschwindigkeit in PL zu behalten muss die Calculate(Ex) so wenig wie möglich tun, im idealfall nur Eingänge abfragen, kurze Berechnung und Ausgänge setzen. Zeitintensive Sachen wie Komunikation mit Hardware sollte in einen eigenen, asynchronen Thread ausgelagert werden, der von Calculate(Ex) nur angestoßen wird und sein Ergebniss dann an einen späteren Aufruf von Calculate zurück gibt.

Mike

[DaPeta]

Hallo Mike,

absolute Zustimmung mit dem Thema Thread was die Performance angeht! Dennoch bin ich der Meinung es gibt eine böse Falle in PL wenn es "viele" Ein/Ausgänge gibt. Verwunderlich ist, dass die Werte bis zum letzten "end;" der CalculateEx in Ordnung sind und beim nächsten Aufruf schon auf dem ersten begin falsch sind. Es wird also ausserhalb meiner DLL ein Wert in den PStrings überschrieben und das verwirrt mich

LG
Peter

[Mike D]

Genau das hebe ich doch in meiner 1. Antwort geschrieben.
PStrings wird vor jedem Aufruf der DLL mit den Eingangswerten beschrieben und die DLL muss dann wieder die Ausgangswerte reinschreiben.

Mike

[abacom]

Bitte auch nicht vergessen, dass die Namen von Ein- und Ausgängen mit einem '$' beginnen müssen um einen Pin für Strings zu benutzen. Nur zur Erinnerung.

[DaPeta]

Hallo zusammen,

@abacom Vielen Dank für den Hinweis mit dem $. Alle "String" Ein/Ausgänge haben ein $.

@Mike jepp, Deinen Hinweis, dass PStrings anders als POutput seinen Inhalt nicht behält hatte ich geglaubt verstanden zu haben. Ich dachte allerdings, dass PStrings erst beim erneuten Aufruf von CalculateEx unvalide wäre und nicht schon undeterministisch vorher. Für mich bietet sich also folgendes Bild

zum Zeitpunkt t=0 schreibe ich einen String in PStrings
bei t=t1 bin ich am Ausgang der CalculateEx und alles ist in Ordnung
dann verschwindet die Kontrolle an PL und PStrings hat "meinen" Wert bis t=t2. Ab einem t>t2 (wann immer das sein mag) steht in PStrings ein anderer Wert ('0' oder '5') und erst bei t=t3 wird "meine" CalculateEx wieder aufgerufen. Zwischen t2 und t3 passiert etwas ohne meine Kontrolle. Wenn t3-t2 "kurz" genug ist ist alles o.k. wenn t3-t2>tx ist wird auf der Oberfläche ein Wert '0' oder '5' angezeigt. Ist das in etwa richtig so? Meine Frage wäre (vorausgesetzt mein Gedankengang stimmt), wann ist t2 und wie groß darf t3-t2 sein?

Mag sein, dass ich mich vollkommen verrenne, deshalb frag ich auch hier nach. Ganz schön schwierig zu beschreiben...
Leider habe ich aus Zeitdruckgründen nicht die Gelegenheit die Thread Variante auszuprobieren gehabt (werd ich aber sicher nachholen).

Guz Nächtle
Peter