01-05-2016 06:42 PM
Hello all,
I'm trying to build an interface around the AMC7836 ADC/DAC combo device from Texas Instruments. This evaluation module has the AMC7836 board and supporting circuitry, and then a computer connection via a "SDM-USB-DIG" dongle, which appears to be a USB serial port that speaks ASCII @ 9600N1. The evaluation module comes with a demo GUI which is written in LabView, but unfortunately compiled and the VIs are not accessible. I've had some limited success reverse engineering the GUI and was able to extract the serial control codes that are being sent to the USB-DIG, of which I've posted about on the TI e2e forums.
I'm a complete beginner to LabView, and have been struggling to design an instrument in a reliable way. I'd essentially like to be able to recreate the basic functionality of the demo GUI (here's a screencapture of the interface), but as a LabView controllable instrument, so I can wrap my own application specific interface around it. I've worked out the serial strings I need to send to the device to initialise it and read and write its registers over serial, it's just LabView programming part that I'm somewhat stuck on - not knowing best practices.
I'd like to have sliders to control the ADC output voltages, and I've played with some event blocks to try and achieve that, but I cannot achieve anything working reliably.
Is there a best practice for creating a responsive GUI that might contain a few sliders, and then when those sliders are moved, a command to set the voltage is sent out over serial to the device, then another read command is sent and processed to display the readback voltage (the specifics of these commands is not important, they can be considered as just ASCII strings to be sent over to the serial device).
Attached is the code that I've been working on so far as a source distribution. If anyone could take a look at that and give me some advice, that would be much appreciated.
01-05-2016 07:44 PM
01-05-2016 08:57 PM
Thanks for the reply, I've included a picture of a little bit of what I'm working with that should comprise the whole problem.
Yes, I perhaps did mean event structure.
So if I have an interface that has 4 sliders to control 4 voltage channels, I'd need 4 independent while loops with a single event structure for each on-change event corresponding to each slider?
Here's what I have set up so far:
(the VISA resource name line to the "Enable DAC block" event is connected, but hidden by the event structure)
The program initialises a VISA serial port, sends the initialisation commands over the serial port and gets the device ready. So far, this works. From there, it enters the main loop where the event handlers are. To me, coming from a different programming paradigm background, the notion of what appears to be polling an event is strange (event structure inside while loop).
At this point, I can interact with the control panel of the VI, but only briefly before the whole thing locks up.
I've opened NI I/O Trace to see what happens:
In the above image, the first three serial writes are the initialisation sequence. The final two writes are due to me moving the slider for "A0". It seems my event structure is working. As an event is generated for every movement of the slider, I've worked around that by comparing the slider value with the new value present in the event data - this should activate the case structure when the slider is first picked up and then when it is released.
After being able to move the slider only briefly, the VI interface becomes unresponsive. I am not sure why this is the case. (I did set up a serial buffer of length 4096, but I'm not sure that's the problem) Any ideas why this would be happening?
The same thing happens with the pushbutton "Enable DAC block". I can click it twice and it generates two correct serial messages then the interface locks up.
A further issue with this is that my stop button never appears to work, and I'm not sure why this is the case.
I'm probably making a lot of newbie mistakes, but I hope I can learn from this.
Thanks
01-05-2016 09:32 PM
01-05-2016 10:13 PM
Thanks for your helpful reply 🙂
I've had a look at many tutorials, and every one seems to have their own way of doing things, hence why I've decided to ask on the forums.
If you could elaborate on exactly what is wrong (not "everything") with my VI, that would be tremendously helpful.
I've modified my VI to contain only one event structure and now the VI does not lock up and works as I'd expect, sending out serial commands when I move the slider.
From what I can gather, there's an event queue that needs servicing before the event structure will pass on control, hence why the second event sequence in the loop would not execute and the front panel would lock up. Moving to a single event structure with a larger event case inside it solves this problem, as one and only one event case is handled and then program flow is directed back to the main loop.
Following this, I had my stop button not working, but after a little more thought I understood why and moved it inside the event structure. This will guarantee that the signal is seen by the while loop's break immediately upon the value of the stop button changing.
Here's my updated VI:
Aside from not propagating errors in my write operations (as seen inside the case structure in the event structure), is there anything else fundamentally wrong with my VI? How would you do it?
01-05-2016 11:37 PM
01-06-2016 12:51 AM - edited 01-06-2016 12:52 AM
Thanks again for your input 🙂
How would I be able to achieve the sending of a serial message only once I stop moving the slider. I don't want a message to be sent when I first click the slider, or as I am moving it, only once I've released the mouse on the slider. I guess one could use the mouse up event, but is there a simpler way similar to what I've tried to do with the comparison (this generates less messages, but not precisely one)?
I say this as the serial bus speed is limited to 9600 baud and each message is roughly 14 bytes long. Dragging a slider over 4096 values generates a lot of traffic and cannot possibly be realtime.
01-06-2016 01:40 AM