LabVIEW
VISA_ARDUNO_CHANNEL WIRES
Solved!
Hi all!
A little context, using Arduino UNO I must acquire a maximum of 6 channels through the A / D converter of the micro, long ago I used LINX to communicate from LABVIEW but it was not for the low sampling frequency that I obtained, a maximum of 122Hz Because of this I did two things:
1) I started using 'channels wires' to optimize and isolate the acquisition stage from the rest of the program, with which I am happy so far.
2) I started using VISA to communicate with the micro and with a couple of instructions to acquire at a higher speed. Currently I reach 300Hz with stability. If I continue to increase as much data is lost ...
There are some questions I would like to ask:
1) Is the code to communicate through VISA (I send a character and wait for the answer) optimal? Is it well conceived? I have never worked with VISA so I have doubts, I attach the complete code. The Arduino sends me the reading of the analog inputs through the serial port as follows:
"Read1Read2 ... Read6 \ n" then separate it in Labview.
2) Am I using the 'channel wires' correctly? When I start reading from the serial port it takes a few seconds to start displaying data on the waveform chart, I don't know why.
Please I need advice, thank you very much in advance !!
I haven't looked at your zipped project but from your picture I can see you are doing it wrong. You can search the board for "Bytes at Port" and find out why you shouldn't be using it in great detail.
Since you are not using LINX already I have a couple suggestions
- Use the Serial.PrintLn function as it appends a Termination Character
- Send all of your data from the Arduino in one big chunk separated by commas
- Serial.PrintLn (sig1,sig2,sig3,sig4)
- Here's some code to start with. I only show the important parts
Now LabView will wait at the VISA Read until it received the Term Char or times out.
First, I suggest you put commas between your outputs on the Arduino. This is will add a deliminator between your values and make it much easier to read. You might want to also fix your indenting to make the C code easier to understand.
void setup()
{
Serial.begin(115200);
}
void loop() {
if( Serial.read() == '1' )
{
Serial.print((float)analogRead(A0)/1024*5);
Serial.print(',');
Serial.print((float)analogRead(A1)/1024*5);
Serial.print(',');
Serial.print((float)analogRead(A2)/1024*5);
Serial.print(',');
Serial.print((float)analogRead(A3)/1024*5);
Serial.print(',');
Serial.print((float)analogRead(A4)/1024*5);
Serial.print(',');
Serial.println((float)analogRead(A5)/1024*5);
}
}
And with that update, on the LabVIEW side you can just use Spreadsheet String To Array to convert the read data into the values. For the read part, just write your "1" and then do a read with more bytes than you ever expect to read in a single line of data. In this case, I used 100. The termination character will tell the VISA Read when to stop reading. For more details go watch this: VIWeek 2020/Proper way to communicate over serial.
As far as channels, at first glance I would say you have way too much. But I did not examine the code to figure out what all you were trying to do. You might want to look into a Queued Message Handler or I think Bob made a Message Channel Handler. Speaking of Bob, he is the Channels expert, so I will defer to him for the rest of that. I am an instrument communications expert.
@crossrulz wrote:
First, I suggest you put commas between your outputs on the Arduino. This is will add a deliminator between your values and make it much easier to read. You might want to also fix your indenting to make the C code easier to understand.
void setup() { Serial.begin(115200); } void loop() { if( Serial.read() == '1' ) { Serial.print((float)analogRead(A0)/1024*5); Serial.print(','); Serial.print((float)analogRead(A1)/1024*5); Serial.print(','); Serial.print((float)analogRead(A2)/1024*5); Serial.print(','); Serial.print((float)analogRead(A3)/1024*5); Serial.print(','); Serial.print((float)analogRead(A4)/1024*5); Serial.print(','); Serial.println((float)analogRead(A5)/1024*5); } }
And with that update, on the LabVIEW side you can just use Spreadsheet String To Array to convert the read data into the values. For the read part, just write your "1" and then do a read with more bytes than you ever expect to read in a single line of data. In this case, I used 100. The termination character will tell the VISA Read when to stop reading. For more details go watch this: VIWeek 2020/Proper way to communicate over serial.
As far as channels, at first glance I would say you have way too much. But I did not examine the code to figure out what all you were trying to do. You might want to look into a Queued Message Handler or I think Bob made a Message Channel Handler. Speaking of Bob, he is the Channels expert, so I will defer to him for the rest of that. I am an instrument communications expert.
Allright!! I will make those changes right now! What I am trying to Do is to increase frequency as high as I can.
How can I talk to Bob?
I used a message handler with channels. Like a labview example that I saw.
Thank you both a lot!!
@Bob_Schor wrote:
Who uses .llb files anymore? I thought they (functionally) went away when LabVIEW Project was released, around LabVIEW 8 (I know Project wasn't there in LabVIEW 7, and poorly-designed .llb structures were the bane of my first introduction to LabVIEW ...).
Functionally, llbs and projects are completely different. Projects are just a way to organize a project. llbs are a way to store files on disk; a form of zip file if you will. llbs are not used much anymore mostly due to source code control (SCC) works better when all of the VIs are separate.
re: .llb and LabVIEW Project (with thanks to crossrulz for explaining the important and essential difference). I started my LabVIEW experience by being handed a large LabVIEW RT "project" (in LabVIEW 7.0) with about 1000 VIs and controls, with maybe 100 "buried" in .llb files. The VIs were further divided on disk into separate function-related folders under one top-level folder. I'd heard of Version Control Software (Perforce, to be precise), but had no experience with it.
A year or two later, I got my hands on a later version of LabVIEW that included LabVIEW Project (a way to organize your VIs and TypeDefs in a functional tree-like structure similar to what I was doing on disk) and our School started a Subversion Server with Tortoise SVN as the client. I unpacked those LLB files so fast and simply put them in their own sub-folder -- so much easier to handle!
re: Message Handler architectures (the Queued Message Handler, QMH, and the Channel Messenger Handler, CMH). LabVIEW's Queued Message Handler (there's a QMH Template you can check out) is a quite famous and well-documented Design Pattern (do a Web Search for Queued Message Handler), which has given rise to the DQMH (Delacor Queued Message Handler), an award-winning extension that is really quite sophisticated (and also well-docuemented).
When Channel Wires were released, I realized that Messenger Channels could replace Queues in the QMH and make a "visually-more-intuitive" metaphor for what the QMH was trying to do. What I did was to substitute a Messenger Channel for the Message Queue, and explicitly run the Channel Wires "as the data flows", namely from the Send-next-Message Message sub-VI out the right-side (output-side) of the While Loop, up and over the top of the loop to the input side ("feedback loop"), joining the initial first Send-next-Message sub-VI that starts the loop and connects with the Receive Message just inside the While loop that dispatches the next "Message" according to the Message contents. Here is a picture:
This is the LabVIEW QMH created by the Template, but with Messenger Channels replacing the Queues (note the VI Icon in the top right of the picture says "CMH", and you can see the Messenger Channels carrying the Message Clusters (pink = Cluster color) as "pipes" entering from a "Send Message" VI just before the Message Loop and ending on a Receive Message VI, and the subsequent Message being generated just before the loop ends, with the Message going "out" the right side, looping over the top of the Message Loop, and coming back in as an input. Also notice that the "pipes" do not "tunnel" through the walls of the While and Case structures -- they sit on top of them, thus not "obeying" Data Flow (which is why they are technically called Asynchronous Channel Wires).
Here's another, simpler State Machine Demo using Channel Wires:
I called this a "Channel State Machine", as the Channel Wire in the Feedback Path (here Blue, the color of the State Enum) only carried "Next State" information. But note there are other Channel Wires here, including a Stream Channel (orange) implementing a Producer/Consumer design, with the Stream's build-in Sentinel feature (yay!), and a Tag Channel (green) used only to shut down the Event Loop when the Producer executes its final Exit state.
I encourage you to explore Channel Wires (as David Foster Wallace would say, I.F.I., which means "If You're Interested") and, drawing on the LabVIEW skills you already have and the examples/tutorial that ships with LabVIEW on Channel Wires, to create your own version of a State Machine and/or create a QMH from the QMH Template and replace the Queue routines with equivalent Messenger Channel routines to get the first "picture" I showed. Your efforts will be rewarded ...
Bob Schor
