Lag in duel VISA read write program plotting to waveform chart

[User002]

Hello, Hopefully someone here knows the solution, which may be hardware, but I don't know. 

I have two Ohaus digital weight scales that I need to plot data from simultaneously via RS-232. My biggest issue is that one scale works fine, and plots the change in weight in real time, whereas the other, there is a large delay that gets worse over time. 

Also, sometimes the scale outputs nothing for multiple loops, which my code reads as zero.

The scale, when it sends nothing, sends two bytes as \r\n. So at minimum, it sends two bytes no matter what. When there is a number, it's 9 bytes. It has a max weight of 8,200 grams and has been set to output numbers only so I don't need to worry about the unit 'g' at all. 

Any idea why one works in real-time, but the other builds up a lag? 

Thank you for the help in advance. 

[cstorey]

Does it matter which scale?  Meaning, if you physically switch them does one always show the issue?  If so, then its likely a hardware setting or cable/connection issue.  Have you tried interchanging RS232 cables or ports on PC?

I'd modify your code a bit too.  I'd add a small delay between Write and Read Bytes at Port.  I suspect the code execution might happen too fast on one scale and bytes at port is 0 for first read. 

You might notice a trend in forum posts, avoid bytes at port if possible.  You don't need to use bytes at port at all if you have nice termination chars.  You can just Write, short delay, then Read, check length and read again if <9.  In this case you would put the code for each scale in its own while loop.  That way you could really see if one scale is misbehaving in terms of what it sends back.  Also give the VISA Read 30 bytes (instead of bytes at port value) and see if you aren't getting some sort of garbage response when the first read doesn't work, like a \s or an extra \n.  

Craig

[User002]

Hi, thank you for the help. The lag still occurs but the added while loops makes it much better. I also added a sequence frame so that both loops had to have data before it plotted and this really helped minimize the lag and drops to zero. There were no unwanted characters sent from the printer, either it was somewhere between 3-9 bytes and gave me a number or just the two /r/n bytes. This is still a great improvement from before, and I think switched com ports the lag stayed with cable. I will check again in the morning. If it is the cable and is a hardware issue, I will accept your solution. Thanks again. 

[cstorey]

What if you make the delay 100ms instead of 5ms?  Or long enough so there's no lag and then decrease until you run into problems.  

[User002]

Hey,

So the while loops improved things but I tested the cable swapping and this is what I found. 

When I switched the entire cables, the lag stayed at the same COM-port. So it wasn't a cable issue. 

Next, I switched one end only of the cables, effectively switching the comport, and this time, the lag also switched. It seems to be from a particular scale. 

I use a 4-port RS-232 to USB adapter, so either this confirms its my scale, or possible the USB port not handling duel data correctly? 

The whole \r\n debacle was also solved. That was a formatting issue of the scales. Its print output and line feeds were set to multiple lines, hence the four \r\n between each byte collected. Switching this to single lines, I no longer have the issue of blank data. 

Do I need to continue using the while loops and byte check, or should I remove these?

Thanks again. We are narrowing in on the issue!

[cstorey · Accepted solution]

I'd keep those while loops make it a subvi and re-use for both scales.  No need for the sequence frame, that is probably causing some slow downs.

I would still advice two things:

     - make your reads more characters than you need, its just a buffer and you want it bigger than your possible reading.  That way if you get extra chars you will see them.

    - try making the delay longer and reducing it.  It might be you are just hammering at the instruments too fast.  Start long and reduce to as short as possible without errors.

Hubs can cause funny issues. You might think of using a PCIe card instead.  We recently solved a long standing intermittent problem with test equipment by moving controllers off the company supplied USB hub to PCIe card.   We used one of these - https://www.amazon.com/d/Serial-Adapters/Native-Express-RS232-Serial-Adapter/B00535BUR4?th=1

[User002 · Accepted solution]

Hey! 

This worked! I got rid of the sequence frame, and made the while loop into a sub-VI, and copied it for the second scale. For whatever reason, It had the lag issues at first, and increasing the delay didn't really help, and eventually made it unusable for the classroom demonstration for what its intended. However, this final block diagram and sub-VI is working great. It's running on a laptop and we must use the 4-port hub, because it is for a classroom setting in front of 200 students live! 

I just wanted to thank you again for you help. It is working now, so I will post the final pics for anyone else with the same issues. This was a working solution. I think the sub-VIs made all the difference. I also used a different laptop with less programs on it, which may also helped. 

Thank you! 

[cstorey]

Glad its working! 

So the code seems fine, the balances aren't the issue, so its most likely laptop and usb port settings.

My bet would be the USB port on the new laptop you are using is key.  Make sure that the Windows power settings are set to High Performance and the USB selective suspend setting is disabled.  See - https://www.sevenforums.com/tutorials/147369-usb-selective-suspend-turn-off.html

Good luck with the demo!