TwinCAT3: Feststellen, ob ein Eingang belegt ist?

[Jörn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

ich hätte da mal wieder ein "vermutlich nicht triviales" Problem.
Es geht um die TcXaeShell 15.0 (Build 4024.0).

Ich habe einen generischen FB für Förderstrecken geschrieben. Nun kann für die Erkennung von Einlauf und Auslauf ja entweder nur einen Einlaufsensor, nur einen Auslaufsensor oder einen Einlauf- und einen Auslaufsensor vorhanden sein. Zudem ist noch optional ein Vorstopsensor möglich, wenn die Förderstrecke mit 2 Geschwindigkeiten bzw. Rampen für den Anlauf und das Bremsen der Motoren arbeitet. Zu allem Überfluss kann die Beschaltung bei verschiedenen Förderrichtungen unterschiedlich sein, Stichwort Winkelübergabe.

Es sind also zwischen 1 und 12 Sensoren möglich (selbstredend zzgl. Sensoren für Hubtisch, Pusher, Separatoren, ... :icon_eek: ). Ich hätte nun aber ungerne 24 Eingangsvariablen am FB, 12x IstDerSensor...Vorhanden und 12x Sensor... . Es wäre mir viel lieber, wenn es eine Möglichkeit gäbe abzufragen, ob ein Eingang beschaltet ist. Ich hab schon in der E/A-Konfiguration geschaut. Dort kann man ja die Inputs mit Variablen verknüpfen und man sieht auch die Verknüpfung. Wenn ich aber in der zugehörigen GVL schaue, in der die Variablen stehen, erkenne ich nirgendwo dran, daß die Variablen verknüpft ist. Auch mit SensorName.HierErscheintJetztWas hatte ich kein Glück.

Alternativ wäre ein Datentyp mit den drei Zuständen false, true und zusätzlich nc / null / neither / ... auch okai. Einfach den Initialisierungswert z.B. auf false setzen hilft mir nicht, da ich an verschiedenen Stellen auf true, false und auf steigende und fallende Flanke abfragen muss. Ich habe ein ENUM mit drei Zuständen angelegt, da laut infosys true ja 1 und false gleich 0 entspricht (1). Einem ENUM kann ich true und false nicht zuweisen. So weit, so gut. Ich kann allerdings statt auf false und true auch nicht mit 0 und 1 vergleichen. Da bekomme ich dann den Fehler Cannot compare type 'BOOL' with type 'E_Three'.

TYPE E_Three:
(
   _null_    := -1,
   _false_   := 0,
   _true_    := 1
);
END_TYPE

FB_Conveyor
IF ixSensors.ST_Back.ixInfeed = E_Three._true_ THEN
   // Error: Cannot compare type 'BOOL' with type 'E_Three'
END_IF

Hat irgendwer eine Idee? Bitte? Es darf auch gerne noch anders als meine beiden Varianten funktionieren.

Gruß
Jörn

(1)
https://infosys.beckhoff.com/content/1031/tc3_plc_intro/2529394315.html?id=8249233644934405028

 

[Heinileini]

Ich würde für jeden nur bedingt vorhandenen Sensor eine zusätzliche BOOLesche Variable (oder Konstante?) anlegen, in der steht, ob der Sensor zu berücksichtigen ist oder nicht.
Wer soll das noch verstehen, wenn Du statt mit BOOLeschen Eingängen nun mit eigenen "TriState"-Variablen für die Eingänge herumrechnest?
Aufwändig wird es sowieso, wenn dass Programm alle möglichen Konfigurationen beherrschen soll. Aber dann auch noch in Jörnscher Algebra verknüpfen?!

PS:
Du willst doch wohl (hoffentlich) nicht darauf hinaus, dass das Programm automatisch erkennt, was angeschlossen ist und was nicht?
Das könntest Du mit Steckern machen, die auf einigen Bits eine Kodierung (Brücken) enthalten, so dass Du wahlweise eine von mehreren verschiedenen Baugruppen anschliessen kannst.

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es wäre mir viel lieber, wenn es eine Möglichkeit gäbe abzufragen, ob ein Eingang beschaltet ist.

Deklariere den Eingang mit Startwert True. Wenn der Eingang auch nur für einen Zyklus auf False springt, weist Du, das er verknüpft wurde.

 

[Guga]

Ich hätte folgenden Ansatz im Angebot:

https://help.codesys.com/api-content/2/codesys/3.5.16.0/en/_cds_pragma_attribute_is_connected/
Achtung:
- nicht in TwinCAT dokumentiert deshalb ohne Gewähr.
- gerade eben mit der 4024.7 an dem Beispiel vom Link ausprobiert, hier funktioniert es. Die Chance das es mit der 4022.x funktioniert schätze ich als sehr unwahrscheinlich ein.


Guga

 

[MFreiberger]

Moin,

Deklariere den Eingang mit Startwert True. Wenn der Eingang auch nur für einen Zyklus auf False springt, weist Du, das er verknüpft wurde.

"Springt" der Eingang nicht auch auf False, wenn etwas angeschlossen ist, aber das Signal False ist?

Ich würde jedem Sensor ein Byte spendieren. Da könnte man ggf. noch weitere Informationen (je nach Sensorausstattung (Diagnoseausgang?)) mitgeben.
Etwa so:

Byte.0 = Signal
Byte.1 = /Signal
Byte.2 = Config
Byte.3 = Pending (z.B. wenn eine Waage misst. Ist der Messvorgang beendet ==> Pending = FALSE)
Byte.4 = n.v.
Byte.5 = n.v.
Byte.6 = n.v.
Byte.7 = Error (z.B. wenn der Sensor noch einen digitalen Diagnoseausgang zur Verfügung stellt)

Da könntest Du dann eigentlich alles mit erschlagen, was so ein (digitaler) Sensor überlicherweise liefern kann.

VG

MFreiberge

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

"Springt" der Eingang nicht auch auf False, wenn etwas angeschlossen ist, aber das Signal False ist?

Nicht, wenn der Eingang gar nicht erst verknüpft wurde. Das geht übrigens erst mit TC3. Bei TC2 konnte man einen als HW-Input deklarierte Variable nicht beschreiben. Das hatte der Compiler nicht aktzepiert.

 

[Heinileini]

Ja, also ... wenn das ...

Deklariere den Eingang mit Startwert True. Wenn der Eingang auch nur für einen Zyklus auf False springt, weist Du, das er verknüpft wurde.

... die Lösung sein soll ... dann hätte ich wirklich gerne mein Problem zurück, statt mir zusätzlich ungeahnte einzufangen.

Bei einem (Software-)Baustein abfragen zu können, ob ein Eingang im BausteinAufruf beschaltet ist, mag ja sinnvoll sein, wenn dieser Baustein vorsieht, dass Eingänge unter bestimmten Umständen nicht beschaltet werden müssen.
Aber wozu will man abfragen, ob ein HardwareEingang zwar physikalisch anwesend ist, aber aktuell kein Sensor angeschlossen ist, oder, ob der HardwareEingang durch physikalische Abwesenheit glänzt?
Für DiagnoseZwecke (z.B. DrahtBruchErkennung) kann ich das noch nachvollziehen.
Aber, um das Programm erkennen zu lassen, ob bestimmte Baugruppen/AnlagenTeile überhaupt vorhanden sind und falls ja, in welcher Variante?
Was sagen denn unsere SicherheitsSpezialisten zu solchen Bestrebungen? Wenn aufgrund eines DrahtBruchs oder eines WackelKontaktes die Software plötzlich meint, eine Konfiguration vor sich zu haben, die so gar nicht zur tatsächlich angeschlossenen passen will?
Ich würde mich nicht auf eine solche Art der "Automatisierung" einlassen wollen. PlausibilitätsPrüfungen sind schön und gut, um unter bestimmten, günstigen Umständen zusätzliche Möglichkeiten zu haben, Fehler erkennen zu können.

Aber sich auf "zufällige" Merkmale zu verlassen, um damit zwischen unterschiedlichen Abläufen zu wählen?!? Das verleitet bestenfalls zu Leichtsinn. Das Wort "zufällig" wird wahrscheinlich als unpassend empfunden, aber ... was, wenn wirklich ein DrahtBruch zu einer Fehlinterpretation führt, oder ein defekter Sensor provisorisch abgeklemmt wurde, damit wenigstens die Produktion weiterlaufen kann, die ohne ihn auskommt, oder wenn der Elektriker einen Sensor absichtlich auf einen anderen Eingang "umgeleitet" hat? ​

 

[asci25]

Hallo Heinileini,

ohne einen Glaubenskrieg starten zu wollen....

Leider hast Du nicht ganz verstanden, was ich meine.

.... Wenn aufgrund eines DrahtBruchs oder eines WackelKontaktes die Software plötzlich meint, eine Konfiguration vor sich zu haben, die so gar nicht zur tatsächlich angeschlossenen passen will?

​

Das wäre völlig irrelevant, weil sich die einmal erkannte Konfiguration nicht mehr ändern würde.

Also, ich wollte nur einen Denkanstoß geben, nicht die Applikation und Lösung präsentieren. Für die Umsetzung ist immer noch der Programmierer verantwortlich - nicht ich. Aber nach 15 Jahren Erfahrung kann ich sagen, das es auch für solche Konstrukte durchaus Anwendungen gibt.

Übrigens, "Hardware-Eingang vorhanden, aber nicht angeschlossen" - für dieses Szenario ist mein Vorschlag völlig unpassend. Damit dürfte die Frage nach Drahtbruch usw. sich erübrigen.

 

[Guga]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich verweise noch mal auf den Lösungsansatz in meinem Beitrag oben (#4). Gefühlt ist er untergegangen.
Stichwort: Lösung über Compiler-Attribut von 3S.

Guga

 

[Heinileini]

Das wäre völlig irrelevant, weil sich die einmal erkannte Konfiguration nicht mehr ändern würde.
...
Übrigens, "Hardware-Eingang vorhanden, aber nicht angeschlossen" - für dieses Szenario ist mein Vorschlag völlig unpassend. Damit dürfte die Frage nach Drahtbruch usw. sich erübrigen.

Ja, ich denke wir gehen von ganz unterschiedlichen AnwendungsFällen aus und reden dadurch automatisch aneinander vorbei.
Du denkst an eine Projektierung der "Hardware" am PG, womit ein Abbild der Struktur quasi im Speicher festgelegt wird. Die "Software" soll diese auswerten.
Was mir vorschwebt, ist eine physikalisch vorhandene Hardware, an der wahlweise Baugruppen unterschiedlicher Ausstattung angeschlossen werden bzw. ausgewechselt werden können, so dass die "Software" sich den sich ändernden Gegebenheiten anpassen müsste.

 

[wollvieh]

Wie wäre es mit cloud computing, oder das Orakel von Delphi befragen ... Im Ernst, sind das die Probleme der Programmierung? EVA Prinzip gilt auch heute noch, Eingabe, Verarbeitung, Ausgabe.

 

[Jörn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hätte folgenden Ansatz im Angebot:

https://help.codesys.com/api-content/2/codesys/3.5.16.0/en/_cds_pragma_attribute_is_connected/
Achtung:
- nicht in TwinCAT dokumentiert deshalb ohne Gewähr.
- gerade eben mit der 4024.7 an dem Beispiel vom Link ausprobiert, hier funktioniert es. Die Chance das es mit der 4022.x funktioniert schätze ich als sehr unwahrscheinlich ein.

Moin allesamt,

vielen Dank für die vielen Antworten. Der Tipp von Guga erzielt genau das gewünschte Ergebnis - ich habs eben mit meinem Build 4024.0 ausprobiert!

Als kleine Ergänzung:

ConvNo1_Test.ixIsLiftPresent := TRUE;   // So funktioniert es nicht ...
ConvNo1_Test();

ConvNo2_Test(ixIsLiftPresent := TRUE);  // ... aber so funktioniert es!

Gruß
Jörn