Schnittstelle zwischen IO´s und Programm

Bensen83

Well-known member
Beiträge
777
Punkte Reaktionen
3
Zuviel Werbung?
->Hier kostenlos registrieren
Hallo alles zusammen ;-)

Habe mal eine Grundsätzliche Frage.
Bei größeren Maschinen kann es schon bei kleineren Änderungen in der elektrischen Hardware schon mal größere daraus folgende IO änderungen geben ;-)
um dieser Geschichte zu entkommen, hatte ich es bis jetzt immer so gehandhabt (Mit Siemens), dass ich als erstes in meinem Programm die eingänge eingelesen habe, diese Variablen zugewiesen habe
und die entsprechenden ausgänge am zyklusende ausgehend von den entsprechenden Variablen zugewiesen wurden.

So musst eich bei einer Hardwareänderung nur die zuordnung einmalig anpassen und nicht noch überall im programm was tun.
as haltet ihr von einem solchen System? Gibts da bei codesys noch was eleganteres?

Bzw. wie verhält sich soetwas bei schnellen ein bzw. ausgängen?

hat jemand ne idee, was da so die beste vorgehensweise ist?
doch imer direkt io´s verwenden? oder was genau muss ich machen? ;-)
 

Larry Laffer

Supermoderator
Teammitglied
Beiträge
13.148
Punkte Reaktionen
2.745
Hallo,
direkt mit den IO's zu arbeiten ist mit Sicherheit der beste Weg.
Man könnte z.B. für E/A's mit gleicher Funktion immer den gleichen symbolischen Namen vergeben. Dann übernimmt das System den Rest - das ginge auch mit Siemens ...

Gruß
Larry
 

mkd

Well-known member
Beiträge
197
Punkte Reaktionen
30
Zuviel Werbung?
->Hier kostenlos registrieren
Ich kann mich Larry nur anschließen.
Wo ist bei symbolorientierter Programmierung das Problem ?

Wir Verknüpfen im Sys Manager nur ganze Bytes, die Zuweisung der einzelnen Bits geschieht dann nur noch in der PLC Variablendeklaration.

Code:
InputByte0 AT %IB0:BYTE; (*Verknüpft im System Manager*)

eTasterStart AT %IX0.0: BOOL;
eTasterStopp AT %IX0.1: BOOL;

Wenn jetzt die Taster elektrisch vertauscht werden, muss man nur die Deklaration der Symbole im Programm ändern.
 
OP
B

Bensen83

Well-known member
Beiträge
777
Punkte Reaktionen
3
Falsch gedacht

Sorry hatte falsch gedacht. Klar bei symbolisch ist das ja bei codesys gar kein Thema. Bei Siemens hatten wir das damals gemacht, weil Manche die adressierte Ansicht hatten und dadurch gab es dann Probleme. Denn auch wenn man es auf symbolisch hatte, wurde der symbolname ersetzt, wenn man ihn in der Deklaration geändert hat.
 

Oberchefe

Well-known member
Beiträge
2.661
Punkte Reaktionen
478
Denn auch wenn man es auf symbolisch hatte, wurde der symbolname ersetzt, wenn man ihn in der Deklaration geändert hat.

Der Operandenvorrang läßt sich einstellen, dann passiert das nicht mehr. Nachteil ist dann nur noch dass man bei manchen Änderungen die ganze Scheiße wieder übersetzen muss weill sonst die Konsistenzprüfung rum meckert.
 

LargoD

Well-known member
Beiträge
588
Punkte Reaktionen
160
Ok lässt sich einstellen, aber jetzt hat jemand anders das Projekt im Step 7 geöffnet der das nicht hat und schon zerschießt er das Projekt.
Falsch.
Wenn nach Änderung der Adresszuordnung das Projekt einmal mit Operandenvorrang symbolisch übersetzt wurde, passt wieder alles, egal was der nächste als Operandenvorrang eingestellt hat.
Gruß
Erich
 

Oberchefe

Well-known member
Beiträge
2.661
Punkte Reaktionen
478
Falsch.
Wenn nach Änderung der Adresszuordnung das Projekt einmal mit Operandenvorrang symbolisch übersetzt wurde, passt wieder alles, egal was der nächste als Operandenvorrang eingestellt hat.

abgesehen davon wird die Einstellung zusammen mit dem Projekt abgespeichert, der nächste der das Projekt öffnet hat die "richtige" Einstellung
 

Majestic_1987

Well-known member
Beiträge
270
Punkte Reaktionen
22
Zuviel Werbung?
->Hier kostenlos registrieren
Ich weiß ja nicht, was du konkret mit "größere I/O-Änderungen" meinst, jedoch würde ich folgendes Vorschlagen, gesetzt den Fall, wir reden über TwinCAT:

1. Deklaration im SPS-Programm mit AT %I* bzw. AT %Q*
2. Zuweisung der entsprechenden Variablen zu den I/O-Punkten im System-Manager
3. Bei Änderung: System-Manager auf, Verknüpfung der betroffenen I/O-Punkte anpassen, Konfiguration speichern, übersetzen, laden. Fertig.

Ob man den "Umweg", im Projekt Byteweise zu deklarieren, gehen will, weiß ich nicht. Finde das eher unpraktisch, weil man damit dann doch wieder eine nicht zwingend notwendige absolute Adressierung erschafft. Wenn sich im o.g. Beispiel von mkd nämlich ein Taster von einer Eingangsklemme in eine andere verschiebt (warum auch immer), dann müsste er erstens im Programm den Taster aus dem einen Byte rausnehmen, dann schauen, in welchem Byte er nun liegt und diese Verknüpfung wieder anfassen. Mit "meiner" Variante spart man sich in dem Fall Arbeit, weil man einfach nur im SysMan die Verknüpfung der PLC-Variablen anfasst.

Wenn natürlich Verschiebungen nur Byteweise auftreten, ist mkd's Version schneller.

Ich persönlich bevorzuge es, mich eben nicht mehr um irgendwelche Adressen zu kümmern. Wozu auch? Mich interessiert letztlich nur, dass meine Variable auf die richtige Klemme reagiert. Wo das im Arbeitsspeicher rumliegt oder im ESC oder sonstwo juckt mich weniger xD
 
OP
B

Bensen83

Well-known member
Beiträge
777
Punkte Reaktionen
3
Siemens

Ich hatte von Siemens gesprochen.

Sorry, aber da kann jemand schreien dass es funktioniert und ich Sage es funktioniert nicht. Wir habe uns so schon mal ein s7 Projekt zerschossen. 😉
 

mkd

Well-known member
Beiträge
197
Punkte Reaktionen
30
Ob man den "Umweg", im Projekt Byteweise zu deklarieren, gehen will, weiß ich nicht. Finde das eher unpraktisch, weil man damit dann doch wieder eine nicht zwingend notwendige absolute Adressierung erschafft. Wenn sich im o.g. Beispiel von mkd nämlich ein Taster von einer Eingangsklemme in eine andere verschiebt (warum auch immer), dann müsste er erstens im Programm den Taster aus dem einen Byte rausnehmen, dann schauen, in welchem Byte er nun liegt und diese Verknüpfung wieder anfassen. Mit "meiner" Variante spart man sich in dem Fall Arbeit, weil man einfach nur im SysMan die Verknüpfung der PLC-Variablen anfasst.

Wenn natürlich Verschiebungen nur Byteweise auftreten, ist mkd's Version schneller.

Du hast "meine" Vorgehensweise wohl nicht verstanden.

Die Variante hat ja gerade den Vorteil das man bei E/A Änderungen und Erweiterungen die Konfiguration NICHT neu Würfeln muss.
Man kann die Änderung also quasi im laufenden Betrieb vornehmen.

Es geht auch nicht um ganze verschobene Bytes. Sagen wir mal, du verknüpfst alle Eingangskarten mit entsprechen deklarirten Bytes, dann besteht die Verknüfung nur zwischen diesen beiden Welten.
Die Addressierung der Bits greift ja auf die bereits verknüpften Bytes und im Logikprogramm wird das Symbol verwendet.

Alle Klarheiten beseitigt?
 
Oben