Dequeuing Elements for VISA Write Optimization

[tbayrg]

Hello All,

I posted some time within the past couple weeks about this same main VI, however I have come across a new dilemma. I have some part detection and camera feed loops that result in enqueuing string inputs into a VISA write command for a PLC. They are custom string commands that are packed and compared in the PLC's program which is why they are in binary and not ASCII or something else.

The string inputs are for the feeding processes of parts, which there are 3 that are identical (one of the feeders has 2 parts which is why it looks different but the order of operations is the same). Right now, each process runs one at a time and rather slow, meaning they take turns going through each feed process when I need them to run simultaneously or faster so that its close enough. This could be a hardware limitation since its only a single PLC, but I am posting this to see if there is a better way to send these string commands or loop the dequeuing process for the desired results. 

I have attached a photo of one of the feeder loops and the element dequeuing loop along with the Main VI and the Subvi that handles the VISA write/read. You can ignore the other loops that are unfinished they are for robotic implementation. I am using LabVIEW 2020. If my code isn't easily readable please let me know, always open to hearing how to improve how I write it. 

[Kyle97330]

Well, one thing I note is that in many places, you have no backup if there's ever a problem with the condition for exiting a While loop.  I suggest you change any given While loop to terminate not only when your standard condition is met but also if there is an error on the error wire or if it exceeds a limit of either time or loop iterations, preventing you from getting stuck in an infinite loop.

This is pure insanity though:

As far as I can tell all the cases are the same as well, so I don't have any idea why you did that.

The main thing I am wondering is why you've got the 100 ms wait time in the loop that seems to be where all your PLC communications happens.  Does the PLC have a specific listed restriction in its manual that says something like "Don't send a command more than once every 100 ms" or is that self-imposed?  I see 100 ms waits in nearly all of your loops, so I wonder if someone told you to never make a While loop without a wait, and you've just been doing that ever since.  It is true that While loops can be "greedy" and eat an entire CPU core if there's no other restriction, but to combat that you can get away with a wait time of just 1 ms.  Even then, the need for a wait of any kind is not really a thing if there's any other code in the loop that has a wait in it, and "VISA Read" never returns immediately unless it's operating on a buffer of past communications, so it's even less necessary to include a "Wait" in a loop containing a VISA read.   

[tbayrg]

Thank you for the help,

The exiting of the while loops is an issue I was planning on dealing with in the future but I'll see how it works with what you've said. 

As for the insane amount of cases, those exist because the PLC being used has an existing program with those string commands in it. I know they are in fact each different because labview has thrown an error when I accidentally added 2 of the same. I haven't changed them yet because I am working on securing the functionality of my labview code before I start altering things in the PLC's code.

The wait times for the loops are self imposed and you nailed it because I have been under the impression that they were required to prevent CPU from being taken up. I'll see what happens when I remove the unnecessary ones and report back.

[Kyle97330]

On my 8-core system, here's a "greedy loop" with no wait in it:

And here it is with a 1 ms wait:

The loop itself is probably taking up even less than 0.2% because LabVIEW is doing other things (drawing windows on screen, refreshing scans of some directories it monitors, etc.) that take a bunch of CPU time as well.

As for the case statement of "pure insanity", I was referring to the fact not that the cases are all different or not, but that it seems that every single case causes the same thing to happen, that being that it just passes through the string in question and sends it to the PLC. 

Even if it did do different code in each case there's many ways to check to see if a string is a "legal" one in some way, and using a case structure like that is one of the most insane ways possible.  Case structures are best used when the case names are meaningful so you can find the one you're interested in quickly.

One good way to know you're using case structures wrong is to check if the number of cases is so large it doesn't fit on a standard-sized screen without scrolling. 

The case names in question are just 10-digit strings with each digit only being a 1 or a 0, so a "sane" method would be one that converted the string to an array of binary digits and checked that for legality using Boolean logic somehow.

[tbayrg · Accepted solution]

Ok I see what you're saying and that probably would make more sense so I'll go ahead and clean that up.

As for the solution to my problem, taking away the unnecessary waits away didn't totally fix my PLC write loop being too slow. I believe the problem was the fact that I was sending so many individual commands at once. It was much simpler to go into the PLC's code and include a new command string that combined parts of the feeding process for individual feeding systems and calling on that. 

Although I technically solved my issue, if you or anyone else has more to say on the topic feel free to respond and add to the conversation. Thank you for again for your help Kyle