Mehrere Verbindungen über Ethernet mit FC5/FC6 AG_SEND/AG_RECV

Atlas

Level-1
Beiträge
65
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen!

Ich möchte eine Kommunikation mit 4 CPU's die alle über einen CP 343-1 Lean in einem Ethernet hängen aufbauen.

Dabei soll der prinzipielle Aufbau der Verbindungen so aussehen, dass eine der Steuerungen als "Kopf-SPS" arbeitet (Diese wird auch alle Verbindungen aufbauen). Alle weiteren CPU's werden ausschließlich mit dieser Kopf-SPS kommunizieren und ihre Daten an diese CPU senden und auch von dieser empfangen.

Aktuell läuft bereits eine Kommunikation über den FC5/FC6 und einer TCP-Verbindung zwischen der Kopf-SPS und einer weiteren CPU. Wie kann ich die Kommunikation realisieren wenn nun noch zwei weitere CPU's hinzu kommen?

Kann ich in der Kopf-SPS einfach für jede CPU einen entsprechenden FC5/FC6 (also 3x hintereinander im selben Zyklus) aufrufen oder darf ich diese FC's nur einmal aufrufen und muss die Verbindungen durchschalten, damit immer nur an eine einzelne CPU gesendet wird und nach abschluss an die nächste...?
 
Zuletzt bearbeitet:
Kann ich in der Kopf-SPS einfach für jede CPU einen entsprechenden FC5/FC6 (also 3x hintereinander im selben Zyklus) aufrufen oder darf ich diese FC's nur einmal aufrufen und muss die Verbindungen durchschalten, damit immer nur an eine einzelne CPU gesendet wird und nach abschluss an die nächste...?
Nein, du kannst alle gleichzeitig aufrufen.

Und daran denken, falls an der Kopf-SPS noch mehrere CPU's angehängt werden sollen, der Lean kann nur 8 Verbindungen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nachtrag:

Es gibt natürlich einen Unterschied zwischen dem zyklischen Aufruf des Bausteines und dem Sendeanstoß des FC5.
Der Sendeanstoß sollte nur erfolgen wenn kein aktueller Auftrag läuft und dann würde ich auch nur alle paar hundert Millisekunden erneut senden.
Sonst bekommt der CP seine Päckchen nicht mehr weg. ;)
Also nach dem Motto > weniger ist mehr. :D
 
Der Sendeanstoß sollte nur erfolgen wenn kein aktueller Auftrag läuft und dann würde ich auch nur alle paar hundert Millisekunden erneut senden.
Diesen Rat gelt "pro Verbindung", oder ?
Sonnst stimme ich dir ganz zu.
Mann muss auch bedenken das bei allen CPs für S7-300 den ganzen Verkehr über den langsahmen Rückwandbus passieren muss.
 
Ich stoße das senden aktuell mit einem 1HZ Taktmerker an... Reicht bis jetzt eigentlich aus von der Geschwindigkeit und wenn nötig wär sicher auch noch schneller möglich...

Wenn ich Euch nun richtig verstehe, kann ich für jede weitere CPU die an meiner Kopf-SPS hängt einen eigenen FC5 und FC6 aufrufen die dann theoretisch alle gleichzeitig Daten zum versenden bereitstellen bzw. diese empfangen?

Das mit dem Limit von 8 ist mir bekannt. Aktuell ist noch nicht in sicht, dass dieses Limit erreicht wird :)
 
In der "Kopf" CPU paramentrierst du ja alle Verbindungen in Net mit aktiven Verbindungsaufbau . Wie Paule schon gesagt hat muss jeder Verbindung eine eigene ID zugewiesen werden .
Auch das die Nacheinander aufgebaut werden und die Telegramme nicht zyklisch sondern in Reihenfolge gesendet werden . Also nutze am besten ein Bit das du von der jeweiligen Verbindung ein Telegramm empfangen hast . Erst dann solltest du die nächste Verbindung anstoßen . Wenn du dieses nicht machst , kann es passieren das sich die ganze Kommunikation aufhängt .
Dieses kann insbesondere bei Neustart der CPU´s auftreten .
 
Zuletzt bearbeitet:
Also nutze am besten ein Bit das du von der jeweiligen Verbindung ein Telegramm empfangen hast . Erst dann solltest du die nächste Verbindung anstoßen . Wenn du dieses nicht machst , kann es passieren das sich die ganze Kommunikation aufhängt .
Dieses kann insbesondere bei Neustart der CPU´s auftreten .
Tatsächlich? :confused:
Also ich synchronisiere meine AG_SEND und AG_RECV nicht zwischen den verschiedenen Verbindungen und habe noch nie ein Problem damit gehabt.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Synchronisieren erledigen die FC5/FC6 schon selber, meine ich. Wenn nicht die Software, dann der CP. In einigen unserer Anlagen läuft die Kommunikation über ein statisches TRUE am ACT der FC's. Die Aufrufe dann einfach im Zeit-OB (OB32,33 usw.)
Übrigens gibt es eine bequeme Möglichkeit, Verbindungen in die CPU zu laden, ohne diese in stopp nehmen zu müssen:
Im NetPro die CPU markieren -> Zielsystem ->Laden im aktuellen Projekt ->Verbindungen und Netzübergänge. Und ZACK! Drin.

Gruß Approx
 
Zitat von Paule
Der Sendeanstoß sollte nur erfolgen wenn kein aktueller Auftrag läuft und dann würde ich auch nur alle paar hundert Millisekunden erneut senden.
Diesen Rat gelt "pro Verbindung", oder ?
Ja genau, pro Verbindung.
Und wie Harald und Approx auch sagen, der CP synchronisiert die Aufträge ja selbst.

@Approx, du meinst die CPU geht nicht mehr in stopp?
Übrigens gibt es eine bequeme Möglichkeit, Verbindungen in die CPU zu laden, ohne diese in stopp nehmen zu müssen:
Im NetPro die CPU markieren -> Zielsystem ->Laden im aktuellen Projekt ->Verbindungen und Netzübergänge. Und ZACK! Drin.
Danke, das wusste ich noch nicht. :D
Ich habe die CPU bis dato immer über das NetPro in den Stopp gezwungen.
Werde es bald mal ausprobieren.
 
Hi,
ich würde die Clients aktiv die Verbindung zur Kopfstation aufbauen lassen.
Da braucht die Kopfstation im Wartungsfall nicht ständig einen fehlenden Teilnehmer zu suchen.

Gruß
Klaus
 
Übrigens gibt es eine bequeme Möglichkeit, Verbindungen in die CPU zu laden, ohne diese in stopp nehmen zu müssen:
Im NetPro die CPU markieren -> Zielsystem ->Laden im aktuellen Projekt ->Verbindungen und Netzübergänge. Und ZACK! Drin.
Konnte das heute endlich mal probieren und ja, es funktioniert.
Der CP setzt kurz aus aber die CPU arbeitet weiter. :D
Allerdings stimmen dann bei einem Vergleich die Systemdaten nicht. :cry:
Darum ist diese Lösung (für mich) für Testzwecke ganz nett, aber keine Endlösung, denn wenn bei einem Bausteinvergleich "Unterschiede bei den Systembausteinen" rauskommt, bekomme ich irgendwie Kopfschmerzen. ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Darum ist diese Lösung (für mich) für Testzwecke ganz nett, aber keine Endlösung, denn wenn bei einem Bausteinvergleich "Unterschiede bei den Systembausteinen" rauskommt, bekomme ich irgendwie Kopfschmerzen. ;)
Bei Unterschiedlicher Länge vom Systembaustein 999, oder 1000 bekomme ich keine Kopfschmerzen mehr ;). Schlimmer wird es, wenn unterschiedliche Parameter gemeldet werden. Bei unseren Anlagen kommt man eben nicht oft dazu, diese zum Laden in stopp nehmen zu können. Deshalb bin ich froh darüber, das man auch so eine Kommunikation aufbauen kann. Und ich überlege dreimal was ich tue - Produktion lahmlegen findet niemand so witzig. :ROFLMAO:
 
Zurück
Oben