+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Instrument IO & VISA (/Forum-Instrument-IO-VISA)
+---- Thema: cFP2020 und RS485 (/Thread-cFP2020-und-RS485)
cFP2020 und RS485 - Nobby - 10.01.2006 11:42
Allen ein frohes, erfolgreiches neues Jahr.
Ich habe LabVIEW 7.1, RT 7.1 und ein cFP2020 über Ethernet mit meinen PC verbunden.
Meine Applikation (VI) möchte ich auf dem PC laufen lassen jedoch muss/will ich die RS485 des cFP2020 ansprechen! Hat jemand zufällig ein kleines Beispiel oder weiss einer wie es funktionieren kann?
NI konnte mir bis jetzt nicht weiter helfen!
Vielen Dank im Voraus für Eure Hilfe.
cFP2020 und RS485 - BitRechner - 16.01.2006 13:38
Hallo!
Habe schon mal so ein ähnliches Problem gehabt, die Lösung ist dann doch etwas "scharf" gewesen.
Frage vorweg: Was spricht dagegen, dem cFP die Arbeit zu lassen und - ich weiß nichts genaues über die Art der Daten vom RS485! - einfach z.B. formatierte, fertige Messdaten oder was auch immer an den PC zurückzusenden. Damit werden Timing-Probleme sehr gut vermindert, da der cFP die ev. zeitkritische Kommunikation per RS485 übernimmt!
Meine Empfehlung, falls wirklich der PC die Strings für den RS485 zusammenbauen muss: DataSocket
Du erstellst ein VI für den Fieldpoint, ein VI für den PC.
Das Fieldpoint-VI regelt die Kommunikation mit RS485, der PC sendet dafür die ASCII-Befehle via DataSocket runter auf den cFP.
Zum Beispiel: PC generiert und sendet Befehl "#062?" für RS485, der cFP hängt dann noch ein CarriageReturn an und schickt es per VISA an die Schnittstelle.
Im nächsten Schritt kommt die Antwort, die über einen anderen String wieder auf den PC zurückgeschrieben wird.
Soviel zur Theorie. Haken: Der cFP hat keinen DataSocket-Server.
Lösung: als DataSocket-IP-Adresse auf dem cFP einfach die Adresse des PC eintragen; der PC ist also logisch gesehen also Quelle und Senke gleichzeitig, aber es funktioniert.
Tip: Datasocket nicht per Front-Panel konfigurieren (Data Operations-Data Socket Connection...), sondern programmatisch mit den Data-Socket-VIs des BlockDiagramms unter Communication-DataSocket - und das Timing genau beachten: PC Sendet, cFP Empfängt, cFP Sendet an RS485, cFP Empfängt von RS485, cFP Sendet retour an PC (Sequence Structures). Inwieweit das mit den Latenzzeiten des Netzwerks wirklich gut geht, ist eine andere Frage (Stichwort VISA timeout...). In diesem Fall Lösung ganz oben: cFP macht die Arbeit
Hoffe geholfen zu haben!
BR.
cFP2020 und RS485 - Nobby - 16.01.2006 15:15
Zunächst mal: Danke für die Tips.
Hier noch ein paar Infos zu meiner Anwendung:
Ich bediene per RS485 8 StÚck Durchflussregler und eine Motorsteuerung. Die Regler bekommen eine RS485 und die Motorsteuerung ebenfalls eine.
Für die Bedinung und Visualisierung meines Experiments auf dem PC benötige ich von den Durchflussreglern zyklich die Istwerte und setze ab und an neue Sollwerte. Dem cFP würde ich ein Array mit den Sollwerten übergeben und ein Array mit den Istwerten abverlangen, den Rest soll das cFP-System machen.
Die Mototsteuerung ist etwas aufwendiger da sie verschiedene Befehle bekommen muss und neben der aktuellen Position bis zu 32 Statusbits zur Verfügung stellt. Zudem ist die Steuerung über ein Sub-VI aus- und einschaltbar. Dieses VI funktioniert und läuft z.Zt. über eine RS232 vom PC. Ein Kompile-Versuch für den cFP ist mir bis jetzt noch nicht gelungen, da RT nicht gleich LabVIEW ist :x - ich muss dafür mein Prog-Design ändern! Fúrs Erste würde ich auf dem Host die Asccis der Motor-Schnittstelle zusammenbauen und die Antwort der Schnittstelle ebenfalls auf dem Host auswerten.
Zusammenfassend:
FÚr cFP würde ich zwei Vi's (Regler + Motor) bauen wollen mit denen ich vom Host aus kommuniziere. Ich dachte an TCP, da, laut Beschreibung, DataSoket Daten verlieren kann?!
Eine Host - cFP Kommunikation habe ich noch nicht programmiert, das ist Neuland für mich
Hast du vielleicht ein kleines, nachvollziehbares Beispiel für mich?
Eine Frage noch: Laut NI passen LabVIEW 8.0 und RT 7.1 nicht zusammen! Stimmt das? Aus diesem Grund benutze ich noch LabVIEW 7.1 da ich die RT 8.0 noch nicht habe.
cFP2020 und RS485 - BitRechner - 16.01.2006 21:26
Zuerst das Leichte:
LV RT 7.1 und LV RT 8.0 sind inkompatibel. Für den Betrieb von LV RT 8.0 empfiehlt NI den Einsatz von cFP-2120, da die cFP-2020 zu wenig Rechenpower haben. Ich denke das kommt ganz auf die Anwendung an, und sollte einfach getestet werden.
Ich habe mich noch nicht drübergetraut, LV RT 8.0 auf einem cFP-2020-System zu installieren, da ich momentan schon froh bin, wenn LV 8.0 und RT 8.0 auf einem cFP-2120 gut zusammenarbeiten, und damit meine ich, dass ich nicht Kaffe trinken gehen kann bis die VIs auf die cFPs runtergespielt sind und laufen.
Ohne Frage jedoch eignet sich meiner Meinung nach erst LV 8.0 in Kombination mit LV RT 8.0 zur Vernünftigen Entwicklung von Anwendungen für den cFP. Damit meine ich z.B. dass in LV 8.0 das Fenster mit "Execution Target PC" parallel zum Fenster mit "Execution Target cFP" am Bildschirm läuft - da fetzt das Debugging dann schon
Der zweite wichtige Vorteil: Shared Variables.
Diese lösen nämlich genau Deine Aufgabenstellung ohne Datasocket udgl.
Am PC wird in eine Variable geschrieben, der cFP liest sie aus - wie wenn sie ein und dasselbe System wären.
Zum eigentlichen Problem:
Die VIs im Anhang realisieren eine Art Handshake zwischen cFP und PC: Der PC sendet erst, wenn der cFP den Empfang bestätigt.
Anmerkung: Das Problem der Gleichzeitigkeit kann NICHT umgangen werden - die VIs schieben das Problem einfach in eine Ecke, die "wahrscheinlich" funktioniert.
Die "Ecke" bei diesem Beispiel: Der cFP setzt sein cFP_acknowledge erst retour, wenn der PC das Signal PC_dataready zurücknimmt.
Anderer Ansatz:
Aus dem cFP_acknowledge ein allgemeines acknowledge machen, das erst vom cFP auf True und dann von PC wieder auf False gesetzt wird, wenn der PC ein True, das der cFP gesetzt hat, erkannt hat. Die Fehlermeldung (multiple datasocket-writers not allowed) kann durch einen Indicator abgefangen werden, und das VI läuft weiter (sonst schaltet sich der automatic error handler ein, und hält das VI auf, ist aber sowieso eine eher unschöne Lösung).
Ist halt wie bei Mutual Exclusion und Sync: Im Endeffekt darf, bei aller Parallelität, sowieso nur ein Programm gleichzeitig im kritischen Abschnitt des Speicherbereiches laufen.
Die VIs:
DS client handshake - zum Testen am PC laufen lassen, dann runter damit auf den cFP
DS server handshake - liefert Daten an den PC/cFP
Launch DS Server if Local URL - aus den Beispielen, startet einfach den DS Server programmatisch
Ablauf: erst den client, dann den server starten und ein bißchen Geduld, bis sich der DS-Stack "erfangen" hat.
Zum Stichwort Daten verlieren:
Das wurde bisher von allen Befragten NI-Ingenieuren mit den Worten: "Das ist eh gepuffert" abgeschmettert. Irgendwo hab ich einmal ein Beispiel gesehen wo ein Bild per DS übertragen wurde. Leider hab ich damals nicht schnell genug geschaltet und das Netzwerkkabel abgezogen und wieder angesteckt - mal schauen ob das Bild dann noch ganz ist (ok, in gewissen Zeitgrenzen halt)
In diesem Sinne
happy wireworking
BR
cFP2020 und RS485 - thomas.sandrisser - 16.01.2006 22:40
[quote=BitRechner]Zuerst das Leichte:
Zum Stichwort Daten verlieren:
Das wurde bisher von allen Befragten NI-Ingenieuren mit den Worten: "Das ist eh gepuffert" abgeschmettert. Irgendwo hab ich einmal ein Beispiel gesehen wo ein Bild per DS übertragen wurde. Leider hab ich damals nicht schnell genug geschaltet und das Netzwerkkabel abgezogen und wieder angesteckt - mal schauen ob das Bild dann noch ganz ist (ok, in gewissen Zeitgrenzen halt)