VI architecture for reading multiple serial stream

[kerboiu]

Hello all,

I'm in need of a bit of advice. Let me first say that I'm not LabView expert, but sadly no one in my work enviroment uses LabView, so I have to solve this on my own. I know the basics of LabView, but with my current problem, I just lack the experience..

So what I'm trying to do, is simply read in three displacement sensors, that's it. I'd like to do this at roughly 100 Hz. The sensors can be adjusted via a program in terms of mainly Baud rate, but also some other settings. Furthermore, all communication protocols are already made into a dll library. There are some LabView example included with the software. One for just communicating, and two other for receiving data. The other two work in two different modes; One loops a request command at a certain frequency and request a single data point every time it loops. The other just sets the sensor at streaming mode and reads out that. I've added both examples below. The communication is already done via the dll, so I don't have to send the sensor command manually.

Now, at first I basically copied the 'request' version two more times, within the same loop and rewired the data writing part a bit. It works, but it goes way too slow (~15Hz) and changing the Baud rate doesn't help. Then I tried the streaming example since I seems logical to me that constantly requesting a data point is slower than just letting the sensor stream. So I adjusted the second example and tried firstly fit the same thing two more times in the same loop and later gave them their own loop (didn't try to extract the data into a file yet). In both cases it works, at sufficient speed, but weirdly the data lags behind the actual input (at the sensor end) several seconds. I'm really confused by this and I can't explain it.

I was wondering if any of you could take a quick glance and spot something wrong or maybe tell me what I'm doing wrong, because I can't really think why this doesn't work, but as I said, I'm no expert with LabView.

Thanks!

[kerboiu]

Oh I also wanted to add this file on both occasions, different Baud rates don't influence the performance at all.

[Sam_Sharp]

If you're calling a DLL - is it thread-safe and are you running it in thread-safe mode rather than in the UI thread? If you're running it in the UI thread, I believe the DLL calls will only happen one at a time (i.e. sequentially rather than simultaneously)?

I don't have time to look at your VIs but that was one thing that stood out from your post as what might be the cause.

[kerboiu]

I don't really know. I tried to adjust the example I got just by rewiring, is there any way I can check in which thread-mode I'm running?

[crossrulz]

In each of your DLL calls, you can edit the thread usage.  Double click on the DLL call to open the call properties.  But you should only change from the UI setting if you are 100% sure the DLL is thread safe.

[kerboiu]

Ah ok, I see, thanks!

I'm gonna give that a go later today, I don't know if it's 100% safe, but at this point I don't really care anymore, I just want it to work!

If the .dll could be the source of the problem though (could be since it always goes slower with more sensors, same .dll), would it be possible to rewrite it to a purely LabView VI without the .dll?

I've tried using the VISA example, but I never managed to get communication between the sensors, so I just went with the .dll version, but maybe if I can somehow rework to the VISA example to sensing those calls the .dll does to the sensor directly, I might circumvent the whole .dll slow down right?

Anyways, thanks, I'll let you know whether it works soon!

[DavidBoyd]

If the sensors are serially interfaced, and you can get a bit of documentation on that serial protocol, you can of course create some LabVIEW code to communicate directly to them (using NI-VISA), thus getting rid of the DLL.

Over the years, I've found that most vendor DLLs for serial instruments are far too limiting anyway.  Frequently they're not thread-safe, don't support serial interfaces beyond COM4, etc., and of course they're totally opaque when it comes to troubleshooting.  A native LabVIEW driver takes some time to create, test, and document (if that's important to you!), but gives you support for multiple concurrent interfaces (if done properly), and is debuggable, both within LabVIEW and using NI-Spy.

Your question also leads to larger questions about LabVIEW application architecture, where you want to communicate to N sensors, display N sensors, record data from N sensors, etc.  So if next week that three sensor project becomes a five sensor project, you adjust the inputs to the code, rather than rewrite the code.

First step: tell us the sensor make/model, and if you have any detailed info on its interface protocol.

Dave

[kerboiu]

Just running the .dll in 'any thread' doesn't seems to help. I still get a massive delay (stream mode) or slow running VI (request mode).

The sensor is this one:

The RF603

http://www.riftek.com/eng/products/~show/sensors/laser-triangulation-sensor

This is also where I got my example from. The manual is quite extensive, but I can't seem to get it to work with a custom VISA VI. The protocol is 1 start bit, 8 data bits, 1 odd bit and 1 stop bit. From the example I can also deduct how to convert the data to actual measured quantity, so I basically got everything to make a custom VISA VI. I linked up the sensors via an RS-232 cable and then each sensor via an FTDI chipset RS-232/USB adapter into my laptop. I only need 3 sensors definitely, just a VI for that will be more than enough.

[DavidBoyd]

I'm out of the office until Monday, but was able to find a good PDF on their website which seems to have the required level of detail. Reading it on an iPhone screen presents a little challenge 😉

I can't offer to write you a driver package - but maybe after a little more in depth reading I can create and send you a VI or two to try sometime next week, perhaps it'll get you kick started. This is NOT a trivial project, and I don't know your time constraints. But if you're resourceful, maybe this'll be enough.

PM me your email address.

Dave