02-16-2018 10:27 AM
It seems to work quite well...
02-16-2018 10:56 AM
Can you post a screen shot of the code? I'm wondering if you might have accidentally expanded an existing shift register (so you will get previous iterations), instead of creating a new one.
02-16-2018 11:24 AM
Waleed,
Overuse of controls and indicators as a mechanism to make variables is an extremely common misstep folks make when learning LabVIEW after having some text language coding background. There's a very literal way to translate text code into lots of "read from local variable, perform operation, write result back to local variable" constructs. This tends to be a very bad practice in LabVIEW where parallel operation is the norm and sequencing takes extra effort. LabVIEW is based on dataflow. The native habitat for data is on a wire, not in a control or indicator.
You keep referencing variables and it isn't clear whether you're starting down this unfortunate path. If so, I'd urge you back up and do it a different way.
I agree with other advice you're getting. Define a cluster and make it a typedef. This is directly analogous to a struct in C. All your many "variables" can then become individual named fields within this one cluster.
-Kevin P
02-16-2018 12:03 PM
Dave, just... no. You're corrupting the impressionable.
02-16-2018 12:23 PM
Thanks to everyone who spent time on assisting me in that.
The problem is the code is updated on daily basis and thus, having a neat Block diagram while porting from C code and making sure everything is working well is a luxury I may not have. I believe all those on the edge of due dates are familiar with it. I literally hold all data types in that project and thus having all variables as an array in not an option. The proposed cluster is something I may try to resort to once I have a relief to do so (and I already did it once on when needed to log multiple data.
Also not using local variables as a bad trend also agreed, but sometimes it is much better especially if this variable is needed to be displayed any way. it also takes less processing than value property.
Last but not least, I'm much grateful that channel wires are there instead of enqueuer/dequeuer pattern as it made it quite possible to sync loops in much simpler way.
Once again, thanks to everyone dedicating and effort to assist me in solving that. Apparently it was a logic I missed in the code itself irrelevant to shift registers.