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 

Designproblem: RS232 Kommunikation



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!

18.02.2009, 12:55
Beitrag #13

therobbot Offline
LVF-Grünschnabel
*


Beiträge: 11
Registriert seit: Feb 2009

8.2
2008
de

97082
Deutschland
Designproblem: RS232 Kommunikation
' schrieb:Warum sollte ich aber eine Klasse im Sinne von OOP/LVOOP machen, wenn ich die vorerst nie wieder so verwenden werde.
Naja, ich habe die Erfahrung gemacht, dass sich das dann später oft doch auszahlt, besonders wenn man konsequent objektorientiert entwirft. Aber ich gebe zu, dass es nicht für alle Anwendungen optimal ist und es sicher auch für vieles besser und/oder effizienter ist, einen anderen Ansatz zu wählen. So gesehen wollte ich auch nicht Deinen Ansatz kritisieren, sondern nur sagen, dass für mich da der Name "Klasse" erstmal verwirrend war.

Zu Instanziierung:
' schrieb:siehe eg.
Das klingt ja gut. Allerdings sollte man in diesem Fall die Queues wohl nicht mehr einfach über Namen verwalten, oder? Dann würde man wahrscheinlich doch eher die Queues beim Start dem VI übergeben, damit jede Instanz seine eigene Queue hat. Das mit den Namen ist mir auch noch etwas unheimlich, da ich ja da nie sicherstellen kann, wer da drauf schreibt...

' schrieb:Das Beispiel sampled kontunuierlich (soll's zumindest) - und zwar im Raster von 50ms. Alle 50ms werden also die Queue überprüft und die in der vergangenen Zeit aufgelaufenen Samples gelesen und weiterverarbeitet. Ob von diesen 50ms-Raster nun z.B. mal 10 Stück wes wegen auch immer ausfallen, spielt für das Samples keine Rolle. Die Daten werden - ob Daq oder VISA - im Hintergrund gespeichert.
Ah, ok, jetzt sehe ich es auch. Ja, solange es nicht wirklich länger ausfällt, würde es durch den VISA-Puffer wohl abgefangen. Allerdings ist das bei mir schon ziemlich zeitkritisch. Ich bekomme pro ms 10 Bytes rein und ich darf da auch eigentlich nichts verlieren.

' schrieb:Und zu Instanzen:
Instanziert wird in LV, indem ein SubVI auf das Blockdiagramm plaziert wird.
Ok... das funktioniert aber dann nur, wenn das VI reentrant ist und kontinuierlich ausgeführt wird, oder? Wenn es nicht kontinuierlich ausgeführt würde, und seine Daten nur in einem uninitialisierten Schieberegister speichern würde, dann würde man doch bei jedem Aufruf wieder dieselbe Instanz bekommen...

Nochmal danke für Deine ausführlichen Antworten und die rege Diskussion. Ich habe durch diesen Thread schon eine Menge gelernt!

Gruß,

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


Nachrichten in diesem Thema
Designproblem: RS232 Kommunikation - eg - 16.02.2009, 20:38
Designproblem: RS232 Kommunikation - eg - 18.02.2009, 10:48
Designproblem: RS232 Kommunikation - therobbot - 18.02.2009 12:55
Designproblem: RS232 Kommunikation - eg - 18.02.2009, 13:07

Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  RS232 / VISA - Alternativer Ansatz für Kommunikation ? fidel 21 15.836 18.12.2006 13:17
Letzter Beitrag: tron
  Voraussetzung zur Kommunikation über RS232 / GPIB / USB-Port jameson 6 5.818 27.09.2006 08:43
Letzter Beitrag: jameson

Gehe zu: