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
