Wir verwenden CodDeSys V3.3 und suchen nache einer einfachen Möglichkeit die Eingänge zu simulieren, wenn keine Hardware-IO's zur Verfügung stehen. Die Verknüpfung der Variablen auf die Hardware erfolgt mittels GVL.
Projektaubau sieht in etwa so aus:
Funktkionsbaustein in welchem der digitale Eingang definiert wird:
FB - fbMachineControlModul
VAR
diFuseCabinetAirOk AT %I* : BOOL;
END_VAR
Task in welchem der Funktionsbaustein instanziert wird:
PRG - PLC_PRG
MachineControl : fbMachineControlModul;
Verknüpfung mit der Hardware über GVL Liste:
GVL - GVL_IO_MAPPING
VAR_CONFIG
PLC_PRG.MachineControl.diFuseCabinetAirOk AT %IX0.0 : BOOL;
END_VAR
Problem 1:
"Forcen" dieser lokalen Variablen (PLC_PRG.MachineControl.diFuseCabinetAirOk) funktioniert nicht. Wird im Online-Modus die Variable auf TRUE "geforcet", dann wird sie zwar als TRUE angezeigt aber nicht als TRUE ausgewertet. Der Programmteil wird 100%ig durchlaufen.
Problem 2:
Wir möchten die Eingänge (Entweder die Adressen oder die lokale Variable) mittels Simulation überschreiben. Die Simulation wäre ein Objekt im bestehenden Projekt (Programm, Baustein, Applikation oder Sub-Applikation ....) und würde optional hinzucompiliert.
Wie kann Problem 2 gelöst werden, bzw. kann es überhaupt gelöst werden? Wenn Problem 2 gelöst wäre, wäre somit auch gleich Problem 1 erschlagen.
Vielen Dank für allfällige Tipps.
Lucien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-07-29
Originally created by: ebt'ler
Du könntest es mal mit Pointern versuchen, ich habe aber noch nicht versucht damit Eingänge zu überschreiben. Es könnte jedoch durchaus möglich sein.
Mit der Hardware-Adresse (Bsp. Digitaler Eingang auf IX0.0 und pt: POINTER TO BOOL) hat so nicht funktioniert. Entweder hat es damit zu tun, dass der EA Zyklus ja vor dem Simulationaufruf erfolgt und dadurch die lokale Variable vom FB nicht mehr aktualisiert wird oder ich mache was mit der Adressierung falsch (CoDeSys ist relaitiv neu für mich und die ganze Adressierung verwirrt mich noch etwas).
Dein Tip hat mich aber auf die Idee gebracht nicht die Adresse mittels Pointer anzusteuern, sondern direkt die lokale Variable vom FB.
Simulaitons-Program, welches vor dem eigentlichen Programm aufgerufen wird:
pt: POINTER TO BOOL;
bTest: BOOL;
pt := ADR(PLC_PRG.MachineControl.diFuseCabinetAirOk);
pt^:=bTest;
Diese Lösung ist sogar noch besser als die Verwendung der IO-Adressen.
Grund:
Wir haben die Absicht die Projetke über SVN zu versionieren und die IO-Verknüpfungsliste GVL_IO_MAPPING wäre kundenspezifisch. Wenn wir in der Simulation die IO-Adressen verwenden würden, wäre somit auch die Simulation kundenspezifisch. Durch die Verwendung der lokalen IO-Variablen vom FB könne wir diese Problem aber umgehen.
Vielen Dank für deinen Tipp mit den Pointer.
Gruss
Lucien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-07-30
Originally created by: ebt'ler
Mit V3.x habe ich mich auch noch nicht auseinandergesetzt, darum kann ich dir keine genaue Lösung nennen. Bei V2.x ist es jedenfals nicht möglich Bitadressen (Hardware) direkt über ADR zu adressieren. Da die Hardwareadressen fortlaufend byteweise hochgezählt werden. Was einen Bitzugriff nicht ermöglicht.
Dadurch ist ein kleiner Umweg über BITADR und Schiebefunktionen nötig.
Wie das bei V3.x umgesetzt wird weiß ich wie gesagt nicht genau.
Aber die testweise Überschreibung müsste auf alle Fälle am Zyklusanfang geschehen.
Aber ich denke du kommst damit klar, also viel Erfolg.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-08-02
Originally created by: Bernhard Werner
Das ist richtig: es gibt nach wie vor keine Pointer auf Bits (das geht aus technischen Gründen auf normalen Prozessoren nicht). Dabei wird immer das gesamte Byte addressiert!
Will man daher Inputs über Pointer beschreiben, verwendet man am einfachsten Bitadressierung:
pbyteIn1 := ADR(%IB0);
pbyteIn1.0 := TRUE; // hier hängt es natürlich vom Prozessor ab, welches Bit mit welcher Wertigkeit
// angesprochen wird, das alte Endianness-Problem
[Hinweis: Quatsch gelöscht!]
Bernhard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2010-08-02
Originally created by: Bernhard Werner
Jetzt war ich kurzzeitig verwirrt:
Es ist tatsächlich so: das IO-Update erfolgt ganz am Anfang des Task-zyklus und mit Programmiermitteln hat man im Moment keine Chance vor dem Update auf das IO-Abbild zu schreiben.
Wenn aber, wie in deinem Fall, keine direkten Adressen im Programm verwendet werden, sondern die Konfigurationsaddressen direkt auf bestehende Variablen gemappt werden, dann ist es auf alle Fälle besser, den Simulationscode für diese Variablen zu schreiben, so wie du das vorhast.
Bernhard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Die Simulation funktioniert einwandfrei. Momentan geht es uns nur darum, die Eingänge manuell zu überschreiben und dass bestimmte Eingänge bei Programmstart auf Default-Werte gesetzt werden.
Mit diesem Prinzip haben wir folgende Features:
- Default-Werte der Eingänge können im Deklarationsteil des PRG-Simulation eingestellt werden und werden somit beim Programmstart jedesmal "geladen".
- Online können alle Eingänge geändert werden indem die Werte der lokale Variable in PRG-Simulation geändert werden. Diese werden ja dann auf die lokale Variablen des PRG-Maschine kopiert.
- Die Simulation ist unabhängig von Hardware-Adressen und bleibt identisch auch wenn Eingänge "verschoben" werden.
- Die Simulation ist unabhängig vom verwendeten Bussystem. Wir setzen EtherCat und CanBus ein.
- Wir könnten sogar Funktionsbausteine in PRG-Simulation einbauen, welche auf die Ausgänge "reagieren" und dementsprechend die Eingänge setzen. Echte Simulation der Maschine....
Danke für die Infos
Lucien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jetzt haben sich die Entwickler so angestrengt, dass auf Eingänge nicht geschrieben werden kann. Ist ja bei anderen, z.B. bei S7 nicht so.
Und jeder Anwender muss wieder einen Weg finden dies zu umgehen, um eine sinnvolle Simulation durchführen zu können.
Ist schon igendwie paradox.
Da ich Umsteiger von S7 bin, war ich mit der gleichen Problematik kofrontiert.
Meine derzeitige Lösung sieht so aus, dass ich für jede Eingangsvariabe auch eine Prozessvariable definiere.
Der Prozessvariablen kann ich auch gleich einen Wert zuweisen, welcher im Of-Betrieb als Voreinstellung gilt.
GVL Eingang:
eLIC010nStart AT %IX10.0 : BOOL ; // E 10.0 010/2.1 Entfettung Signal = 0 Befüllung start
GVL Prozessvariable
_LIC010nStart : BOOL := TRUE ; // E 10.0 010/2.1 Entfettung Signal = 0 Befüllung start
Programmteil nur in Online
GVL._LIC010nSwitart := GVL.eLIC010nStart ; // Eingang auf Prozessvariable schreiben
Programmteil nur Ofline bzw. Simulation
Programmteil nur Ofline bzw. Simulation
GVL._intEingang := REAL_TO_INT(GenSinus(REAL, rZahl:=5)) ; // Beispiel um etwas Bewegung in die Simulation zu bringen
Eure Lösung sieht ähnlich aus. Dies sollte auch unabhängig von der Version sein. Unsere Anlage läuft unter V3.4
Die Listen schreibe ich in Excel und kann durch einmalige Eingabe alle drei Listen bzw. Programmteile erzeugen lassen.
Gut dass der Anwender manchmal unterschätzt wird, aber so ist es des öfteren zwischen Theorie und Praxis.
Weiterhin viel Erfolg.
Gruß von Rainer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Salü zäme,
Wir verwenden CodDeSys V3.3 und suchen nache einer einfachen Möglichkeit die Eingänge zu simulieren, wenn keine Hardware-IO's zur Verfügung stehen. Die Verknüpfung der Variablen auf die Hardware erfolgt mittels GVL.
Projektaubau sieht in etwa so aus:
Funktkionsbaustein in welchem der digitale Eingang definiert wird:
FB - fbMachineControlModul
VAR
diFuseCabinetAirOk AT %I* : BOOL;
END_VAR
Task in welchem der Funktionsbaustein instanziert wird:
PRG - PLC_PRG
MachineControl : fbMachineControlModul;
Verknüpfung mit der Hardware über GVL Liste:
GVL - GVL_IO_MAPPING
VAR_CONFIG
PLC_PRG.MachineControl.diFuseCabinetAirOk AT %IX0.0 : BOOL;
END_VAR
Problem 1:
"Forcen" dieser lokalen Variablen (PLC_PRG.MachineControl.diFuseCabinetAirOk) funktioniert nicht. Wird im Online-Modus die Variable auf TRUE "geforcet", dann wird sie zwar als TRUE angezeigt aber nicht als TRUE ausgewertet. Der Programmteil wird 100%ig durchlaufen.
Problem 2:
Wir möchten die Eingänge (Entweder die Adressen oder die lokale Variable) mittels Simulation überschreiben. Die Simulation wäre ein Objekt im bestehenden Projekt (Programm, Baustein, Applikation oder Sub-Applikation ....) und würde optional hinzucompiliert.
Wie kann Problem 2 gelöst werden, bzw. kann es überhaupt gelöst werden? Wenn Problem 2 gelöst wäre, wäre somit auch gleich Problem 1 erschlagen.
Vielen Dank für allfällige Tipps.
Lucien
Originally created by: ebt'ler
Du könntest es mal mit Pointern versuchen, ich habe aber noch nicht versucht damit Eingänge zu überschreiben. Es könnte jedoch durchaus möglich sein.
(V2.3 Syntax, eventuell anpassen!)
Salü ebt'ler,
Mit der Hardware-Adresse (Bsp. Digitaler Eingang auf IX0.0 und pt: POINTER TO BOOL) hat so nicht funktioniert. Entweder hat es damit zu tun, dass der EA Zyklus ja vor dem Simulationaufruf erfolgt und dadurch die lokale Variable vom FB nicht mehr aktualisiert wird oder ich mache was mit der Adressierung falsch (CoDeSys ist relaitiv neu für mich und die ganze Adressierung verwirrt mich noch etwas).
Dein Tip hat mich aber auf die Idee gebracht nicht die Adresse mittels Pointer anzusteuern, sondern direkt die lokale Variable vom FB.
Simulaitons-Program, welches vor dem eigentlichen Programm aufgerufen wird:
pt: POINTER TO BOOL;
bTest: BOOL;
pt := ADR(PLC_PRG.MachineControl.diFuseCabinetAirOk);
pt^:=bTest;
Diese Lösung ist sogar noch besser als die Verwendung der IO-Adressen.
Grund:
Wir haben die Absicht die Projetke über SVN zu versionieren und die IO-Verknüpfungsliste GVL_IO_MAPPING wäre kundenspezifisch. Wenn wir in der Simulation die IO-Adressen verwenden würden, wäre somit auch die Simulation kundenspezifisch. Durch die Verwendung der lokalen IO-Variablen vom FB könne wir diese Problem aber umgehen.
Vielen Dank für deinen Tipp mit den Pointer.
Gruss
Lucien
Originally created by: ebt'ler
Mit V3.x habe ich mich auch noch nicht auseinandergesetzt, darum kann ich dir keine genaue Lösung nennen. Bei V2.x ist es jedenfals nicht möglich Bitadressen (Hardware) direkt über ADR zu adressieren. Da die Hardwareadressen fortlaufend byteweise hochgezählt werden. Was einen Bitzugriff nicht ermöglicht.
Dadurch ist ein kleiner Umweg über BITADR und Schiebefunktionen nötig.
Wie das bei V3.x umgesetzt wird weiß ich wie gesagt nicht genau.
Aber die testweise Überschreibung müsste auf alle Fälle am Zyklusanfang geschehen.
Aber ich denke du kommst damit klar, also viel Erfolg.
Originally created by: Bernhard Werner
Das ist richtig: es gibt nach wie vor keine Pointer auf Bits (das geht aus technischen Gründen auf normalen Prozessoren nicht). Dabei wird immer das gesamte Byte addressiert!
Will man daher Inputs über Pointer beschreiben, verwendet man am einfachsten Bitadressierung:
pbyteIn1 := ADR(%IB0);
pbyteIn1.0 := TRUE; // hier hängt es natürlich vom Prozessor ab, welches Bit mit welcher Wertigkeit
// angesprochen wird, das alte Endianness-Problem
[Hinweis: Quatsch gelöscht!]
Bernhard
Originally created by: Bernhard Werner
Jetzt war ich kurzzeitig verwirrt:
Es ist tatsächlich so: das IO-Update erfolgt ganz am Anfang des Task-zyklus und mit Programmiermitteln hat man im Moment keine Chance vor dem Update auf das IO-Abbild zu schreiben.
Wenn aber, wie in deinem Fall, keine direkten Adressen im Programm verwendet werden, sondern die Konfigurationsaddressen direkt auf bestehende Variablen gemappt werden, dann ist es auf alle Fälle besser, den Simulationscode für diese Variablen zu schreiben, so wie du das vorhast.
Bernhard
Salü Bernhard,
Die Simulation funktioniert einwandfrei. Momentan geht es uns nur darum, die Eingänge manuell zu überschreiben und dass bestimmte Eingänge bei Programmstart auf Default-Werte gesetzt werden.
Mit diesem Prinzip haben wir folgende Features:
- Default-Werte der Eingänge können im Deklarationsteil des PRG-Simulation eingestellt werden und werden somit beim Programmstart jedesmal "geladen".
- Online können alle Eingänge geändert werden indem die Werte der lokale Variable in PRG-Simulation geändert werden. Diese werden ja dann auf die lokale Variablen des PRG-Maschine kopiert.
- Die Simulation ist unabhängig von Hardware-Adressen und bleibt identisch auch wenn Eingänge "verschoben" werden.
- Die Simulation ist unabhängig vom verwendeten Bussystem. Wir setzen EtherCat und CanBus ein.
- Wir könnten sogar Funktionsbausteine in PRG-Simulation einbauen, welche auf die Ausgänge "reagieren" und dementsprechend die Eingänge setzen. Echte Simulation der Maschine....
Danke für die Infos
Lucien
Hallo zusammen
hab heute euere Formusbeiträge gelesen.
Jetzt haben sich die Entwickler so angestrengt, dass auf Eingänge nicht geschrieben werden kann. Ist ja bei anderen, z.B. bei S7 nicht so.
Und jeder Anwender muss wieder einen Weg finden dies zu umgehen, um eine sinnvolle Simulation durchführen zu können.
Ist schon igendwie paradox.
Da ich Umsteiger von S7 bin, war ich mit der gleichen Problematik kofrontiert.
Meine derzeitige Lösung sieht so aus, dass ich für jede Eingangsvariabe auch eine Prozessvariable definiere.
Der Prozessvariablen kann ich auch gleich einen Wert zuweisen, welcher im Of-Betrieb als Voreinstellung gilt.
GVL Eingang:
eLIC010nStart AT %IX10.0 : BOOL ; // E 10.0 010/2.1 Entfettung Signal = 0 Befüllung start
GVL Prozessvariable
_LIC010nStart : BOOL := TRUE ; // E 10.0 010/2.1 Entfettung Signal = 0 Befüllung start
Programmteil nur in Online
GVL._LIC010nSwitart := GVL.eLIC010nStart ; // Eingang auf Prozessvariable schreiben
Programmteil nur Ofline bzw. Simulation
Programmteil nur Ofline bzw. Simulation
GVL._intEingang := REAL_TO_INT(GenSinus(REAL, rZahl:=5)) ; // Beispiel um etwas Bewegung in die Simulation zu bringen
Eure Lösung sieht ähnlich aus. Dies sollte auch unabhängig von der Version sein. Unsere Anlage läuft unter V3.4
Die Listen schreibe ich in Excel und kann durch einmalige Eingabe alle drei Listen bzw. Programmteile erzeugen lassen.
Gut dass der Anwender manchmal unterschätzt wird, aber so ist es des öfteren zwischen Theorie und Praxis.
Weiterhin viel Erfolg.
Gruß von Rainer