LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Design pattern - Single instrument (data acquisition and control) over serial

Hi all,

I'm a fairly new user to LabView and have begun work on a device driver for a messaged based device. The device itself is an ADC/DAC combo attached to a SPI to USB Serial dongle. The dongle accepts ASCII control codes terminated by \n and responds with a prompt each time. (an example code to tx would be "01011105GH0000VVGI\n" with the device returning "device_name > [optional data]".
Communication with the device sends read and write messages that access device registers to either set or fetch their contents.

I'd like to have the interface first start with a serial port selection and a "run" button, then the device would go through an initialisation routine, and then the GUI would become available and in an active mode upon which a range of the ADC registers would be monitored (serial write for read register command and then a serial read for the result) at a fixed rate to update indicators as well as a range of slider controls available for the user to change DAC voltages (a serial message to update a specific register would be sent only once the user stops moving the slider).

I've had a go a tackling this problem via the use of a shift register state machine which allows me to proceed through wait->init->run->wait states, to where my run state comprises an event structure in a loop to handle user interaction with the sliders as well as a timed loop (for which the clock source is created during the init state) for acquiring ADC readings automatically at a fixed rate to update a set of indicators.


My problems have been stemming from the serial port, which seems to only work some of the time. If I plug the USB serial port in and start labview, I can run my VI and get through the initialisation state of my program, where a few messages are written to the serial port and everything is fine.

 Capture2.PNG
The VI state then proceeds to "run" and I'm usually greeted with an error after sometime about a VISA Write timing out (due to the timed loop) and I see in NI I/O Trace a failed VISA Write and the VI GUI locked up. At this point I'm forced to abort the VI. Running the VI again I'm lucky to get the serial port to work again without timing out imediately, generally requiring me to restart LabView. I'm fairly sure this is due to my misunderstanding of VISA serial devices, timed loops and event structures all interacting together. Can anyone speculate on what could be happening to cause this? I've tested the serial port with the included serial demo programs and can confirm it works correctly, it just seems to become very fragile when a VI is terminated without the serial port being able to be closed first. VISA Reads always seem to be causing issues.
I've had a look at the Instrument I/O Assistant instant VI, and it looks promising for what I need to do. I've only had the chance to test it with a Rigol DS1054Z oscilloscope over VISA USB, and it worked a treat. I'm hoping it will play nicely with my serial device when I go to test it with that.

I can't post my VIs as I don't have access to them right now, but I can update this post in 24 hours with them.


My questions are:

This seems like a common LabView scenario, what is the best applicable design pattern to apply to this task?
How can I avoid serial errors and "breaking" the serial port?
What are some sane debugging strategies, especially for serial I/O?

0 Kudos
Message 1 of 5
(3,520 Views)

In a Windows application, the Timed Loop just adds more overhead than it gains you.  Just use a normal While Loop with a wait inside of it.

 

As far as what exactly your problem is, we need to see some code to actually help.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 5
(3,476 Views)

Here's the general area in my program that's causing issues.
I feel it's due to the timed loop. It will work one time only when I step through it after a breakpoint, but from there it will throw an "unknown error". I believe this is due to not closing a VISA resource or something of that nature.
The error seems to be generated in ADC.vi, where some serial reads and writes are done, the same as in the initialisation part of the program that works fine. I've been using the Instrument I/O Assistant express VI, which seems to work very well on its own.

Will using a timed loop and an event structure in my main loop together cause problems, especially with VISA serial? I'm quite stumped.
Capture.PNG

Attached is the entire project.

0 Kudos
Message 3 of 5
(3,425 Views)

Hey Iberezy,

 

I've been looking at you code and had a question as well as some potential feedback.

 

Can you help explain the need for the timed loop within the case structure?


Also, seeing the event structure below, have you considered utilizing a producer/consumer architecture?  This best practice can also help folks on the forum best navigate and understand your code.  You may not have a specific use for this, so I could be mistaken.

 

http://www.ni.com/white-paper/3023/en/

Chris
0 Kudos
Message 4 of 5
(3,348 Views)

It's hard enough dealing with ADCs and DACs when they are connected to your PC directly, but now you are adding a serial interface into the mix!  Wow.

 

Something you haven't discussed are data rates and how the data are being transferred.  Generally, with an ADC, you say "Give me 1000 points at 1KHz", and know that a second later it will present you an array of 1000 numerics (maybe more, if you are doing a multi-channel conversion).  The timing is handled by the Hardware -- the DAQmx Read will wait until the conversion is done and then pass out the data.

 

How does your device handle this?  Does it start to stream serial data when the conversion is done?  Does this mean you need to "busy-wait", checking to see if there are any bytes at the VISA Input port?

 

Is your DAC a "shove a number in" one-at-a-time device (like the DAQs on, say, the USB-6009 and some NI Multi-function boards?  Or does it also have a clock and a buffer to be filled?

 

In any case, it is probably better to let your device take charge of the timing, rather than you trying to impose timing on it.

 

Bob Schor

0 Kudos
Message 5 of 5
(3,333 Views)