07-08-2015 10:08 PM
This was originally configured with lots of dynamic data and daq assistants. I changed all the input to arrays with tasks and the program execution didn't speed up much.
This is running on a cDAQ 9139 with 3 9188's connected via ethernet. Wondering if there's something I can do with channel scans to take out some of the lag. The loop time is around 4 seconds on the hardware. RAM use isn't bad at 116k.
07-08-2015 10:51 PM
First some ettequete comments:
Do NOT upload vis set to "Run When Opened" Without warning the forums! The next guy that look into your problem may have his "Real Work" open too and your code can cost others time and frustration when it starts running! FAIR warning is required!
NEXT: if you want us to evaluate why your code runns so darned slow UNLOCK the password protected Block Diagrams
Style comment: Why on earth are you not using PROJECTS? How do you look at dependancies? or even work on anything other than a 10VI app without a project?
I know that sounds harsh but, we can't help you if your code crashes or IDEs and the BDs are locked and we have to GUESS what vi/ vis are top level and which sub-vis are bogging down the process.
My Guess though is: If you properly add the vis to a lvproj, unlock the BDs and run VI Analizer on the project most of your problems will be identified.
07-09-2015 05:59 AM
I think a couple of the subvi may be still locked, but I put everything back in a project file and unlocked the front panel. Note the time it was uploaded, that was pretty late and it was a long day. My apologies.
07-09-2015 08:11 AM
All the password restrictions are gone now.
Sorry for the lameness.
07-09-2015 08:27 AM
The first thing that I would do it simplify your code. You have eight loops running what seems to be the same exact code. Why not make it into a VI so it is easier to maintain. Next I would start disabling sections of the code and see where you are loosing the time. There is a lot going on in your code so most of my effort at the beginning would be to make your code readable and try to get it on one screen. If you make your code as a single vi that you can exicute eight times that will help a lot.
07-09-2015 09:27 AM
All the password restrictions are gone now.
Sorry for the lameness.
Thanks for understanding and helping us help you!
07-09-2015 10:56 AM
I never thought of that since each of those loops needs to execute independently. If I make it into a SubVI, what sort of reentrancy will I require to ensure that it is functioning as smoothly as possible?
I really appreciate the help here, gentlemen. This loop, with acquisition method taken into account, runs about 3-4 seconds in real life. Each of those big loops is also writing data to a text file every minute, and once those get close to 8mb the file get large enough that it can't be opened, written to, closed in less than one minute and the whole mess crashes.
I'd like to have it automatically generate new files when they reach roughly 4mb. That will be the next obstacle to tackle. I've been at this close to 8 years now I think and still don't know much more than a newb since I wasn't given any dev time on anything, just "make it work".
Can someone glance at the daqmx tasks and tell me whether or not that's been done in the most efficient way possible? I have a feeling I'm losing a lot in the acquisition side of things, and that code is all converted DAQ assistants. Yes I'm that lame.
07-09-2015 04:23 PM
Wow. At least the wires are more-or-less straight and parallel.
This is in serious need of a complete rewrite. I just checked the VI Description of Main Front Panel to Get a Clue, and would you believe it -- there was no Description. I see lots and lots of duplication (which suggests the need for arrays and FOR loops), lots of "busy details" (which means "Sub-VI goes Here". I can't really tell how big the VI is, but it certainly doesn't pass my BS Standard that it fit on a single monitor's screen -- I estimate you'd need a 24-monitor setup to see this thing.
From the relatively clean design of the Front Panel, I suspect that it would be possible to do a complete rewrite, and get something that is viewable, understandable, and maintainable, but it will take a little effort, and possibly some Expert Assistance (i.e. a LabVIEW Guru working along side you for a week or two).
I've recently done such a port by myself (it's hard being your own Guru -- thank goodness for smart BME students), and found that the old adage, "Write the Documentation First", really works. Among other things, generating a 10-page detailed documentation of what you are really trying to do forces you to prioritize and (I don't really think this is a word, but it should be) hierachitize your Project. Understanding what is really supposed to be happening is the First Step in getting it to work.
07-10-2015 11:03 AM
Thanks for the input. The program works - it does as intended, just rather slowly.
The reason there's no description or documentation is that, rather frustratingly, the project scope was not defined prior to the start. It would have read, 'monitor temperatures and turn things off if the limits are exceeded'. One loop, one daq assistant, one switch and you'd be done, right?
This has morphed over years of added requirements, changing scope, and general confusion from what it started as (See above) to what it is now. There are elements in here that are only here because I couldn't figure out how to do something, asked, and was given some code to try. Imagine if the first car manufacturer had been given a PO for a wheelbarrow but what was intended was a MacLaren F1. Zero has been proactive and all has been reactive, and still is.
The front panel I'll take credit for, since that's the only thing that's purely mine. I can try to work up a description of what it's currently doing if that will help my case at all.
07-10-2015 04:42 PM
Paradoxically, making a lot of sub-VIs ("encapsulate most functionality") will probably greatly speed up your code. The reason I say this is that to grasp what is going on in its present form requires 24 monitors (or one of these wall-sized $10,000 monsters) to get a grasp of the whole thing. If you start putting "pieces into little boxes", you will probably begin to see "Oh, I did that already over here" or "Oh, I could do those simultaneously rather than sequentially" (this is especially valuable if one thing is much slower than the other). At some point, there may even be an "Aha!" moment when you realize a Much Better, Faster Algorithm (perhaps because you are only Doing It Once instead of 100 times).
At least, this has been my experience in a few messes I've tackled ...
Strive to get the Top Level Block Diagram to a single screen (it can be done, but even 2 screens would be a big improvement).