Schnittstelle zwischen IO´s und Programm

[Bensen83]

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]

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]

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.

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.

 

[Bensen83]

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]

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.

 

[Bensen83]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok

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. Egal habe ja jetzt eh codesys.

 

[LargoD]

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]

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]

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

 

[Bensen83]

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]

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?