VI works properly every other time

[EMorrison]

Hello All,

I am fairly new to labview, but not programming. I have created a VI that controls an electronic load via inputs from a CSV file. The VI communicates with the load via a NI USB to GPIB converter. The driver for the load is from the NI find drivers page. The problem I am having is that the load follows the commands every other time the VI runs unless I close out Labview entirely and start fresh each time.  This leads me to believe that there is some buffer that is not properly cleared after the VI closes. I have attached the VI and a sample CSV file but I don't think anyone will be able to use it without the load. So I guess my question is, how can I return the VI to a virgin state at the begining of a run without having to close out labview all together? I have checked "Clear Indicators when called" but that just makes it look like it was fully reset. Also, why would it work every other time it is run without being completely closed? To be more clear on that point, I open the VI and run it. The VI completes as expected and returns to the editor. I click run again and it does not appear to communicate with the load during this run. After it exits back to the editor, I click run again and it works as expected once again. This pattern repeats indefinately.

Thanks in advance ,

Eric

[GerdW]

Hi Eric,

beside learning usage of basic array functions you should NEVER use a STOP (or QUIT) function in your code.

This could be the reason for your problems: due to immediate STOP some controls (with latching behaviour) may be confused…

[crossrulz]

Some general comments.

You should look into using the Event Structure to capture your button presses and then keep your data in shift registers.  This would eliminate your local variables.  We try to avoid using local variables because they break data flow and open you up to race conditions.

Don't stop your program with the Stop function.  That is basically aborting your VI.  Instead, pass a TRUE out of your case structure to the conditional terminal of the loop.  This will allow the VI to stop on its own in a very clean way.  I suspect this is what your issue.

[EMorrison]

Thanks all for the comments. I have updated the VI to exit the program properly. This has not cleared up the issue. I will also look into using events to monitor button presses.

Thanks,

Eric

[RTSLVU]

I see you are using a TDI/Dynaload DC electronic load.

My condolences 

I hate to say it but part of your problems could be the fact that the Dynaload VI's are crap (unless they have improved them in the last couple years the Dynaload VI's are some of the absolute WORST examples of LabVIEW programming I have ever seen)

AND to make matters worse there is a "bad" firmware revision in some of the Dynaloads that had remote control issues. But I can not remember the exact revision.

Also in general:

1. lose all the flat sequence structures let the data flow do the sequencing
2. Don't make your program one big loop 
3. Break your tasks down to steps and use a state machine (this will eliminate 99.9% of flat sequences)
4. In this case a producer/consumer architecture might work nicely 
5. You have a lot of local variables, that's trouble brewing  

[EMorrison]

RTSLVU,

While I am clearly not a labview expert, I agree the VI's from TDI leave much to be desired. I have had my suspicions that the supplied driver VI's may be the problem, but my inexpeirence is logically the first place to look for faults. I'll see what I can do to remove a lot of the sequencing. I'm still trying to shed the structured programming logic and embrace Labview's flow ideology but old habits die hard. Proper training is in the future, but there are things I have to accomplish now. I'll forge ahead and learn from my mistakes and take advice from here as needed.

Thanks,

Eric

[RTSLVU]

Here give these a try, I have updated them to use VISA and kept some backwards compatibility.

[mikeporter]

While the drivers you have might be a particularly pathological case, there is a general lesson to be learned here:

Never trust drivers you get from instrument vendors. They almost universally stink. Also never blindly trust instruments either. You will find bugs in instrument firmware, so before you use a command, test it to make sure you understand not only what it does, but the "side-effects" it has.

Finally, be very, very, very careful when using old instruments. There was a time when the GPIB interface was put on for marketing purposes and often didn't work very well. (Yes, HP. I'm looking at you.)

Mike...

PS: Just had a thought, does the fact that I can remember when HP made rack and stack instrumentation make me old?  

[crossrulz]

---

mikeporter wrote:

PS: Just had a thought, does the fact that I can remember when HP made rack and stack instrumentation make me old?  

---

You mean before they were bought out by Agilent and then spun off into Keysight Technologies?  Oh, the spin off isn't completely official yet.  Well, give it a few months.  But, yes, that does make you old.

[Dennis_Knutson]

I feel pretty old too. I was doing a contract at Loveland/Fort Collins when the Agilent spinoff was announced. There were an awful lot of unhappy campers.