LabVIEW
Arrays: working with elements inside array "index array + stacked sequence" vs "For Loop + Case Structure"
I'm working with data coming from a PLC. All the data from PLC comes inside a single array with 2000+ elements.
The PLC is sending data in about 100 ms (DAQ = 100 ms) to LabVIEW, but I'm trying to decrease this DAQ time to <10 ms
The LabVIEW has to get the data and split it into three types of array:
- Array of BOOL
- Array of SGL
- 2D Array of SGL
Some indicators and XY Graphs in the Front Panel needs to interact with several elements inside these arrays. And some Graphs needs to be displayed during several days, so memory will be a issue sometime.
I'm using "Index Array + Stacked Sequence*" to sort and display the data in the Front Panel indicators.
(*Obs: I know that Stacked Sequence is to be avoided, but if I use only wires, my block diagram will have kilometers of wires and will be impossible to change something in the future)
1. Is there a more efficient way to sort and display my data?
2. Does a "For Loop + Case Structure" with several index Array will use more memory (or be more efficient "programmatically" speaking) than this single "Index Array + Stacked Sequence" ?
Right-click on the stacked sequence structure and replace it with either a sequence structure to better understand what you are trying to do, or (better) replace it with a case structure to begin transforming this into a state machine. At any rate, after doing this, never go back to the stacked sequence structure again.
I am really not a fan of converting things to Boolean Arrays. Those just tend to eat up memory and processor power with little gain. Instead, keep the I32 and you can use a mask (AND with a value) to only have the bits you care about and then Logical Shift the values down to bit 0. You can then do all kinds of analysis on that value.
Back to your original question, there is not really any difference between a Sequence Structure and a sequence loop (FOR Loop with a Case Structure). I think I would be more likely to turn the conversion code for each U32 into a subVI, outputting a cluster with all of the values. The top level can then use Unbundle By Name to get only the values it actually cares about for display.
Hello billko, thanks for your answer. But I still have some doubts in how to replace the Stacked Sequence
About the State Machine: I think it will be not necessary, because the LabVIEW needs to update all front panel indicators each cycle of the DAQ. At the moment I have nearly 30 indicators "spread" in the Front Panel (sensors status + sensor measurement). And I'm already using one State Machine to thread the OPC-UA logic (states: Init, Config, Idle, DAQ, Error). This OPC-UA logic is similar to the example that NI provides with the OPC-UA package. And the sensors are updated only during the "DAQ" state, but in this case all of these sensors needs to be updated
About the Stacked Sequence: I'm really trying to avoid the use of the Stacked Sequence. But at the moment I think only these options can be used:
• 1st option. Use only wires: It's impracticable because the VI will have so many wires that will be nearly impossible to modify something.
Let's say that after one month, the user needs to add 5 more Indicators and the PLC gets 2-4 variable in the middle of the array
How can I modify the snippet bellow to add these variables? In my opinion it will be easier to delete this portion of the VI and start again from zero
On other hand, with Stacked Sequence it will be only "Right click: Add Frame After" and we are good to go.
• 2nd option: Use Case Structure. In this case the Case Structure needs to be preceded with a For Loop, right?
So in the end, it will be swapping:
- "One Stacked Sequence" with 12 frames with only one use of the "Index Array" function... with
- "One For Loop" with n=12 plus a "Case Structure" plus 12 use of the "Index Array"
The performance of this 2nd option is equal, worse or better than the "Stacked Sequence"? I'm asking this because the VI needs to display XY Graph with several days of data, and memory will be a issue
Am I missing something? Is there a better way to manipulate the elements inside the array relating some elements to others and updating several front panel indicators?
Hi mthheitor,
@mthheitor wrote:
How can I efficiently manipulate the "bits" from a U32 DWord inside LabVIEW?
Like this:
To clear a bit you can use an AND function, to switch a bit you use XOR…
I'll go ahead and share this Malleable VI. The Malleable VI was first released in LabVIEW 2017, but it essentially allows the VI to conform to the data types wired up. Even if in an older version, you can get an idea of how to more efficiently parse your data.
Sorry, I am a bit late to the party here, but why exactly is the input an array of SGL? Wouldn't a string be more reasonable if it contains various types of binary data?
Execution speed is just one of the parameters of a program, code readability and maintainability is also important and your score here is very low. I agree with others here that you code should not really contain much green at all.(Also note that built array in concatenate mode is probably more reasonable than you insert into array).
Next time please also include the typedefs and have the control contain typical default data so we can actually run it and test.
