LabVIEW
LabView Rant - lack of Express node support
wiebe@CARYA wrote:
@Rich_Tennant_Tech wrote:
>>>>>>>>>>>>>>>
That's fine, having a node that can run everything at one speed would just be another option in our tool box - something that you would only use if needed and not used if you wanted to run at different speeds. Not wanting to change the game, just expand its capability.
Another option to that would be to let a higher speed card run at that higher speed but then have a node that would average that back down to a common speed. So then I would be getting a the lower scan rate that I'm looking for (average of 1 second) but then not have to worry about a buffer over run.
Or just make it possible to specify that any card can run at any speed requested as long as it doesn't exceed its max speed design limit or cause a buffer over run - or any other unseen error caused by running too slow.
Case in point would be a test I'm running right now on 12 water pumps set to run for 3000 hours (estimated full life) - we're looking at case temperature (9211 card) and current (measured with a shunt into a 9239 card). The 9211 maxes out at 15 Hz, the 9239 wants to run at 4 times that and to prevent a buffer over run you need to average the 9239 readings. Which seems kind of silly, why not just make it possible to run them all at a lower speed and be done with it?
Our solution was to pay a company to write a program that will save data at a 1 second interval across all channels. Sad but true.
I'm not that into DAQmx, so really can't comment on that.
But in general, suggesting a global to fix things in not a good idea. In this case, it seems you want a global speed? Or just a global default speed?
If you really thing it will help people, you can suggest it in the idea exchange. Probably the Data-Acquisition-Idea-Exchange.
Globals have their place, and they are pretty powerful. Because they are so powerful, they aren't easy to tame. I use them all the time for someplace to store values I pull from a config file. Also, at the beginning of my application, I gather all my front panel control refs into a cluster and store that in a global so I can distribute them as needed. Notice that these are all examples of write-once-read-many.
@billko wrote:
wiebe@CARYA wrote:
@Rich_Tennant_Tech wrote:
I don't have a quote button, only a reply button - strange.
You get that button in your reply window, or rather above your reply entry:
On narrow screens (mobile) you might have to press ... first.
Do you know how long it took me to find that quote button? When they switched from having the quote button on the bottom to putting it on the tool bar, it messed me up for at least a few weeks... so finally I stopped to ask for directions. 😉
HAH!, found the quote button, thank you for posting that! Maybe I don't use enough social media but I never would have found it in the tool bar. Talk about hiding it in plain sight.
@Rich_Tennant_Tech wrote:
I can understand that, but coming from other data acquisition system I do not like it when the program will do something that I did not request. In this case taking data samples when I did not request them. Even worse is when those unrequested data samples crash my program (i.e. a buffer error) that can quickly become annoying. So a quick fix would be to either make a Global scan rate or a node that can handle what ever the card wants to run at but then average it down to a rate that I actually want to save at.
So if a card wants to run at 100Hz then fine, but then offer a node that let's the user display and save that at what ever they want or their system can handle. Basically to seamlessly turn that 100Hz into 5Hz for displaying and saving.
If that's what you want then FlexLogger (and maybe DAQExpress, I haven't used it) is the program for you. LabVIEW is not a data acquisition system; it's a full-on programming language. What you're asking for is quite trivial to implement using full DAQmx functionality- just not ExpressVI's. As others have mentioned, ExpressVI's have little to no real use in "real world" application development. They're OK for quickly prototyping systems, but beyond that they impose lots of limitations... like the ones you're currently running into, actually.
Any programmer who is capable of coding a full program that can acquire, analyze, log data, control parameters, etc will not be using ExpressVI's to do it.
NI does sell a data acquisition system- it's called FlexLogger. It's for people who want a straightforward, easy-to-use system that can be acquiring and logging data in a few seconds. You can select which input channels you want, what scan rates you want, display rates, logging parameters, perform simple calculations, all that good stuff. (Again, DAQExpress can do a lot of similar things but I haven't used it myself, so I can't really comment on its usability.)
Again, I'm not a DAQ expert, but you should be able to configure tasks in MAX, program their sample rates, etc.. Then use the tasks in LabVIEW. This saves LabVIEW programming. You are still "programming" (more configuring) the tasks, but in MAX.
This has ups and downs. I usually like my programs to be "self contained". But it can be great to let users do adjustments in MAX, without having to expose settings in your LabVIEW program.
Search LabVIEW like a graph! Just to make things more complicated...
Note that any two or more devices don't have the same clock. Cheap IO devices use software timing, so their samples will line up with the PC clock. Real expensive IO devices can have external clock options, so you can make them all use the same timer. But intermediate devices, they all have their own clock. This will become apparent if you same for hours or days. No two devices will have sampled exactly the number of samples you'd expect.
AFAIK, This is not an easy problem to solve...
