Event-gesteuerte RS232

Zu Deiner Ausgangsfrage:

(31.01.2014 14:20 )Mr. B schrieb:  Ich frage mich, ob es möglich ist in einer Schleife auf X Teilnehmerevents zu warten - diese dann meinetwegen in eine query schieben, um sie dann nacheinander abzuarbeiten (denn die Daten können natürlich auch zeitgleich eintreffen).

VISA-Read verhält sich schon von Natur aus so wie man das von Events her kennt - d.h. es wartet und wartet, bis etwas ganz Bestimmtes eintritt. Das kann sein: a) Zeilenendezeichen eingetroffen (falls Zeilenende-Steuerung konfiguriert, sehr zu empfehlen!). b) Die per Eingangsbelegung festgelegte Anzahl von Bytes befindet sich im Buffer c) Timeout ist erreicht (Gibt es so auch bei der Event-Struktur, aber es wird eigentlich nicht als Event gezählt)
Eine extra Event-Struktur wäre da doppelt gemopppelt.
Man kann diese Ereignsisteuerung aber außer Verkehr setzten - und von Anfängern wird das regelmäßig so gemacht und es wird hier auch teilweise vorgeschlagen, manchmal auch zu Recht . Z.B so: Vor Ausführung von VISA-Read wird nachgeschaut was im Puffer ist und dann immer genau das gelesen. Entweder es wird vorher genügend lange gewartet, damit alles was man erwartet auch schon im Buffer ist, oder es wird so lange gepollt, bis man alles zusammen hat.
Wenn Du mehrere COMs hast und Du willst nicht pollen, dann geht das nicht in einer Schleife, sondern nur in parallelen Schleifen. Es muß dann überall einen Timeout geben, damit man die Schleifen auch mal beenden kann.

Jup - so meine ich das.

Gerade das Thema mehrere Schleifen ist da meine denke. Aber da liegt ja der Mops im Keller: da müsste man dann ja x Schleifen "vorprogrammiert" haben und dann zur Laufzeit mit "Sinn" füllen. Irgendwie uncool.

Zurück zur Frage: das Durchwühlen nach den Daten scheint also alternativlos. In einer eigenen Schleife wühlen und wenn was gefunden wurde in einer anderen Schleife auslesen.

Meine Vorstellung wäre es gewesen, ein Array mit comports zu übergeben und eine unabhängige Meldung zu erhalten, an welchem comports etwas auszulesen ist. Die Menge der comports sei unbekannt und flexibel. Sobald diese Meldung da ist, kann man in einer anderen Schleife die Daten abholen und verarbeiten. Die Abfrage, ob an anderen Ports etwas anliegt läuft während dessen ungehindert weiter und meldet ggf. während der Verarbeitung bereits die nächsten Daten an einem anderen Port z.B..
Das kann ich ja nun auch über das durchwühlen erreichen. Irgendein Gefühl sagt mir, dass es da doch was geben muss: das bekanntgeben, dass Bytes am Port sind ist ja bereits ein solches Event - warum muss man sich dann genau das erst noch selbst erzeugen, indem man es ständig abfragt?

Danke trotzdem!

Hallo B.,

da erstellt man sich ein VI, welches man mehrfach parallel aufruft - so oft wie man COM-Ports verwalten will.
So sieht das bei mir aus:
   
(Hier noch für LV2009, LV2011+ macht das asynchrone Aufrufen noch einfacher…)

Dann schiebt man die gelesenen Daten in eine gemeinsame Queue (mit einer Kennung für den COM-Port) und kann sie zentral auswerten. (Oder wie im Bild mittels einer FGV…)

Es werden ja wohl nicht während der Laufzeit ständig COM-Ports zugefügt und entfernt? Und selbst wenn nicht, dann wäre das auch kein Problem. Die auf dem Motherboard implementierten COM 1 und 2 würde ich im BIOS abschalten. (Oder in der Software nicht mit zählen) Es verblieben dann nur noch die USB-Ports, und diese COMs existieren nur so lange, wie die Hardware tatsächlich in USB gesteckt ist. Und man kann doch wohl davon ausgehen, dass die angesteckten USB-Coms auch verwendet werden? Die existierenden COM-Ports lassen sich leicht ermitteln, und Existenz wäre dann gleich Benutzung.

Hallo Ludwig,

Zitat:Die existierenden COM-Ports lassen sich leicht ermitteln, und Existenz wäre dann gleich Benutzung.

Bei einem 4fach oder gar 8fach USB-zu-RS232-Adapter würde ich das (d.h. der zweite Teil des Satzes) nicht so pauschal sehen…

(03.02.2014 11:32 )GerdW schrieb:  Bei einem 4fach oder gar 8fach USB-zu-RS232-Adapter würde ich das (d.h. der zweite Teil des Satzes) nicht so pauschal sehen…

Ja richtig, aber vielleicht hat unsere Diskussion den positiven Aspekt, dass Mr.B ein paar überfälligen Informationen über die verwendete Hardware herausrückt.

Anzeige

Hi zusammen,

danke für die Hinweise.
Tatsächlich werden zur Laufzeit des Programmes weitere Teilnehmer hinzugefügt oder entfernt.

Somit bleibt es tatsächlich so, wie es ursprünglich vermutet: durchwühlen und melden - ob über FGV oder querey oder whatever (Reise nach Rom).
Ich konnte mich nur nicht damit abfinden, dass das auslösende Ereignis ("Comport in Verwendung") nicht abrufbar ist (ganz einfach, wie "button down" einer Maus), sondern aktiv von Hand abgepollt werden muss.

Greez

Hallo B,

Zitat:das auslösende Ereignis ("Comport in Verwendung") nicht abrufbar ist

Vielleicht ist das so, weil der COM-Port-Status kein "Ereignis", sondern ein "Zustand" (bzw. in OOP-Sprech eine "Eigenschaft") ist?

Dir steht es frei, ein UserEvent zu definieren, welches du über eine Polling-Routine triggerst…