LabVIEW
VI's bogging down?
@chuggins143 wrote:
Nope, not sure what a "chase condition" is... ?? I'll have to go look that up.
Look up the phrase "race condition", you'll have better luck finding information on that. I think aeastet was making up a new phrase that almost sounded the same. 
@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.
Would you also write a VBA program without functions and/or includes? LabVIEW has a nifty little tool where you can just select some code and choose Edit -> Create SubVI. Your big case structures might be a start for that. 🙂
Kudos to you for using Shift registers!
Most of your Select (the triangles) are ANDs.
The LV startup windows has an Example finder (or search in help), the Producer/Consumer is probably what you're after, since i bet not all of this must really be run each iteration, no?
Case structures can be used with integers and doubles also, in which case they work like switch/case or if/then. Many comparisons can be merged into that solution.
Race conditions happens on all multithreaded systems, if you dont control in which order data is read and written to variables it basically becomes random. Local variables give no such control. Just imagine 10 excel applications writing to the same file without file lock, in which order will the data end?
/Y
Great for you to jump in feet first! and a heck of a way to start! We really aren't picking on you too much when we suggest modularizing your code by using sub-vis (think sub-routine). Just grouping related code so that it fits on one screen section is a good place to start but not enough. Make it a sub-vi so it gets its own block diagram and gets away from unrelated code it will be much easier to read and maintain ESPECIALLY when you add VI documantation and comments
"Express vi's are those darn huge blue icons that get configured. Pro's detest them because they perform poorly. There is a lot of code behind them that follows the 90/10 rules. 90% of the code is not used often (think exception cases) and the 10% you need can usually be accomplished with a couple functions on the palatte. For instance Write to spreadsheet file.vi on the file palatte would format your file just fine and use less memory.
Did you ever look at the task manager to verify that LabVIEW is the resouce hog?
Thanks! 
I understand you aren't picking on me... I realize that I need to shrink this down. I'm just to green at this point to see all the short cuts that all you experienced guys/gals notice. Basically, I know just enough to be really dangerious at this point! 
I've written one other controls program using LV... a precursor to this if you will, that occasionally had the same issue, but once I turned it into a standalone executable those issues went away. I've got alot to digest and read so I may take a step back and do some reprogramming.
...and to answer your question, I typically have the task manager running and LV is chewing up a lot of memory.
THX
C
@chuggins143 wrote:
I do have a few questions... is there a way to write a VI that has the shift registers built in? ...say I wanted to VI my counter, do you put a loop in the VI? This was the first thing that I wanted to subVI because it's huge and quite complicated. ...but I didn't know how to take care of the shift registers since they're tied to my main while loop. Any ideas? I'm thinking I can put a loop in the vi with all of the separate inputs/outputs... is my thinking correct?
One of the guys mentioned that I'm using local varialbles... I'm not seeing where I'm using local varaibles as described in the Help files. At least not in the way that I'm understanding it. If you'll point one out so I can better understand I'd appreciate it.
Thanks!
C
Yes, Shift registers is fine to put in your sub-vi's. It's a common way to keep a memory between loops (uninitialized shift register).
/Y
@chuggins143 wrote:
Thanks!
I've written one other controls program using LV... a precursor to this if you will, that occasionally had the same issue, but once I turned it into a standalone executable those issues went away. I've got alot to digest and read so I may take a step back and do some reprogramming.
...and to answer your question, I typically have the task manager running and LV is chewing up a lot of memory.
THX
C
THat points back to my wild guess of an array growing somewhere. (After some poking I suspect a filter is building a hsitory or the DAQExpress VI is not deallocating buffers and it needs broke up inot "init before" Read inside" "Close afterwards" to avoid the buffers being repeatedly reallocated.
Run the VI profiler and figure whick VI is using increaling memory. Once we know that, we can focus on a fix.
So run the rofiler and proceed based on what it tells us.
Ben
