running serial task and AI task continuously

[JThorus]

Hello all

I am communicating with a third party serial instrument continuously while running an analog input operation. I have both the serial task and AI task in the same loop and seemingly regardless of the loop speed I get a timeout error - the serial read cannot complete in time. I suspect synchronization problems as I observe the error gets thrown after a longer time running the program when I decrease the loop speed. (I am controlling the loop speed based on the sampling rate and number of samples read for the AI task.)

I have read a lot of documentation on here about synchronizing various tasks but have never come across an example where a serial device is run along with an AI operation. Any advice on this? Should I have both tasks in the same loop?

Thank you for your time and I can provide more information as necessary. I have attached the main VI 'serial_minicone.vi' along with the serial sub VI 'tipdatasub.vi' and 'sleevedatasub.vi' which are very similar. The other two sub VI 'ai2.vi' and 'ai4.vi' just contain some arithmetic for the instrument calibrations.

Thank you!

Jeff

ps These VIs are in development so please forgive the lack of user-friendliness...

[MichaelBalzer]

Have you tried running the serial task in a separate loop or VI, without running any AI task? It may be the AI task is a red herring, and there are actual timeout issues when talking to the serial device.

Have you verified the loop rate is what you're expecting based on the AI task timing?

[Blokk]

I had a look at your VIs. There are several problems:

1. As I see, you try to collect data with DAQmx at a rate of 20 kHz? For sure this speed cannot be reached by RS232. Also, it is really really bad decision to do data processing in the fast DAQmx loop (ai2.vi, ai4.vi with Main calculations, etc.)!!! That will cause the timeout error which you see. Using a single loop in this case is just very bad!
2. Remove that unnecessery Flat Sequence Structure, use the error wire to decide data flow. Wire the error wire through the TDMS VIs too, and use the Merge Error function to bundle error wires at the end.
3. I would not use the Elapsed Time Express vi here. Just use a proper absolute time stamp - "Get Date/Time in seconds" (generated at the DAQmx loop) which you save in the TDMS file...

Here I would imagine you could use a Producer/Consumer design. I do not know what is your data acquisition requirement, but here you must make a decision. You have a slow RS232 and a fast DAQmx task. Assuming that you want to save the data at a rate of 4Hz (DAQmx 20 kHz rate, 5000 samples), you could use 3 loops: 2 producer and 1 consumer. If you do not need a tight sync between the RS232 and DAQmx data, I would just use a Queue for the DAQmx, this would send data from the DAQmx Producer to the Consumer loop. In the RS232 Producer, you could use a Notifier to broadcast always the most recent result to the Consumer loop (and use the "Get Notifier Status" in consumer loop).

And of course, process the data ONLY in the Consumer loop, you should have nothing in the fast DAQmx Producer loop, only the DAQmx Read and the Enqueue element (in this case the element is a 2D array).

[Blokk]

I tried to put together a quick example, note that, i did not have the time to properly clean up the VI, neither to program more proper intercommunication/error handling... But I hope it can give you some idea how to decouple different loops not to slow down DAQ...

Another thing, you should use LabVIEW project, to properly maintain your VIs, subVIs, and typdef controls...

[JThorus]

Great thank you both for your replies!

It turns out the AI task was a red herring as I received the same timeout errors when ONLY talking to the serial instrument (no AI task in the loop). My new diagnosis is that the carriage return character, which is appended both to commands to the device, and responses from it, was getting overwritten due to the VISA Write and Read functions executing one immediately after the other. This is not the most elegant solution, but I added 10 ms delays between each VISA Write and Read, and I have not had any errors since. I should note (there was a good debate about the best way to handle termination characters in my last post) I also tried writing the carriage return by explicitly including it in my commands to the device and had the same errors. So in this case it seems the VISA instrument properties END IN and END OUT are doing fine appending the termination characters. Any thoughts on the way I solved this problem (with the delays)??

As for the loop rate, by separating the serial instrument in its own loop, I realized the instrument is capable of receiving commands and writing responses very quickly, but the board on the instrument only updates the value of the tip load and sleeve load at about 3-4 Hz. So there is no reason to run the loop much faster than this. I can verify my AI sampling characteristics do in fact control the loop rate.

Blokk, thank you for posting this code. I have used queues before to separate DAQmx Read operation and data processing / writing to file, but I have not used a notifier to broadcast from a producer loop to a consumer loop. Very cool. Could you please explain the error handling? For example, if one of the VISA VIs in the Serial Loop throws an error, does the program stop? I would feel much more comfortable about running the program continuously if I knew it could get through a garbled command here or there.

Thanks!

Jeff

[Blokk]

Could you please explain the error handling? For example, if one of the VISA VIs in the Serial Loop throws an error, does the program stop? I would feel much more comfortable about running the program continuously if I knew it could get through a garbled command here or there.

Correct observation 🙂 No, if the Serial loop generates an error, it will stop execute, but the 2 other loops will NOT know about this error. So this is one thing should be fixed.

Since I always use a kind of Queued Message Handler design, where I have a Event Structure, I usually use a User Event to broadcast error from other loops toward the GUI (Event Structure) loop. And then the GUI loop "tells" the other still running loops to stop (or handling/reporting/logging error).

In your case, if you use my example VI, a possible "quick fix" for error handling could be the following:

• If an error happens in the DAQmx loop, first it should command the bottom Consumer loop to stop: so put a little Case structure after (or inside) the DAQmx loop, with anEnqueue Element function beside a "stop" command. Do not forget, this should still work in case of error, so do NOT connect the error wire through theEnqueue Element function. And finally, the Release Notifier will "kill" the top Serial loop. Of course, this loop itself must stop too, so insert a Boolean logic "OR" for the stop condition, and connect the error wire to it.

  

• If an error happens in the Consumer loop, it should stop the middle DAQmx loop, and then the Serial loop will stop as usual. A quick&dirty way can be that, if you get an error here, you create again a Case structure around the error wire, and use the "Release Queue" function (the "Release Queue" function can be wired through with the error wire, it will stay function even in case of error!). This will throw an error inside the DAQmx loop, thus stopping it. So finally all 3 loops will stop.

• If an error happens in the "Serial loop", you could use the "Release Notifier" there just right after the While loop inside an Error case. This will kill the bottom Consumer loop with an error, and it will do the same with the DAQmx loop.

As you see, this is not an elegant/sophisticated way to do error handling. You could have a look how error handling works for example in the Queued Message Handler, but it is a bit more elevated level of LV programming (I suggest to go through Core-1-2-3 online teaching material):

http://www.ni.com/webcast/3640/en/ 

Good luck!

EDIT: You could also use the Notifier from the top "Serial loop", to broadcast an error msg, similarly as the DAQmx loop commands to process data or stop the Consumer loop...Anyway, if you dig deeper into LV, you will see why the "User Events" are so useful 🙂

[JThorus]

Hmm I think I'm about halfway to understanding this error handling...haha. The way you explain how each loop is interconnected makes sense. I just need to understand the details. Will go through the suggested teaching materials and thank you for giving me a place to start!!

Jeff