daten einlesen von bis zu 12 com ports

Hallo

ich habe da mal eine Frage:

ich benutze LabVIEW um von Sensoren Daten einzulesen und zu verarbeiten .. soweit so gut ...
Momentan läuft das ganze projekt so ab das ich ein Hintergrund VI starte welches bis zu 12 serielle Ports am PC einliest und die Daten in eine Globale Variable packt ...
Ein anderes Vi(ein Testprogramm von vielen) holt sich die Daten dann dort raus und stellt z.B. das ganze mit nem graphen dar und berechnet einiges...
das hintergrund VI arbeitet unabhängig vom den restlichen Vi damit es immer daten sammelt damit nix verloren geht und es nicht auf irgenwas warten muss ...
gespeichert werden aber immer nur die letzten 5 sekunden ...

zur Info: die Sensor Elektronik sendet alle 10ms nen datenpacket .. bzw mit 115200 bps und darin verpackt alle 10ms nen neuer datenstring.
Wenn der Datenstring empfangen wurde wird er zerlegt in 4 verschiedene waveforms +einiges anderes und in die globale variable gespeichert ...
und das ein COM Port nach dem anderen ....

Bei so ca 4-6 belegten Ports allerdings wird das ganze extrem langsam und bei 12 fast nicht mehr bedienbar ... von einem sich bewegenden graphen mal ganz abgesehn ...

hat jemand evtl eine idee wie ich das ganze performanter gestalten kann ?

1. globale variable weglassen .. ok... aber wie transportiere ich die Daten vom Einlese VI zum Verarbeitungs und Anzeige VI ?

ach ja ich benutze LV 7.1

ich hoffe ich hab das einigermaßen verständlich nieder geschrieben ... ich kanns leider nicht alles hochladen .. is bissi umfangreich ...

gruss toaran

Anzeige

Hallölle,
du könntest auch eine Queue nehmen.
Die kannst du in dem Einen VI füllen und im anderen wieder auslesen.
Grüße
Achimedes

Hi,

ich bin mir nicht sicher, ob die Queue was nützen würde. Dein Zeitproblem kommt wohl eher vom seriellen Lesen als von den Globals. Ich weiß ja nicht, wie du dein Lese-VI aufgebaut hast, aber evtl. sollte man das mal untersuchen. Verwendest du z.B. viele Array-Funktionen? Die fressen nämlich viele Ressourcen und man könnte da sicher was optimieren. Oder auch beim eigentlichen Lesen. Hast du das ein bisschen aufgeteilt, oder warten die Leseroutinen evtl. aus irgendwelchen Gründen aufeinander?

Poste doch mal ein Dummy-VI, dass deine VISA-Lesefunktionen enthält und ein anderes, dass das die Globals ausließt...wenn man sich sowas abgespecktes erstellt, dass das eigentliche Problem demonstriert, kommt man manchmal auch auf neue Gedanken!

Gruss
Achim

Du wirst doch wohl die Diagramme nicht alle 10ms updaten? So schnell kann sowieso kein Mensch gucken. Also besser die Daten erst mal sammeln, z.B über 100 ms oder länger, und dann das angesammelte Paket zum Diagramm schicken.
Weitere Vorschläge könnten sich ergeben, wenn Du das VI zeigst.

Hallo

danke für die antworten ... ich lad einfach mal das Einlese VI hoch ...
es könnten ein paar Sub Vis fehlen ...

das schnelltest VI ist eine ältere version der derzeitigen tests ... aber die grundfunktionen sind alle drinn ... auch bissi müll der im aktuellen nicht mehr drin ist ...

ich kann wie gesagt nicht alles hochladen ist einfach zu viel ... daher fehlen viele SubVis


  MC_Einlesen.vi (Größe: 215,31 KB / Downloads: 233)


  MC_Einlesen_P1.vi (Größe: 92,25 KB / Downloads: 221)


  Schnelltest_V1_3_2.vi (Größe: 1,31 MB / Downloads: 234)

Hi,
leider klappt das runterladen nicht...

Aber: Ein einzelnes VI, das über 1,3 MB groß ist...da ist bestimmt was optimierungsfähig

A.

' schrieb:Hi,
leider klappt das runterladen nicht...

Aber: Ein einzelnes VI, das über 1,3 MB groß ist...da ist bestimmt was optimierungsfähig

A.

hmm bei mir klappt das downloaden ....

edit: ich hab die datein mal auf meinen server geuploaded da sollte der download klappen ...

http://www.toaran.de/files/einlesen.zip

gruss toaran

Hi,

ich habs mal runtergeladen...an den beiden Lese-VIs konnte ich auf den ersten Blick nichts aussergewöhnliches entdecken...aber bei deinem Schnelltest-VI kommt mir das kalte Grausen! Da steig ich nicht durch, und ich glaube fast, das auch du damit Schwierigkeiten hast. Die vielen (unnötigen) Sequenzen. Was sollen die bewirken? Die meisten stehen in keiner Beziehung/Reihenfolge zueinander, d.h. sie werden eh willkürlich abgearbeitet... das RIESIGE Blockdiagramm...wenn schon was nicht auf ne Bildschirmseite (ca. 1024x1280) passt, kann schon was nicht stimmen...gerade Linien wären hilfreich, und evlt. solltest du mal über ne State Machine nachdenken...das Anzeigen der langen "Item Names" in den Bundle-by-Name-Blöcken frisst auch BD-Platz (mach mal nen rechtsklick und wähle "hide full names")

Es ist mir schlicht zu anstrengend, mich da durchzuwühlen...sorry! Wenn du deinen Code mal aufräumst, dann schau ich mal drüber...hast du dir dein BD mal im Navigations-Fenster angeschaut?

Gruss
Achim

' schrieb:hat jemand evtl eine idee wie ich das ganze performanter gestalten kann ?

Zuerst solltest du die Hinweise von Achim beherzigen. Obwohl es eigenlich notwendig wäre, dasselbe zur Bekräftigung nochmals ausführlich darzulegen - will ich doch darauf verzichten.

Mach mal zu allererst aus jeder einzelnen Sequenz ein SubIV. Ein solches SubVI enthält dann eine Quasi-Statemachine in einer While-Schleife, die (jede Menge) Schieberegister hat. Dieses Programmierverfahren (Statemachine in While-Schleife) dienst der Variablenverwaltung! Als Nebeneffekt verschwinden dann auch noch jede Menge lokaler Variablen im Hauptprogramm - was sehr gut ist im Sinne einer Datenflußsteuerung. Und beachten: In das SubVI gehen keine Referenzen rein auf Variablen/Bedienelemente, die nicht im Frontpanel sichtbar sind !

Wenn es dir nicht gelingt, jede einzelne parallele Sequenz in ein SubVI umzuwandeln - weil du z.B. in mehreren Sequenzen die gleiche Variable benutzt (beachte: keine Referenzen, die sind in deinem Falle verboten) - dann hast du nicht mit den SubVIs ein Problem, sondern bereits jetzt mit deinem bestehenen Sourcecode. Da können nämlich jetzt bereits Dateninkonsistenzen auftreten, von denen du bisher noch gar nichts bemerkt hat - weil: sehen tut man in diesem Sourcecode ja gar nichts.