TIA S7 Kommunikation PUT/GET/i-Device

[itsdarkdownhere]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich muss jetzt tatsächlich nochmal nachfragen.

Wenn ich in meinem Transferbereich bspw. Byte Q100 => I100 festlege und im IO-Controller einer boolschen Variablen die Adresse Q100.0 und im I-Device eine Variable mit der Adresse I100.0 zuordne, bekomme ich keinen Bit übertragen.

Was übersehe ich hierbei?

 

[MFreiberger]

Ich muss jetzt tatsächlich nochmal nachfragen.

Wenn ich in meinem Transferbereich bspw. Byte Q100 => I100 festlege und im IO-Controller einer boolschen Variablen die Adresse Q100.0 und im I-Device eine Variable mit der Adresse I100.0 zuordne, bekomme ich keinen Bit übertragen.

Was übersehe ich hierbei?

Das hört sich aber nicht wie PUT/GET an!?
Eher wie iDevice...

 

[Nordischerjung]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

Hardware in beiden Steuerungen übertragen? Zeig doch mal Screenshots.

 

[itsdarkdownhere]

Das hört sich aber nicht wie PUT/GET an!?
Eher wie iDevice...

Es geht auch in der Tat um iDevice.
Ursprünglich ging es in diesem Thread um PUT/GET, bin dann aber auf iDevice aufmerksam gemacht worden. Dies wurde die letzten Posts auch besprochen.

Der Titel ist nun natürlich etwas irreführend.

 

[itsdarkdownhere]

Im Anhang die Screenshots.
Einfach nur ein kleines Programm um die iDevice-Funktionalität zu testen.
Wenn ich in PLCsim den physischen Eingang steuere, wird der Wert über den Ausgang Q100.0 nicht an I100.0 im i-Device übergeben.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Im Anhang die Screenshots.
Einfach nur ein kleines Programm um die iDevice-Funktionalität zu testen.
Wenn ich in PLCsim den physischen Eingang steuere, wird der Wert über den Ausgang Q100.0 nicht an I100.0 im i-Device übergeben.

Profinet-Kommunikation kann in der PLCsim nicht simuliert werden.

 

[itsdarkdownhere]

Profinet-Kommunikation kann in der PLCsim nicht simuliert werden.

Vielen Dank!

Wieder etwas dazu gelernt. Dann werde ich das mal mit Hardware testen.

 

[Januar]

PLCSim Advanced sollte das aber können, wenn mich meine Erinnerung nicht im Stich lässt ?

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

PLCSim Advanced sollte das aber können, wenn mich meine Erinnerung nicht im Stich lässt ?

Ich meine nicht. OPC UA und TCP/IP gehen. Aber keine E/A-basierten Protokolle.

 

[DCDCDC]

Ich lege den Idevice Bereich immer ans Ende der E/A Bereiche, so kommt am wenigstens etwas quer. Lieber etwas mehr für die Kommunikation freihalten als zu wenig, so hast du dann mehr Spielraum im Lebenszyklus der Anlage. Es muss nämlich bei jeder Bereichsänderung die Hardware in beiden Partnern neu übertragen werden.

Hier noch mal Beispiele von Siemens zum Aufbau der Kommunikation, auch für Safety Geschichten

SIOS

support.industry.siemens.com

Ich realisiere auch immer einen Handshake des Lebensbits, d.h. beide Teilnehmer setzen und rücksetzen sich gegenseitig das Lebensbit, so siehst du direkt ob die Kommunikation steht, oder nicht und kannst so einen Kommunikationsabbruch erkennen und dementsprechend handeln

 

[itsdarkdownhere]

Danke für eure Hilfe!

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Profinet-Kommunikation kann in der PLCsim nicht simuliert werden.

... Es muss nämlich bei jeder Bereichsänderung die Hardware in beiden Partnern neu übertragen werden...

... Kommunikationsabbruch erkennen ...

Drei Punkte für Put & Get oder an jede andere S7-Kommunikation. Bei einer CPU/CPU-Kommunikation würde ich immer eine S7-Kommunikation gegenüber PN vorziehen, solange es nicht in Echtzeit schnackseln muss.

 

[MFreiberger]

Bei einer CPU/CPU-Kommunikation würde ich immer eine S7-Kommunikation gegenüber PN vorziehen, solange es nicht in Echtzeit schnackseln muss.

Moin Onkel,
warum würdest Du das tun? Wegen dem Hardwareladen oder gibt es weitere Gründe?

BTW: bei einer F-Kommunikation würde ich PN vorziehen.

 

[DCDCDC]

Drei Punkte für Put & Get oder an jede andere S7-Kommunikation. Bei einer CPU/CPU-Kommunikation würde ich immer eine S7-Kommunikation gegenüber PN vorziehen, solange es nicht in Echtzeit schnackseln muss.

Wollte nur noch mal herausstellen, dass es sich auf längere sicht lohnen kann, etwas mehr Reserve einzuplanen als nur die Signale die aktuell notwendig sind.. Anlagen und Maschinen wachsen gerne historisch in Sachen Funktionalität

 

[circlehook]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da mit Put/Get eigentlich nicht kontrolliert werden kann, was die fremde SPS macht, ist das das Ausschlusskriterium für mich.

 

[Onkel Dagobert]

Moin Onkel,
warum würdest Du das tun? Wegen dem Hardwareladen oder gibt es weitere Gründe? ...

Hardwareladen ist sicherlich der Hauptgrund. Aber auch die Konfiguration ist vergleichsweise aufwändig. Dann belegen PN-Schnittstellen Hardwareadressen. Wie teilt man diese auf? Sollte man Adresslücken lassen oder nicht? Wenn ja, wieviel? Bei komplexen Anlagen kommt man dann schon mal in Bedrängnis. Dann hat man oftmals eine zentrale SPS, welche mit zig anderen kommuniziert. Geht diese (u.a.) wegen Hardwareladen auf Stopp, stehen Produktionsanlagen, da von irgendwelchen Folgeprozessen der Watchdog ausbleibt. Hier ist man mit S7-Kommunikation wesentlich flexibler unterwegs, wobei die verschiedenen S7-Kommunikationen von "quick & dirty" bis "very big" alle ihre Berechtigung haben. Profinet hat natürlich auch seine Berechtigung, dort wo es hin gehört.

 

[itsdarkdownhere]

Was fällt denn genau unter S7-Kommunikation? Put/Get, UDP und TCP?

Oder auch die gängigen Feldbusse Profinet, Profibus, Modbus, MPI bzw. RS485?

 

[Ludewig]

Zuviel Werbung?
-> Hier kostenlos registrieren

SIOS

support.industry.siemens.com