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 habe noch einen Hinweis: in deiner letzten RT-Variante bist du von sende alle 6.4 Sekunden Kommandos an 1 Gerät auf sende alle 0.1 Sekunden Kommandos an ALLE Geräte gegangen. Mglw. ist 0.1 Sekunden zu kurz, um eine Antwort zu erhalten.
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
da ich mit dem Problem überhaupt nicht weiter gekommen bin die Hardware aber anscheinend funktioniert habe ich mal versucht eine total abgespeckte Version des Projektes zu erstellen um über FPGA-FIFO-RealTime serielle Daten zu lesen und zu schreiben.
Blöderweise funktioniert das ganze nicht so wie es soll. Denke, dass ich da bestimmt wieder so einen kleinen Code-Fehler drin habe auf den ich nicht komme...
Im RT. vi sind coercion dots zu sehen wenn es darum geht ins fifoWRITE etwas reinzuschreiben. Datentyp vom fifoWRITE ist U16 und es müsste eigentlich passen. Tut es leider nicht.
Ansonsten habe ich das Problem das Befehle nicht gesendet werden. Zudem werden nur die Anfangsteile der zu empfangenden Befehle empfangen.
Ein ganz anderer Ansatz (habe mir dein zip-File noch nicht angesehen):
Die 9870/9871 RS232 Module lassen sich auch im Scan-Engine Modus betreiben (Voraussetzung: Installation des entsprechenden Pakets auf dem cRIO). Im RT verhalten sie sich dann wie eine "gewohnte" serielle Schnittstelle (vgl. Sektion 4 cRIO Developer's Guide).
Gruß, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Ja das mit dem CoercionDot war eigentlich recht simpel, schätze habe zu lange gearbeitet gestern
Bevor ich das mit den ScanEngine-Mode versuche wollte ich zunächst die Hardware testen.
Dazu habe ich das Modul mit einem anderen PC verbunden und mit Hyperterminal getestet.
Zunächst funktioniert alles wunderbar und ich kann Daten senden und empfangen. Sende ich über mehrere Ports funktioniert es weiterhin.
Aber einige Sekunden nach dem ich den "Update Config"-Button betätige (serielle Konfiguration, Baud rate etc.) hängt sich das FPGA.vi auf. Es kommen zwar keine Fehlermeldungen und alles sieht danach aus, dass das VI läuft, aber es wird nichts mehr gesendet und empfangen.
Beim ersten Klick auf "Update Config" springt der Button sofort wieder auf off (das muss es laut Code auch tun). Nach einigen Sekunden (also nach dem das FPGA.vi sich aufhängt) tut er das auch nicht mehr. Ich hatte das Problem auch mit dem letzten FPGA.vi (Prozessleitsystem.zip), das heißt an den jetzigen Änderungen kann es nicht liegen.
//edit
ein Nachtrag: Das ganze funktioniert erst wieder wenn das RIO neugestartet wird. Stoppen des VI oder Neu starten von LabVIEW zeigen keine Wirkung
//
Deutet das auf ein Hardware Problem hin? Was würdet ihr vorschlagen.
Anbei das FPGA.vi und das Bild mit den Änderungen.
ich habe es endlich zum Laufen bekommen ohne dass sich irgendwelche Ports überschneiden . Es wird vom richtigen Port gelesen und auch auf den richtigen geschrieben. Alles funktioniert wunderbar bis auf ein Problem: Das ganze ist elendig langsam...
Bis der Inhalt des fifoWRITE über die Ports geschickt wird staut sich alles im besagten FIFO und die neu eingegeben Befehle kommen erst teils nach 1-2 Minuten an, weil in der Zwischenzeit die vorherigen Befehle mehrmals ins FIFO geschrieben wurden.
Timeout des FIFO und der Module (Modx/Portx, Write Byte) runtersetzen bringt nichts.
Wäre es eine Lösung die Größe des FIFO so zu reduzieren, dass in einem Intervall nur ein Satz der Befehle ins FIFO geschrieben wird?
Hoffe ihr habt ein paar Ideen, denke es ist nicht mehr weit bis zu einer guten Lösung.
Anbei das FPGA und RealTime.vi
Danke und Grüße,
Hattorii
11.04.2014, 20:32 (Dieser Beitrag wurde zuletzt bearbeitet: 11.04.2014 20:37 von GerdW.)
du hast noch einen heftigen Bug im FPGA.vi: Deine Port-Init-Casestrukturen werden nur genau einmal zum Start des FPGA.vi aufgerufen! Du hast dummerweise innerhalb deiner While-Loop andere endlos laufende While-Loops: was bedeutet das wohl für die Iterationen der äußeren Loop?
Im RT-VI der gleiche heftige Bug: du schreibst in einer ungebremsten endlos laufenden While-Loop Daten in deinen FIFO - und wunderst dich, wenn dieser überläuft…
Was soll dieser Quatsch mit endlos laufenden Schleifen innerhalb von endlos laufenden Schleifen? Von welchem NI-Beispiel-VI hast du sowas gelernt?
Pack doch bitte Write-Loop, Read-Loop und Init-Loop im FPGA in parallele Loops! Das gleiche gilt für den RT-Host…
Im RT-VI schreibst du jeweils U16-Arrays in den FIFO, im FPGA liest du diese Arrays aber einzelwertweise aus. Bei längeren Strings schreibst du also (im FPGA) so schnell wie möglich in die seriellen Ports - ich weiß wirklich nicht, ob die das mögen…
Es gibt doch eigentlich für alle Module entsprechende Beispiel-VIs, sicherlich (und gerade) für deine Module mit den seriellen Ports. Wie wird das da eigentlich gehandhabt?
Danke für deine Antwort Gerd. War sehr hilfreich!!!
Habe die Korrekturen vorgenommen zudem schreibe ich nun nur alle 5 Sekunden ins FIFO. Habe festgestellt, dass dieser genau dann nicht voll läuft.
Ich muss die ganze Zeit Befehle senden, da in diesem Falle der Befehl "in_pv_02" dem Gerät sagt, dass er mir die Ist-Temperatur zurückschicken soll, welches aufgezeichnet werden soll. Habe es aber nun in so weit geändert, dass die anderen Befehle nur einmal gesendet werden sollen bei Änderung.
Eine letzte Frage:
Ich bekomme nun alle 5 Sekunden eine Temperatur zurückgeschickt, welches wegen der Shift Register von rechts nach links durchgeschoben wird (Port X -String Indicator). Wie kann ich diesen String so bearbeiten, dass ich daraus die richtige Temperatur erhalte in der Form: "25.03". Denn wird dieser weiter geschoben steht ja theoretisch irgendwann auch mal "5.03" und ".03" oder "03" da drin.
VIELEN DANK und beste Grüße,
Hattorii
anbei: die funktionierenden (wahrscheinlich nicht die schönste Variante ) VIs
14.04.2014, 20:42 (Dieser Beitrag wurde zuletzt bearbeitet: 14.04.2014 20:45 von GerdW.)
Zitat:Wie kann ich diesen String so bearbeiten, dass ich daraus die richtige Temperatur erhalte in der Form: "25.03". Denn wird dieser weiter geschoben steht ja theoretisch irgendwann auch mal "5.03" und ".03" oder "03" da drin.
- Üblicherweise werden solche Strings mit irgendwelchen TermChars gesendet, die man dann prima auswerten kann. Dummerweise löscht du die aber mit TrimWhitespace weg…
- Wenn man sich an den TermChars orientiert, wird es sehr einfach: Immer wenn ein TermChar kommt, wertet man die bisherigen Zeichen aus (die sollten dann ja eine komplette Messung darstellen) und löscht diese dann aus dem Buffer (aka Schieberegister)…
- RT: Wozu hast du eine lokale Variable "Datenspeicherung", wenn das Terminal ungenutzt rumliegt?
- RT: Um einen boolschen Wert nach 0/1 umzuwandeln gibt es eine passende Funktion in der boolschen Palette: da braucht man kein Select mit zwei Konstanten…
- RT: Wozu ein FormatIntoString, dessen Hauptaufgabe im Einfügen von Zeilenendezeichen besteht? Warum tippst du die nicht einfach im Formatstring mit ein?
- RT/FPGA: Wenn du Zahlenwerte auf einen Bereich testen willst, kann man ein "größer als", ein "kleiner als" und zwei Case-Strukturen verwenden - es gibt aber auch die InRangeAndCoerce-Funktion, die man mit einem Select kombiniert…
- FPGA: Wenn du Messwerte als FXP bekommst und diese in ein I16-Terminal schreibst, bekommst du nicht ohne Grund einen CoercionDot. Ich frage mich, ob "Systemdruck P0x" jemals einen korrekten Wert anzeigt…
- RT/FPGA: Das AutoCleanup-Tool machte für meinen Geschmack beide VIs übersichtlicher…
- Tipp: In den LV-Optionen kann man die "Symbol"-Darstellung aller Terminals im BD ausschalten - die nehmen dann weniger Platz im BD weg und man sieht sofort den Datentyp anstatt der (die meiner Meinung nach) unwichtige FP-Optik…
