DEAD_ZONE - Problem bei Phoenix ILC130

[fenast]

Liebe Leute, ich habe ein lustiges kleines Problem mit einer Phoenix-Kleinsteuerung ILC 130 ETH unter PCWORX 5.20 (SP 4.45).
Dort habe ich den OSCAT(3v32)-PID-Regler CTRL_PID genutzt (übrigens ein Klasse-Teil!) und mich gewundert, warum er nicht funktioniert. Der Output liefert konsequent 0.0. Weitere Forschungen ergaben, dass die (dort verwendete) Funktion DEAD_ZONE Quelle des Übels ist. Sie spuckt ebenfalls Null aus, egal welche Parameter man ihr übergibt. Da tut sie auch, wenn man sie isoliert einfach im Hauptprogramm aufruft, z.B. ist hier DzOut immer 0.0 statt 2.0:
DzOut := DEAD_ZONE (DzIn, DzLim) mit den Vorbesetzungen DzIn := 2.0; DzLim := 0.1; oder beliebigen anderen Werten.
Der Blick in den Code von DEAD_ZONE zeigt, dass dort mittels ABS() ein Absolutwert berechnet wird. ABS() liefert jedoch immer 0.0, wenn ABS() innerhalb von DEAD_ZONE aufgrufen wird. ABS() funktioniert jedoch, wenn ABS() im Hauptprogramm direkt (also nicht innerhalb einer OSCAT-Bibliotheksfunktion) aufgerufen wird.
Wenn man den (überschaubaren) ST-Code von DEAD_ZONE modifiziert und die ABS()-Funktion dort entfernt bzw. durch funktionsgleiche if-Konstrukte ersetzt, funktioniert alles. Aber das kann's nicht sein.
Schreibt man das gleiche Programm für ein anderes Phonenix-Zielsystem, für das eine PC-Simulation möglich ist (bei der ILC130 gibt's dämlicherweise keine Simu-Möglichkeit), so funktioniert alles (auch mit ABS()) wunderbar.

AÄhhh - ich bin nicht gerade ein Anfänger (wohl schon bei PCWORX), aber dazu fällt mir nix ein... vielleicht hat jemand von euch eine Idee? Demo-Projekt (obiger Dreizeiler) kann zur Verfügung gestellt werden, aber man braucht halt eine ILC130, um das auszuprobieren. Vielen Dank vorab für eure Hilfe.

[peewit]

wenn es in der simulation funktioniert, aber auf deiner hardware nicht, ist es wahrscheinlich ein fehler im compiler
die simulation für eCLR kommt erst 2012, und bislang muss man auf RFC xxx umstellen
dabei wird aber ein X86 basierter compiler verwendet.
dadurch kann es auch zu unterschiedlichen ergebnissen kommen, was aber natürlich nicht sein sollte

mit jeder höheren pcworx version, kommen neuere höhere eCLR compilerversionen hinzu
so wie ich vermute hast du eine fehlerhafte kombination in anwendung
und wahrscheinlich reicht die neueste firmware und pcworx version aus, damit das problem nicht mehr auftritt

aber um es genauer bestimmen zu können brauche ich mehr informationen

ilc 130 eth mit welcher firmware (projekt-kontroll-dialog -> info aufrufen)
welche projektvorlagen version hast du in verwendung
(wenn du projekt neu machst, was steht bei der vorlage dabei  z.b. 01/2.00 usw...)

[fenast]

Danke, peewit, für die superschnelle und kompetente Antwort.
Leider besitze ich keine neuere PC-Worx-Version um damit zu experimentieren. Wäre trotzdem der Versuch eines Firmware-Upgrades lohnenswert?
Hier sind die Zusatzinfos:
SPS: ILC 130 ETH 2.0.5.9062
Firmware: V. 3.54.01 07/16/09 HW 01
Projektvorlage: ILC 130 ETH Rev. > 01/3.00

[peewit]

firmware kannst du ruhig updaten, da kann eigentlich nichts negatives passieren
allerdings wird es wahrscheinlich dein problem nicht lösen

du wirst ein pcworx update benötigen, damit ein anderer compiler-core zur anwendung kommt

ich habe leider keine ilc 130 bei der hand zum testen, aber bei einer ilc 150 gsm mit FW 3.70 und aktuellen compiler-core
passiert dieser fehler nicht, somit ist der fehler wahrscheinlich schon gefixt, aber deine version ist leider zu alt

[fenast]

Vielen Dank für deine Mühe!!
Dann muss ich mich wohl um einen neuen Compiler kümmern; wer weiß, was da sonst noch für Merkwürdigkeiten schlummern.
Schon ein dickes Ding... einziger Vorteil: Ab jetzt kann ich bei Fehlern mit dem Setup immer sagen: wahrscheinlich liegt's wieder mal an PC WORX ;-)
Schönes WE!