VI's bogging down?

[chuggins143]

Ok, you guys asked for it... here is my current catastrophe.

Typically the "Primary 1 Flow Readout" and "Primary 1 Sp Readout" loops are not running.  I'm still a relative noob when it comes to LV programming, but what I have here runs and does what I want it to do.  There are some VI's that you guys probably won't have... they are for running a DAQ board and a relay board from Measurement Computing.  I don't remember exactly which ones load, but they are needed, just let me know and I'll post them up. 

Thanks for taking a look!

C

[aeastet]

OK a few things to talk about before we start troble shooting.

1. Try to make your VI fit on one window!!!!!! It makes it much easier to trobleshoot.

2. You did not include the vi that collect data but I am assuming that you are using DAQ assastants for that. They are good to get started with but not for long tearm.

3. Using local varibles on a diagram as big as your is very dangerous. You can have chase conditions very easily. Do you know what a chase condition is?

Try and condense this code down to one window and repost it.

[Ray.R]

catastrophe is right 😉

Okay..  first thing is that you need to understand data flow and data types.  You should not coerce signals to doubles, boolean, integers.

I have some missing VI's.  However, we would probably need your data file to do a trial run and observe the execution under highlited execution.  Which you can do yourself.

I have a feeling that at one point in time, the code triggers a condition which executes a different portion of the code, thus resulting in the "bogging down".

You could set some breakpoints in the code to trap the execution just before it bogs down and set some probes to find out their values.  That way, you can focus on the state that the code is in just before bogging down.  At that time, you can use the highlited execution, otherwise, it would take way too long to get there.

[aeastet]

A few more thoughs after exploring your code.

1. Do you know how to use event structures?

2. If you are going to place a control or indicator give it a useful name boolean or boolean 4 is not useful especially when trying to troubleshoot.

3. Property nodes are very slow. Only use them when you need to. We can talk about that when we get so of the other stuff fixed.

4. You should try and get rid of the dynamic data types in your code. That is the dark blue colored lines. double or interger data would be best and faster.

That is what I see for now. That should keep you busy for a day or so. When you get this working then we can start trouble shooting.

Also the other VI's that you did not include could also be causing the problem. I did not see anything jumping out just yet could you include the other vi's too?

[Ben]

Cleaning up the code will help us help you.

Creating some sub-VI's will also let you use the profiler to determine what part of the code is affecting you.

Try putting a case structure (your code in true case, wire a false constant to the selection terminal) around the code where you are writing what appears to be a log file. You have it set to append so as the file grows, so does the amount of time required to update it.

If the code does not obg down after you do that, serach this site for "Producer Consumer" design pattern to see how your logging can be moved out of your main loop.

Ben

[chuggins143]

I would love for this to all fit on one screen!   But as I developed it, it kind of kept getting bigger....  It started as one loop looking at a voltage reading and opening and closing two relays based upon the target and the parameters I set forth.  That grew to three loops... I then needed a timer that would pulse the out put to the relays.. and then I needed to write to a file.  I'm still in the "development" phase of this project so I don't want to start throwing everything into subVI's  when I might need to hack back into it at a later date and change it.

There is one DAQ Assistant that I used for my CompactDAQ modules... the other VI's are for Measurement Computing hardware.

Nope, not sure what a "chase condition" is...  ??  I'll have to go look that up.

Quite honestly, I'm not sure how anyone else would even start to try and trouble shoot this since you don't have my hardware to hook it up to and it needs the hardware to run. 

C

[chuggins143]

Ok, guys, thanks for the tips!  I'll do some research and get back with you guys.

Thanks!

C

[Ben]

---

@chuggins143 wrote:

I would love for this to all fit on one screen!   But as I developed it, it kind of kept getting bigger....  It started as one loop looking at a voltage reading and opening and closing two relays based upon the target and the parameters I set forth.  That grew to three loops... I then needed a timer that would pulse the out put to the relays.. and then I needed to write to a file.  I'm still in the "development" phase of this project so I don't want to start throwing everything into subVI's  when I might need to hack back into it at a later date and change it.

There is one DAQ Assistant that I used for my CompactDAQ modules... the other VI's are for Measurement Computing hardware.

Nope, not sure what a "chase condition" is...  ??  I'll have to go look that up.

Quite honestly, I'm not sure how anyone else would even start to try and trouble shoot this since you don't have my hardware to hook it up to and it needs the hardware to run. 

C

---

Did it bog down BEFORE you added the file write functions?

Ben

[JÞB]

A couple of things stand out. (besides modularity and other style issues.

1. the file that you read has a macro?  are you sure LabVIEW is the gate? that macro may be doing just about anything and bogging down the entire CPU.
2. All those express vi's.  They have a lot ove overhead code compared to other types of vi's.  Some even have been accused of having memory leaks.

[chuggins143]

Yes it did... I'm suspecting it's probaby the vi that's taking data on my MMC DAQ card...  I dug around and found the VI... it's attached.

Did it bog down BEFORE you added the file write functions?

Ben

---