LABVIEW 2019 freezes around 8 min

[rohan_koka]

Hey guys,

I am new to the LABVIEW world. I have a program that communicates with Agilent N5770a power supply sources and outputs the voltage based on a predetermined power profile. To get the accurate power supply, I use the measured voltage and current to calculate the resistance and feedback this value to update the voltage using a shift register. Everything runs as expected for around 8 mins (495 secs to be precise) but after that, the program freezes and stops communicating with the power supply. I have to restart LABVIEW to re-establish the communication. I'm not able to understand the reason behind this. I need to run the program for long durations. Please help me with this issue. 

I am attaching the VI below. Any help is appreciated. 

[GerdW]

Hi Rohan,

---

@rohan_koka wrote:

I am new to the LABVIEW world.

Any help is appreciated. 

---

• The outer while loop should be a FOR loop: you know the number of iterations before entering the loop!
• The innermost while loop is not needed as it iterates only once!
• Do you really need to compare 5 to 1 all the time (again)?

---

@rohan_koka wrote:

Everything runs as expected for around 8 mins (495 secs to be precise) but after that, the program freezes and stops communicating with the power supply. I have to restart LABVIEW to re-establish the communication.

---

Do you need to initialize the communication in each iteration?

What happens when you start your VI with other input values in those arrays? Does that 495s change?

What happens when you don't try to command that device as fast as possible?

[altenbach]

OK, let's look at the code. Do you know who wrote it?

There are a lot of driver calls that we don't have, so the problem could most likely be there.

Silly parts:

• The innermost while loop is just a glorified sequence frame and serves no obvious purpose
• Your outermost loop is just a glorified FOR loop and array indexing could be done with autoidexing instead.
• There are no sanity checks. For example the array sizes and "number of arrays" (misnamed!) all depend on each other. Feels very fragile!
• Your time calculations should not have anything orange! Only additions with unsigned integers will correctly roll over at the range boundaries.
• Do you really need to initialize the instrument with every iteration of the loop? Especially since you never close it!
• Useless code everywhere. I cannot imagine a situation where 5<1, so that part is always FALSE and OR'ing it with another boolean just returns that other boolean, right? Why so complicated?
• Why don't you put an error indicator inside the loop so you can track what's going on?

(EDIT: Ah, Gerd was faster than me and already pointed out some of the same problems while I was writing :D)

[rohan_koka]

Thanks for your comments. I cleaned up my program a bit to implement the changes you suggested. 

I think I might have narrowed down on the issue here. I looked at one of the driver files which seems to save the Instrument name for each iteration (picture attached below). When the Labview freezes and I try to run it again, the resource name is filled up with the same instrument names with (1),(2),.. in front of it.

I am using the Agilent N5700a driver file (http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=35046833B7872E93E0440003BA7CCD...).

I made a duplicate of the driver file so that I can make changes to it. Can you please suggest what changes I can make to this file to stop it from 'accumulating' the resource/instrument name? When I tried to remove the resource name connection and run I got an 'Acess Violation error.

Am I wrong in thinking this might be the issue? Please let me know your thoughts. 

Thanks again!

[FireFist-Redhawk · Accepted solution]

Without even having the dependencies, I can point you to one possible reason: you are re-initializing the device everytime you take a measurement! Which means you are generating hundreds/thousands of unique instrument handles (that you aren't closing). The "Close" you have at the very end will only close the last instrument handle you opened.

Initialize once, at the very beginning, and close once, at the very end. And carry the instrument handle on a shift register.

Spoiler

[Kyle97330]

That looks like an "initialize" VI.

Instead of modifying the driver code, it's probably best to change your code so that this VI is only called once at the beginning of your code to get the reference, and then just re-use the output wire.

You might be able to get away with just constantly closing the reference at the end of each loop, but it's a bit silly to constantly be opening and closing the same reference each loop.

I don't have 2019 installed so I can't look at your actual VI though...

Edit: Never mind, Redhawk posted basically the same thing but faster and better before me...