B&R Frage zu Datenaustausch zwischen PP220 und PP45

[Leuchtkeks]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich bin gerade dabei mich etwas in die B&R Steuerungen einzuarbeiten und hab da eine Frage zwecks Datenaustausch.

Folgendes Szenario:

1x PP220 das eine Trocknungsanlage inkl. aller Aggregate steuert.

1x PP45 das als kleine Fernbedienung für das PP220 dienen soll. Hat sonst nix zu tun außer dem PP220 zu sagen "Start da mal das eine Aggregat und sag mir dann Bescheid obs geklappt hat"

Ich dachte zuerst ich mach das entweder mit AsTCP oder AsUDP, aber so wie ich das sehe kann man da als Daten nur einen Pointer auf einen String übergeben, ich verstehe das so das ich dann eben auch nur Strings verschicken kann. Ich will aber ein Array mit 10x BOOL austauschen. Sprich 10 Förderaggregate mit dem aktuellen Zustand, läuft/gestoppt. Vorformatierte String zusammenbasteln, verschicken und dann wieder aufdröseln mach ich eigentlich ungern.

Dann bin ich im Handbuch auf AsIMA bzw. INAcntl gestoßen, so wie ich das verstehe kann ich da auch Strukturen versenden etc.

Nur wie ist das dann mit der Ethernetschnittstelle? ist die dann blockiert oder kann ich da noch weitere Verbindungen aufbauen? Zusätzlich soll das PP220 nämlich per UDP Ist-Werte zyklisch an einen kleinen Server schicken zwecks Protokollierung.

Ich verwende Automation Studio 2.7.0.21 SP14

 

[bits'bytes]

Willkommen Leuchtkeks

Also, du kannst sicher mit AsUDP und TCP Strukturen versenden. Am besten du definierst dir eine Sende-Struktur (im anderen Projekt = Empfangsstruktur) .

Du übergibst immer die Adresse und die Länge, hab jetzt den genauen Aufruf nicht im Kopf, aber irgendwie so....

AsSend (1, .... , &SendeDaten, sizeof(SendeDaten))

Dann brauchst du nur die Struktur ändern (in beiden Projekten !!) und die geänderten Daten werden übertragen.

AsIMA geht auch ganz gut, da schreibst du in die Daten-Tabelle nur die Namen rein und alles wird übertragen.

--
Ethernet kannst du parallel benützen...


ABER,
vielleicht solltest du mal überlegen ob du nur EINE CPU verwenden willst und mit Ethernet einfach eine zweite Visu dranhängen, welche du auf ein Terminal sendest.
In dieser Visu machst du eine Statusanzeige und und einen Startbutton so wie du schreibst.

Dann hast du alle Daten sowieso auf der CPU.

Als zweite Visu würde auch eine VNC funktionieren.

Am besten du klärst das ev. mit dem B&R Vertriebler der dich betreut...

bg
bb

 

[Leuchtkeks]

Zuviel Werbung?
-> Hier kostenlos registrieren

Super Sach, funktioniert

Hab schnell nen Task mit nem kleinen Schrittschaltwerk eingebaut und mit nem Schnüffelstück auf dem lokalen PC getestet, kommen Daten an, der versendet die Struktur ohne meckern

Grad kleine Gedankenklemmer:

Um die Antwort vom Master zu empfangen brauch ich ja keinen zweiten TCP-Socket, ich müsste nach dem Senden nur im Schrittschaltwerk eine Stufe weiterhüpfen und da so lange TcpRecv() ausführen bis was ankommt richtig? Mir schwirrt da grad das Stichwort Race-Condition im Kopf rum. Ich knobel mal weiter, denk das krieg ich hin.



Zum Thema VNC: Das geht so nicht, das ist eine Trocknungsanlage für Getreide und Mais, sprich das ganze steht auf nem großen Bauernhof, und das Silo wo die Fernbedienung dran soll steht draußen im Freien, ein Rugged-Environment Notbuch kostet da garantiert mehr als das kleine PP45, das ich zumal direkt von meinem Arbeitgeber gebraucht kaufen kann.

Das ist nämlich so: Nach dem Trocknen wandert der Mais in eine Kühlzelle. Danach wandert der über diverse Förderaggregate quer durch die Hallen raus in die Silos. Das sind ~50m Fußweg plus nochmal 8m ne Leiter rauf. Du lässt das Auslagern manuell laufen, läufst nach hinten, hoch auf die Leiter, beobachtest das ganze. "Oh, gleich voll". Also Leiter runter, vor laufen, Aggregate abschalten, nach hinten laufen, die Leiter rauf, "Mist, da passt noch was rein", Leiterr unter, nach vorne laufen, Aggregate einschalten, nach hinten laufen, Leiter hoch, warten, "So, jetzt aber", Leiter runter, vor laufen, Aggregate abschalten, nach hinten laufen, Leiter hoch, reingucken zur Kontrolle, "OK, passt", Deckel zu, Leiter runter. Das war dann das erste Silo. Was jetzt kommt kannst du dir ja Denken. Es ist nicht ganz so schlimm wie es sich liest, aber verplemperst halt unnötig Zeit mit Aufpassen.

 

[bits'bytes]

Hi,
ist ja gut wenn zur Abwechslung mal was klappt

VNC muss nicht unbedingt auf einem Lapi laufen, ich denke da an diese Terminals von B&R, sind auch in der notwendigen IP-Kategorie denke ich.

Aber stimmt schon, das PP45 ist halt schon recht günstig, auch wenn du während dem Booten locker einen Kaffee trinken kannst.

Nun egal, wenns so ist dann ist es so...

--

Senden und Empfangen am selben Gerät, bin ich mir nicht sicher.

Du musst ja für die jeweilige Richtung eine IP Adresse und einen Port angeben, oder ?

Wenn du zweimal dieselbe IP Adresse eingibst, funktioniert das vielleicht. Ich würde aber an deiner Stelle gleich 2 Tasks machen, einer für senden, der andere für empfangen. Dann kannst du das leichter auf das zweite Gerät bringen, wenn es soweit ist....

bg
bb

 

[Leuchtkeks]

Senden und Empfangen geht schon. Sende- und Empfangsport müssen halt unterschiedlich sein, die IP ist egal. VirtualHosts bei nem Webserver z.B.

Ich überlege gerade was ich mache. Mehr Overhead mit TCP und Arbeit sparen oder per UDP und zwei Zyklische Objekte, eins fürs Empfangen und eins fürs Senden.

Das sind so wenig Bytes an Daten und das PP220 hat so wenig zu tun, glaub kaum das sich da das TCP-Handling bemerkbar macht. Allerdings widerum auch so wenig Daten das ich keine Bedenken habe das da bei UDP was flöten geht. Ich könnte ja noch ne Checksumme mitschicken und beim Empfänger die nachrechnen und dann vergleichen.

Ich bau das gerade noch ins PP220 ein und mach dann so ne Art Stresstest. Mal bei alle 200ms was senden anfangen und die Zeit so lange runterschrauben bis es kracht, dann hab ich ja nen Anhaltspunkt.

 

[bits'bytes]

Zuviel Werbung?
-> Hier kostenlos registrieren

...Ich könnte ja noch ne Checksumme mitschicken und beim Empfänger die nachrechnen und dann vergleichen.
...

Hi,
ich denke das kannst du dir sparen, die Richtigkeit der Daten sind auch bei UDP durch das Protokoll gegeben. Also, sobald du in deiner Applikation die Daten hast, sind sie auch richtig. Das macht UDP.

bg
bb

 

[Leuchtkeks]

UDP ist aber ein Verbindungsloses Protokoll. Du hast keine Garantie das ein gesendetes Paket nur einmal oder mehrmals oder in der richtigen Reihenfolge oder überhaupt ankommt, das meinte ich. Ich bin bei so Sachen immer extrem übervorsichtig

 

[bits'bytes]

...
Du hast keine Garantie das ein gesendetes Paket nur einmal oder mehrmals oder in der richtigen Reihenfolge oder überhaupt ankommt, das meinte ich.
...

ja, das mag so sein wenn du über das weite internet gehst, dass die reihenfolge durcheinanderpurzelt. aber du machst doch eine punkt-zu-punkt verbindung, direkt verbunden. deine daten werden auch nicht in mehrere UDP pakete aufgeteilt. was soll also durcheinander kommen ?


ev. wäre es günstig, immer bei veränderung zu senden und für "heartbeat" zu sorgen, d.h. zb einen 300 ms takt mit in die Daten zu nehmen. der empfänger kann dann jeweils kontrollieren ob in diesem abstand die daten kommen.

noch besser würdest du statt dem takt alle 300 ms einen zähler erhöhen, der muss dann auf der empfängerseite fortlaufend sein. so kannst du ganz sicher prüfen ob die daten ok ankommen.

wie gesagt, checksum hilft meiner meinung nach nicht....

bg
bb

 

[Leuchtkeks]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja, da hast du vollkommen recht. Ich bin in Sachen Software-Absicherung immer etwas paranoid.

Stimmt, das mit dem Zähler hatte ich vorhin irgendwo im Handbuch aufgeschnappt. Gute Idee.

 

[knorpe]

also solche sachen würde ich eher über das INA protokoll laufen lassen ;-)
wesentlich stressfreier...

 

[bits'bytes]

tja,
aber auch nicht immer, wenn ich daran denke wie viele Probleme es während der IBN bereitet hat.

du spielst eine Seite rein, waren plötzlich alle INA Kommunikations Variablen voller Müll....

Bin mir nicht mal sicher ob das heutzutage funktioniert, hat sich ja doch einiges getan beim PVI...

Beim TCP/UDP hast du als Programmierer noch ein bisschen mehr Kontrolle wann die Daten übertragen werden.

Auch ist bei INA die Datenkonsistenz nicht gegeben, diese werden nicht synchron geschrieben. Es kann z.B vorkommen dass der Anfang einer Struktur schon neu ist (schon gelesen wurde), das Ende noch alt (zum Zeitpunkt wo du im Programm das auswertest). Analog gilt das wenn das PVI zum Schreiben aufbereitet. Du kannst jederzeit mit deiner Software drüber und einen Teil während der Bearbeitung verändern.



bg
bb

 

[knorpe]

Zuviel Werbung?
-> Hier kostenlos registrieren

also einmal richtig konfiguriert macht das INA eigentlich keine Probleme mehr.
und bis jetzt hatt ich auch noch keine Auffälligkeiten Punkto Datenverlust.

Aber wie gesagt - viele Wege führen nach Rom...

 

[Sera]

Schon mal über eine Powerlinkkommunikation nachgedacht?

Leicht einzubinden und schnell und das ganze in echtzeit.

Kommt natürlich drauf an ob du die entsprechenden Schnittstellen bereits hast. Sonsten wäre zusätzlich HW notwendig.

 

[bits'bytes]

also einmal richtig konfiguriert macht das INA eigentlich keine Probleme mehr.
...

Hi,
um hier kein Missverständnis zu generieren. INA läuft total super ohne Probleme wenn die Entwicklung abgeschlossen ist.

Solange man aber auf einer der CPUs Tasks überträgt wo ev. diese Kommunikationsvariablen verwendet werden, krachts schon mal (bzw. hat es früher gekracht, habe leidvolle Erinnerungen :shock

...
und bis jetzt hatt ich auch noch keine Auffälligkeiten Punkto Datenverlust.
...

Von Datenverlust war nicht die Rede, unter Datenkonsistenz verstehe ich einfach dass das Applikationsprogramm nie sicher sein kann, ob INA schon die ganzen Daten in die PV übertragen hat, oder z.B. erst 200 von 500 Byte. Dann wertet die Applikation 200 Byte vom neuen Datensatz und 300 vom alten aus. Durcheinander.

Das ging bei mir mal so weit dass ich mir am Anfang und am Ende der Struktur Sync-Flags einbauen musste um diese Probleme in den Griff zu bekommen.

Bei 10 Byte wird sowas eh nicht passieren.....

bg
bb