Maximum number of shift registers/feedback nodes per a loop

[wbadry2]

Hello,

I'm working on porting code from an embedded system to LabVIEW. I need over 60 variables to be held in memory (via either shift register or feedback node). I use both as I read they gave same performance and since I don't need other than previous variable value (global scope in text based programming).

My problem is, once I added like 40 variables, the latest added value started to affect the update of others (some variables started to hold same value after few iterations). I checked the code several times and it is supposed to work. It is certainly weird behavior. All variables are initialized.

Just needed to point out that I use formula node with those shift registers and feedback node as an intermediate step before porting all code to LabVIEW.

So, is anyone aware of the maximum number of shift registers allowed either generally or connected to formula nodes? Thanks

[crossrulz]

I have not heard of a limit.  I would not doubt that there is one.  But one way to help reduce the number is to group related variables in clusters and use the Unbundle By Name and Bundle By Name to read and write the values.  You probably want to do this anyways to make your code more readable.

[paul.r]

Agree with Crossrulz - put your data in a cluster and store that on the shift register. If you are seeing the wrong values in the shift registers, it is likely that somewhere your wires are getting mixed up - which would be very easy to miss if you have 40+ shift registers! 

[wbadry2]

Thanks to crossrulz and paul.ross for your responses,

I'm certain your proposal would drastically eliminate this giant number of shift registers. However, wouldn't bundle/unbundle affect the overall code execution speed? I'm not an architect and thus not aware of all performance bottlenecks. My boss wants the code to remain in C like to be able to get it updated with less amount of time (he is aware that it makes it 80% slower than native LabVIEW primitive blocks. It was working very well until I had to add few more variables and started to get this freezing values.

[paul.r]

Depending on what you are doing yes it can affect execution speed, however for the vast majority of applications its a non issue. Can you post your code? If you are trying to optimize the execution speed, there are plenty of users here that can help with other items that would likely be much more significant than the unbundle/bundle overhead.

I just threw together a quick, sloppy benchmark test - unbundling a cluster with 1 double, incrementing the double, then rebundling in a loop on a shift register took about 2.7 nanoseconds. Doing the same thing with just a double took about 1.29 nanoseconds.

[crossrulz]

---

@wbadry2 wrote:  However, wouldn't bundle/unbundle affect the overall code execution speed?

---

Not even enough for you to measure (we recently tried in another thread somewhere around here).  Your Function Nodes will hurt your execution speed A LOT more than bundle/unbundle.  You will also gain readability when using Unbundle By Name and Bundle By Name.

[wbadry2]

Unfortunately , I am under NDA and therefore won't be able to post the code due to that restriction. It is a bit massive due to number of variables I currently have and as I mentioned, I'm 100% sure that converting it to native LabVIEW would drastically improve the performance. I'm currently trying to reform the code by adding variables one by one and see if I'm gonna reach a bottleneck. If I got stuck, I will try bundling variables to see if getting any better.

Once I'm done, I will post my feedback in a day or two utmost. Thanks again for your valuable suggestions 

[altenbach]

---

@wbadry2 wrote:

My problem is, once I added like 40 variables, the latest added value started to affect the update of others (some variables started to hold same value after few iterations). I checked the code several times and it is supposed to work. It is certainly weird behavior. All variables are initialized.

---

I would have thought that you'll run out of diagram space much earlier than out of feedback nodes, so that would be a new one for me. Would be interesting to hear a comment from NI.

What is the datatype of the "variables"? If all are the same, you could even use an array. (you could use a typedef'd enum diagram constant containing the variable name to readably index into it).

Are these shift registers on the main diagram or embedded into e.g. an action engine? Are they accessed from different parts of the code? What is the overall code architecture?

Would "global variables" be an alternative?

While you don't need to show us any proprietary code, maybe you could draft a simple example program showing how you access (read/write) these variables and how often this needs to happen.

[CFER_STS]

Are your variables all of the same datatype, or mixed?  If the former, initialize an array of the required number of elements (or place a constant with the initial values), and pass that into a single shift register.  Use index and replace functions within the loop to access and modify individual variables.  If your variables are of mixed datatypes, create a cluster typedef containing defaults for all of your variables, place a constant of that typedef'd cluster before your loop, and then use the unbundle by name and bundle by name functions within the loop to access and modify your variables.

[CFER_STS]

Just to add to that, the maximum number of shift registers / feedback nodes in a loop is reached as soon as someone is unable to look at your code and figure out what it does within a few seconds.