INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Event-gesteuerte RS232



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!

03.02.2014, 09:48
Beitrag #11

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: 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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
03.02.2014, 10:57
Beitrag #12

Mr. B Offline
LVF-Neueinsteiger


Beiträge: 4
Registriert seit: Jan 2014

DEVELOPER SUITE CORE 2013
2005
EN


Deutschland
RE: Event-gesteuerte RS232
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!
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.02.2014, 11:09 (Dieser Beitrag wurde zuletzt bearbeitet: 03.02.2014 11:34 von GerdW.)
Beitrag #13

GerdW Online
______________
LVF-Team

Beiträge: 17.398
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: Event-gesteuerte RS232
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…)

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.02.2014, 11:28
Beitrag #14

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Event-gesteuerte RS232
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.02.2014, 11:32 (Dieser Beitrag wurde zuletzt bearbeitet: 03.02.2014 11:33 von GerdW.)
Beitrag #15

GerdW Online
______________
LVF-Team

Beiträge: 17.398
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: Event-gesteuerte RS232
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…

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
03.02.2014, 11:57 (Dieser Beitrag wurde zuletzt bearbeitet: 03.02.2014 11:57 von Lucki.)
Beitrag #16

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: Event-gesteuerte RS232
(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.Big Grin
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
07.02.2014, 09:41
Beitrag #17

Mr. B Offline
LVF-Neueinsteiger


Beiträge: 4
Registriert seit: Jan 2014

DEVELOPER SUITE CORE 2013
2005
EN


Deutschland
RE: Event-gesteuerte RS232
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
07.02.2014, 09:44
Beitrag #18

GerdW Online
______________
LVF-Team

Beiträge: 17.398
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: Event-gesteuerte RS232
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…

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  User Event in einem Event zünden? theodrin 11 8.500 28.08.2009 21:36
Letzter Beitrag: theodrin

Gehe zu: