LabVIEW program crashes after running for few hours

[johnsold]

I do not have your subVIs so I cannot see what is happening in those.  SInce 7 arrays pass through the subVI, multiple memory allocation problems could occur as a result.

Looking at the lowest array/shift register in the loops and the "ramp" case, we see a classic example of how to create a memory problem. The image shows the Build Array inside two loops with shift registers.

Arrays in LV occupy contiguous memory locations.  When the array gets to be one element larger than the space allocated, LV will seek another space, large enough for the whole array plus some margin, and move the entire array there.  When that space is used up, the process repeats.  Performance gets slow and eventually no more memory is available.

The better way is to pre-allocate the largest memory space you will need outside the loop and use Replace Array Subset inside the loop.  You may need to add another shift register to keep track of the array index of the element to be replaced next.

Other comments: The use of local variables is discouraged.  As you are using them, race conditions may well occur. Use wires.  And shift registers.

While loops inside while loops are usually not necessary and may be tricky to debug.  If you need to repeat the "ramp" code many times, just feed "ramp" back via the shift register.  It looks like you are trying to make a state machine type of architecture.  State machines are powerful and often the preferred architecture for programs like this. Use the power of the state machine to simplify the "ramp" state.

Lynn

[TiboD]

Wow thank you for the advise, I'll try to re-arrange my arrays so it can allocate enough memory. I guess if I set my time step to a bigger value (now it's taking a measurement every 100 ms), it will take less memory than the usual...?

I'm using local variables mostly to put values in my controls to avoid typing them one by one, you think I still need to change it and use wires with shift registers?

[johnsold]

Generally you set your time step based on how fast you need to get the data.  Certainly a longer step will result in less data.  A better approach might be to write to the file after you have accumulated a certain amount of data or after a specified time interval.  After saving data you reset the arrays to the default value and continue accumulating.  Thus, you decide how much data you keep in memory and set the save intervals accordingly.  This has the advantage of minimizing the amount of dat lost in the event of a power failure or other malfunction.

You are reading the locals in several places, sometimes multiple times inside the same case (the while loop inside "standby").  Using locals to write a value to a control during initialization is one of the (few) justifications for using locals.  Read locals are almost never needed.

An example of a race condition may exist in your "standby" case.  You write a False to Save.  The terminal of the Save control is also read in the same case. Which one occurs first? You cannot tell.  LV may not even always read them in the same order.  Both will probably be read before the while loop completes, but that is not guaranteed.

Lynn

[TiboD]

Well actually your solution is exactly what I need, I just spoke with my advisor this morning and he asked me to program a saving process every 10 minutes.

Do you have an idea of how I can make it? I need to write in the same file underneath the previous values if you see what I mean

In my "standby" case, I use local variables just to get pop-up messages if the user forgot to set a value in an important control. I don't use multiple times the same local variables (hours, minutes and seconds are not for the same controls 🙂 )

Indeed in my "standby" case I have to change the save function because as you said, LV can't know which one to read first

Thank you for the heads up!

[LabJackSupport]

---

even when I just keep the USB connected to the U6 and I unplug the U6 from my power supply, it will go to 157 Volts again 😞

---

Sounds like the control inputs are not biased to 0, so perhaps you could do that.  Try putting resistors from "I in" and "V in" to ground.  In general you want the biggest value that holds the inputs low if nothing is connected.  Try 10k.  Put these right at the power supply connector so they hold your supply control inputs low if nothing is connected.

[johnsold]

TiboD,

I am not sure exactly what you mean but I think you want to use the same file and append data to it.  You already have the Append to FIle input set to true.  So after you write to the file, just clear the arrays.  The next time you save, the newly accumulated data will be written at the end of the file.  You will want to arrange things so that you only write the header the first time you save. You will need to pass the file path in a shift register so that it uses the same file every 10 minutes without prompting the user each time.

Lynn

[TiboD]

Actually I spoke to my advisor again and now he's asking me another thing.

He wants me to program my save case so that when you hit "START" button, a pop-up window will appear BEFORE the experiment begins and asks you where you want to save the file.

Once you've set the path file, he wants the file to be written every half-second (my actual time step is now 500 ms, so each time there's a measurement made, we want to write it in the file) so that when LV crashes, we have the file with the saved values anyway.

Do you know how to do it? With my saving function, the pop-up window will appear only at the end of the experiment when you hit the "STOP" button so I have no idea how to do it...?

Thank you for your answer again!

[johnsold]

Yes, I know how to do it.  In fact that is the way I would do it.

I would add a state to your state machine. It would be a file initialization state.  In that state you create the file and write the header information.  If it is created successfully (without error), pass the file path to a shift register.  In the Save state you no longer need (or want) the header information and you need to clear the data arrays.  Since Write To Spreadsheet file closes the file after writing you do not need a close file state.

You also need to change your next state logic so that the saving takes place automatically after each time interval rather than requiring the user to press a button.  Also, do you want to save again when the Stop button is pressed?  If not, you will need to change the logic there.

Lynn

[TiboD]

Hi Lynn,

Thank you for the tips, I'll try it!

To answer your question, I don't need to save data once I pressed the STOP button. Pressing it means that we are done with the experiment so we no longer need to record data.

PS : in your solution, how do we know that the pop-up window will appear before the experiment begins?

[johnsold]

When you call the Write to Spreadsheet File.vi or the Write Characters to File.vi with no path connected to the input, they pop up dialog asking for a file. So all you need to do is to make sure the Write Characters... (which writes the header) is called before you start the experiment.

Your program now starts in the "standby" state.  When Start is pressed (if none of the other conditions prevents), then you go to "ramp."  The change you make is to go to "Initialize File" after start, then from there go to "ramp."  This is basic state machine operation.  If you are not familiar with it, please do a little research and learn about it.

It is a good idea when working on a complicated program of any type to carefully design the program before writing the code.  In the case of the state machine you should have a good state transition diagram.  This will document all the states and the condition which determine the transitions from one state to another.

Lynn