Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
ich muss für ein Messprogramm unter anderem eine Kommunikation zwischen zwei Rechnern realisieren.
Effektiv sieht das so aus das auf Rechner A Messhardware zum Auslesen der Messdaten vorhanden ist und über LabVIEW abgefragt wird. Außerdem soll über diesen Rechner ein Rechner B gesteuert werden, der sich direkt am Messplatz befindet und die Messapparatur steuert (über ein LabVIEW Program).
Ich denke mit TCP / IP sollte das ja am einfachsten auch zukunftssicher zu realisieren sein (beide Rechner haben Zugang zum gleichen LAN).
Soviel zum Setup.
Leider konnte ich im Example Finder keines der Beispiele öffnen und bezüglich meiner Fragen war auch das Beispiel <a href='index.php?showtopic=8230'>in diesem Thread gefunden habe </a>nur insoweit hilfreich, dass ich glaube den prinzipiell zu wählenden Aufbau verstanden zu haben. Ich hoffe der ein oder andere kann mir meine Fragen beantworten, da das Verfahren möglichst umfassend verstehen will um Fehler zu vermeiden und eine möglichst stabile Kommunikation zu garantieren, bei der Falls notwendig auch große Datenmengen ausgetauscht werden können. Soweit zur Vorrede.
Das eigentliche Problem / die eigentliche Frage:
1. Soweit ich das verstehe sollte man am besten einen Rechner als Server verwenden und einen als Client. Ich würde mal vermuten, dass im Zweifel auf den Server ein größeres Aufkommen an Prozessorlast liegt (?). Entsprechend würde ich Rechner B hierfür nutzen und A als Client (da hier der eigentliche Messprozess läuft sollte der Rechner nicht mit zu vielen Aufgaben überfrachtet werden).
2. Prinzipiell brauche ich eine 2 Wege Kommunikation. Kann ich das Programm trotzdem zunächst über den localhost testen? (soweit ich das verstanden habe könnte ich ja auch an den Senden und empfangen, ich müsste also meinem Verständnis nach nur Race Conditions zwischen den beiden Programmteilen beim testen Verhindern (damit nicht der Client dinge empfängt die er selbst gesendet hat etc.)
3. Ich verstehe nicht genau, wann ich einen Timeout kriege. Der Listener wartet ja nur darauf dass er von extern kontaktiert wird. Folglich kriegt der (bei aktiviertem Timeout) also auch schon einen Timeout, wenn keine Verbindung angefragt wird.
Wie sieht das ganze aber bei TCP Read und Write aus? Ich hatte in einem anderen Thread etwas von einem TCP stack gelesen. Wirft Write also erstmal alles auf besagten Stack und wenn innerhalb des Timeouts nicht gesendet werden kann passiert der Timeout? Oder liegt der TCP stack schon auf dem Zielrechner und ist nur für das TCP Read relevant?
Genauso die Read Funktion, kriegt diese einen Timeout wenn keine Verbindung vorliegt oder auch wenn keine per TCP Write gesendeten Daten mehr vorliegen?
4. Verstehe ich den Aufbau richtig insoweit, dass auf dem Server ein Listener läuft der auf eine eingehende Verbindung wartet. Vom Client wird diese mit TCP: Verbindung Herstellen hergestellt. Anschließend kann ich auf beiden Rechnern Read und Write Operationen durchführen. Die Kommunikation ist dabei automatisch nach ausgehender und eingehender Kommunikation getrennt (sprich: Ich kann nicht mit TCP Read lesen was ich vorher geschrieben habe, sondern nur das was Rechner 2 geschrieben hat).
a) Sollte man diese Verbindung dann nach Abschluss einer Sendeoperation offen lassen oder lieber schließen und beim nächsten Vorgang neu öffnen (gibt es da irgendeine Daumenregel nach der man entscheiden kann wann das eine und wann das andere lohnt oder eine generelle Richtlinie)
b) Muss man selbst dafür sorgen dass die Verbindung offen bleibt (durch regelmäßigen Datenverkehr - sozusagen ein "alive signal") oder reicht es aus auf einem Rechner (oder beiden) durch ein Read zu prüfen ob Daten anliegen (falls Read keinen Timeout kriegt wenn keine Anliegen).
c) Das Timeout Handling muss ich mir selbst programmieren (?) (sprich also typischerweise das selbe Paket nochmal senden lassen etc. pp.)
d) findet beim Senden über das TCP Write / Read im TCP Protokoll selbst schon eine Prüfung mit Checksummen statt oder sollte selbst noch eine erzeugen um die empfangenen Daten auf Konsistenz zu prüfen?
e) Gibt es Richtlinien wie groß die Datenpakete maximal sein sollten die man mit einem einzelnen Write / Read Kommando sendet?
f) Kann ich davon ausgehen, dass jedes Read Kommando die Daten aus genau einem Write ausliest (auch wenn zum Beispiel vor dem Read auf der Gegenseite schon zwei Write Operationen durchgeführt wurden)?
Soweit erstmal alle Fragen die mir dazu einfallen. Ich danke schonmal im Vorraus für die Zeit beim lesen und die hoffentlich kommenden Antworten.
Gruß Kiesch
P.S: Auch über Sekundärliteraturempfehlungen wäre ich sehr dankbar (sollte allerdings möglichst nichts kosten)
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Anzeige
15.06.2010, 14:43 (Dieser Beitrag wurde zuletzt bearbeitet: 15.06.2010 14:50 von Kiesch.)
Sorry wegen doppelpost, aber ich konnte nirgends einen Edit Button finden *scheinbar weil Eingangspost des Topics*:
Eine Frage noch zu "TCP: Listen": Ist das von der Funktionalität her einfach eine kombination der Funktionen "Listener erstellen" und "Auf Listener warten" oder gibt es da noch Unterschiede?
*Nachtrag 2*
Eine weitere Sache noch: Wäre es problematisch, wenn auf beiden Rechnern unterschiedliche LabVIEW Versionen laufen? Aktuell läuft auf Rechner A ein LV 8.2 - ich hoffe dass ich mich mit einem Upgrade auf 2009 durchsetzen kann. Rechner B sollte eigentlich jederzeit problemlos geupdatet werden können. Nur bei Rechner A ist das eigentlich weniger gewünscht (nach dem Motto never Change a Running System muss dazu vorher quasi garantiert sein, dass man, wenn es dadurch zu Problemen mit den Messprogrammen kommt das Update komplett zurücksetzen kann in irgendeiner Form).
Es ist also durchaus möglich, dass in Zukunft auf beiden Rechnern unterschiedliche LabVIEW Versionen laufen werden - daher wäre es gut zu wissen ob man das vielleicht vermeiden sollte (sprich B nur updaten wenn A auch geupdatet wird).
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
Hi, danke Archimedes, hab mir die Erklärung zu den shared variables von NI mal näher angelesen und es scheint als ob die quasi die meisten Funktionen schon erfüllen die ich mit TCP/IP erst programmieren müsste.
Der Thread kann also soweit zu. Hab zwar noch fragen, aber die sind dann wohl besser in dem shared Variables Thread hier zu diskutieren, damit jemand der danach sucht die leichter findet :-)
@Mod bitte Thread zumachen, danke :-)
Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
Zitat:d) findet beim Senden über das TCP Write / Read im TCP Protokoll selbst schon eine Prüfung mit Checksummen statt oder sollte selbst noch eine erzeugen um die empfangenen Daten auf Konsistenz zu prüfen?
Da es leider keinen Error Code dazu gibt würde ich vermuten das es von der LabView Seite nicht Implementiert wird, aber da es ein Teil des TCP Protokolls ist sollte es doch vorhanden sein?