How to send different types of data periodically over Serial Port?

[RavensFan]

When you say it is not working, give some details.  What is it doing wrong?  What part is not working?  Where do you first notice the issues?

One thing you should do is put a small wait statiment in your upper loop.  Right now you have a greedy loop which is running that subVI as fast as it can which eats up CPU cycles.  Put in a small, perhaps 50 msec wait.

For the lower loop, nothing is jumping out at me right now as being wrong.  Of course I can't run your VI because I don't have your hardware.  Put more indicators in there (such as on the string from the VISA read with hex display on so you can see the data right away.  Be sure to use probes.  You can also use highlight execution, but sometimes that can be problematic because it dramatically slows down your code which can cause timing issues when you are working with other things like DAQ cards and serial devices.

I would recommend looking at the online LabVIEW tutorials
LabVIEW Introduction Course - Three Hours
LabVIEW Introduction Course - Six Hours

How to Learn LV

You tube tutorials can be hit or miss.  You may learn something, but there are a whole lot of bad ones out there as well.  I'd recommend sticking with the ones hosted on the NI site.

Also search the forums for books, there have been quite a few threads listed some very popular LabVIEW books.  I don't remember the names from the top of my head.

[crossrulz]

You have a data dependency between your bottom and top loop.  You should use a local variable of the stop button for stopping the top loop.

[RavensFan]

I completely missed that.  The green line didn't jump out clearly to me on the screen.

Plus I would have assumed the original poster would have paid attention to what was said and wouldn't have created the exact same problem on another wire while fixing the problem on the original wires!

[xpress_embedo]

---

@RavensFan wrote:

When you say it is not working, give some details.  What is it doing wrong?  What part is not working?  Where do you first notice the issues?

At that time, what i saw is that my Upper Loop is not executing and the reason behind that is the way i connected the Stop Button form Lower Loop to Upper.

But that part is corrected now, i used a local variable and it starts working, but with huge delay, i think it is of 10 second and this happens due to serial read which has default timeout of 10seconds.

If i reduce this timeout to 1 second, then i get packets easily if configured to send at the rate of 1 second per packet.

Similarly if want to send packets much faster suppose 200msec per packet, then if serial timeout configuration timeout must be less than or equal to 200msec, otherwise i will get packet at slower rates.

Is this fine, till now it looks that if reduced the timeout value to 100msec then this problem will get solved. ??

But is this the correct way to do the things.

One thing you should do is put a small wait statiment in your upper loop.  Right now you have a greedy loop which is running that subVI as fast as it can which eats up CPU cycles.  Put in a small, perhaps 50 msec wait.

Thanks for the suggestion, i updated this, added 50msec in the upper loop and my CPU usage reduced, without delay it was around 34-40% and it is 0-1%

For the lower loop, nothing is jumping out at me right now as being wrong.  Of course I can't run your VI because I don't have your hardware.  Put more indicators in there (such as on the string from the VISA read with hex display on so you can see the data right away.  Be sure to use probes.  You can also use highlight execution, but sometimes that can be problematic because it dramatically slows down your code which can cause timing issues when you are working with other things like DAQ cards and serial devices.

 Highlight execution works properly for sending part but if turned on i a not receiving data from serial port, may be that makes things slower.

Even i am not using my device now, i had created virtual serial port in my PC and shorted the COM1 and COM4, and using HW Hercules software to send and receive packet.

The packets i am using to simulate the things are as follow:

2C0302012427 -> Ultra Sonic Sensor

2C02010100 -> Turn on LED

2C02010001 -> Turn off LED

Once finished i will do real time testing with my device.

---

[xpress_embedo]

---

@crossrulz wrote:

You have a data dependency between your bottom and top loop.  You should use a local variable of the stop button for stopping the top loop.

---

When i created a local variable for the stop button, i am not able to connect it.

On searching i found this link

Stopping Parallel While Loops in LabVIEW With One Stop Button

http://digital.ni.com/public.nsf/allkb/267704CDE91156D186256F6D00711AAE

"Since you cannot use a local variable with a Boolean control that is set to a latching action, it will be necessary to right-click  your Stop Button control on the front panel and select Mechanical Action»Switch Until Released.  This setting will toggle the Boolean Control back to false after the VI stops execution, which is desired."

I used this method to stop both loops using single stop button, i tried the other property node method but that doesn't work for me, don;t know why, i am getting the string output as the value, but that's not the problem as the first method works for me (By creating Local Variable).

[xpress_embedo]

Here is my updated VI.

I changed the timeout value to 100 msec.

Please provide suggestions how can i further improve this VI. Complete project is also attached at the bottom.

One more thing i would like to add in this VI, which is number of retries.

Right now i am just sending two types of packet, which is OP_LED and OP_SENSOR, and these are query packets, my device will return the exact status whenever it receive these packets.

So suppose LabVIEW sends OP_LED packet and got OP_LED response, but a case when it doesn't get response it will try for two more times by sending OP_LED packet and after that report communication failure error.

I am planning it to do like this, initially every packet has its retry count, count of zero means no need to send this packet, whenever a packet is transmitted a current count value is incremented, and if response to that packet is received then current count is reset and if not t will try for retry count set for that packet and when reaches the terminal point it will not send the command again.

I am planning to do this with Global Variables as my data is in two different loops.

[RavensFan]

My opinion is that the default timeout on the serial configure of 10 secs is way too long.  I'll typically make mine 2 seconds.

As for what you wrote about the timeoute value and the rate you are sending data, you've got that completely backwards.

You want your timeout to be just a bit longer than whatever is the longest time between data being sent.  If your device sends every 1 second, then you don't want your timeout to be 1 second or less.  It will wind up timing out before you get the message or even in the middle of it coming in.

Timeouts affect how long to wait before returning an error if data is not coming.  It doesn't affect how fast the data is coming.  A longer timeout doesn't slow down the reading of packets.  It only slows down how fast the loop iterates when the data is not coming.

I'm quite sure you don't want timeout values as low as 100 msec.

If your data is supposed to arrive every second, set  your timeout value to 2 seconds.

[xpress_embedo]

---

@RavensFan wrote:

My opinion is that the default timeout on the serial configure of 10 secs is way too long.  I'll typically make mine 2 seconds.

As for what you wrote about the timeoute value and the rate you are sending data, you've got that completely backwards.

You want your timeout to be just a bit longer than whatever is the longest time between data being sent.  If your device sends every 1 second, then you don't want your timeout to be 1 second or less.  It will wind up timing out before you get the message or even in the middle of it coming in.

Actually my device will not send any data until LabVIEW asks for it, when LabVIEW sends OP_LED packet then my device sends back the OP_LED status, and similarly for others, and i think it will be instantenous or may be in in few msec less than 5msec.

Timeouts affect how long to wait before returning an error if data is not coming.  It doesn't affect how fast the data is coming.  A longer timeout doesn't slow down the reading of packets.  It only slows down how fast the loop iterates when the data is not coming.

Yes i agree but in my case it slows down other loop as well, don't know why? maybe something is there which i am not able to understand as i am new to LabVIEW just started two or three weeks ago.

I'm quite sure you don't want timeout values as low as 100 msec.

If your data is supposed to arrive every second, set  your timeout value to 2 seconds.

As already told above that data comes when LabVIEW sends command.

---

One wierd thing i noticed is that, when i run my VI, LabVIEW sends packet properly and as per timeout of 100msec i must get error if no data is received, but i didn't get any error.

If it due to the reason that writing and reading are in two separate loops and as per timeout occurs when you send data and data is not received in the specified timeout time,

[RavensFan · Accepted solution]

I thought you put the VISA reads into a separate loop because it was sending data continuously whether you sent a command or not.

If you need to send a command in order to get a response, then don't use separate loops.  Put the VISA write into the same loop as the VISA reads.

There is no reason for one loop to slow down the other, so I have no explanation for what you are saying.

[xpress_embedo]

Well thanks, you guys help me alot.

I am really thank full to tou guys.

Still this design has lots of flaws but good thing is that its working, see below, i tested it with my device.

---

@RavensFan wrote:

I thought you put the VISA reads into a separate loop because it was sending data continuously whether you sent a command or not.

If you need to send a command in order to get a response, then don't use separate loops.  Put the VISA write into the same loop as the VISA reads.

I did it, now both read and write are in same loop, it doesn't effect much, if data is coming then everything is fine.

I added one more thing in this, if i didn't get response from the device LabVIEW application will send command only three times after that it stops.

This is also working fine, i used global variables for this purpose. But still there is lots of scope for improvement in that section.

There is no reason for one loop to slow down the other, so I have no explanation for what you are saying.

---

Block Diagram, i added 5 millisecond delay in the main loop.

This is Working LabVIEW VI  

Now i will start with LabVIEW Introduction Course - Six Hours as Three Hour course link is dead.

Thanks once again.