queued message handler - slow

[skyraak]

I used the the queued message handler project template to implement the multiple readout and control of several VISA-devices over virtual serial-USB bridges. 

The timeing or readout frequency in the template is mangaed though a "Wait Until Next multiple ms " VI. At every stated multiple  ms LabView "requests" a measurement of a aqusisition VISA-device, reads the interface and process a 51 byte string into double numers and sends commands to the control VISA-device.

Everything works fine, until I drop below 10ms. No error occurs but the logged seconds become "stretched" and longer than actual seconds suggesting that LabView takes longer to process everything than 10ms.

My VISA microcontrollers are capable of much higher frequencies (after measurement request arrival on the mictrocontroller till the whole 51 byte string is assembled and sent < 300us). It is not essential that the timeing is absolutely precise, but 1000 samples for example should be on average one second and the data should be logged with higher frequency than 100 Hz.

Any ideas how to overcome this? I have a hard time finding out why LabVIEW runs into problems keeping up. Or would you say that the queed message handler is simply unsuited for fast readouts because inacuracy of software timeing (as I read in an other topic). But again if that is the case, I am lacking ideas on how to do it differently aside from sending larger junks of data and do not process all in realtime.

[mikeporter]

Perhaps, seeing some code would help? It is very hard to debug descriptions. There are many things that could effect you application.

Mike...

[Jacobson-ni]

I would suggest timing different sections of your code to figure out where the bottleneck is.  If your application is nicely broken up into SubVIs you can run your code and go to Tools > Profile > Performance and Memory and to see which Vis are taking the most time to execute.

[Bob_Schor]

Even without seeing code, I can assert that the Queued Message Handler is not slow.  I just cobbled together an example using a QMH that handled a million messages -- guess how many minutes it took?  3.5 seconds.  So in 10 milliseconds, you should be able to handle about three thousand messages.  Of course, what you actually do to handle the message has to be taken into consideration (in my timing case, I was incrementing a Shift Register and comparing it with a million to decide whether to send the "Continue" or "Stop" Message).

My Conclusion is that the problem is not with the QMH, but rather with the processing of the Message itself, which is taking "too long".

Bob Schor

[natasftw]

Be careful with your understanding of the waits.  What you said is only true if everything else in the loop finishes before that next multiple.  If the code takes 11ms to compute, the wait has no meaning whatsoever.  As soon as the code is finished, it'll run the next iteration.

If you skip processing and just read data, how fast can you get it?  that will give you an idea of the limitation of the software timing.  If it's much higher than what you're seeing otherwise, your processing is the problem and you should offload it into a parallel loop.  If it's not much higher than what you're seeing, you'll want to look into taking more messages per iteration so you can increase your throughput that way instead.

[drjdpowell]

What kind of visa communication are you using?  That would be my first guess at the slow point.