LabVIEW
Weird behavior of feedback node in sub-vi
Solved!
@YePererva wrote:
P.S. Please, explain how does use of local variables compromise the data flow?
As I understood, the main part responsible for dataflow in such application is the state machine and connection between states. In NI course(s) there is a strong suggestion "one state - one function". So, in this case I have several states: "Data acquisition" (reading of 7 sensors, but there will be a few more latter ), "Statistics" and "Data filtration/noise suppression", where extra calculations are made. Usage of local variable seems to be the proper way of passing data between those stages. What is wrong with that?
Your blatant overuse of local variables is just the tip of the iceberg. Not only are you ping-ponging massive data across locals (causing extra memory buffer allocations), you even have duplicate instances in parallel for no reason at all. Don't be afraid to branch a wire.
Obviously, you are coming from a text based programming background. LabVIEW does not have "variables" in the common definition, such as in text based programs. The wire is the variable!. Local variables are mostly useful for special UI issues, e.g. for programmatically updating a control that is typically operated by the user.
Your subVI problem would be a non-issue of you would make your code scalable! Make the subVI operate on an array and now reentrancy does not even matter. Just keep the array of pressures in a shift register via linked tunnels. You would not even need to make any dramatic code changes if in the next applications you had 10 pressure channels! (Gerd's rewrite above would operate an an array with basically no code changes).
Here are some comments (Unfortunately, we don't have the full VI, so we cannot see all the weed in the other cases).
and please (please!!!!) don't maximize the front panel and diagram windows of your tiny subVI to the monitor. It is extremely annoying to stare at 95% whitespace while preventing you from seeing other important windows, such as the online help.
Also note that implementing a rolling average has much cleaner solutions. It can be implemented fully in-place. Have a look here, for example.
For some additional ideas, see my NI Week presentation (Part II) where I compare four different running average implementations in terms of memory and speed. Some can easily be expanded to 2D data with a few modifications.
@YePererva wrote:
Link for presentation is broken.
Works fine here. Maybe try again later.
@YePererva wrote:Regarding Rolling average as sub-vi (can open it from a personal PC, but will take a look later): does it support changing size on the fly (if need to adjust during the running of the application)?
It is a simple draft and will re-init whenever the history size changes. If you want anything different, you can implement it with a little bit more code after deciding what should happen if the size increases or decreases.
It would be easier to pad with zeroes an divide the sum with the correct number of "valid" entries.
Hi Christian,
@YePererva wrote:
Link still doesn't work:
The link to the "Advanced User Track" presentation is also invalid for me. Removing parts of the URL from the end always results in an "Page Error" from NI.
I guess your presentation is posted in a board with restricted access…
