LabVIEW
Mini-Nugget Save time wiring shift registers
Hmmm. It took me longer to read all of your replies than it took to write the Nugget.
Thanks for reading and replying!
Lynn wrote
...turn off Auto Grow for the structure before squishing.
...Duplicating and modifying that case may be a time saver also.
Yep. I generally turn off "Auto-grow" (auto-explode) on all of my work machines, not to enable this technique but to prevent my long-winded documentaion from tripling the size of my diagram. "Duplicating" is definately preferable to adding and and wiring, GOOD POINT!
smercurio wrote
Wouldn't the Tunnel Wiring Wizard do this for you?
Yes I beleive you are corect. I never use that tool in my work projects since it is based on scripting which is not supported. I have enough challenges in delivering quality code without introducing an unkown aspect that would laways make me wonder "Is that bug due to using the tunnel wiring wizard?" Yes. I am a wimp. 
tst wrote
I much prefer collecting all the SR values into a cluster and then bundling and unbundling by name. That way you have a single SR and the code is cleaner.
Good point tst. But because these Nuggets are all about "splitting wires", I have to point out that I feel uncomfortable putting ALL in a single cluster. If the assorted values are realted logically, yes. But grouping unrelated values seems to break rules about "data Normalization". Without quoting from Codd (sp?) I think of it this way. If I am passing the whole cluster to a sub-VI for it to do its job, then they are probably related. On the other hand, if some are used in one sub and the others used in a differnt sub, then I will probably implement them as seperate clusters.
The other exception applies to large data sets and performance issues. Large data sets will get their own shift-registers.
JLV posted
But it does happen that a client wants additional features ...
I wish I could blame the above on the customer but I can't. I ws reviewing my code and realized that I had not accounted for a queue going dead (eg The creater of the queue going idle and LV detroys the queue.
JB wrote;
This may not be considered as a good solution by all of you but if the cluster becomes too big, I put it in a VI to save space on the diagram.
That is another good point. If a state machine has a lot of states and a value is only used in two of them, an Action Engine is a nice approach that really cleans up the state mahcine code. Of course this is not an easy method to use if the state machine has to be re-entrant since the AE would either be shared by all of the instances or else I would have to bend-over backwards to use VI-Server and invoke nodes to keep the state info distinct.
Again thatnks to all of you for reading and replying!
Ben
Ben a écrit:JB wrote;
This may not be considered as a good solution by all of you but if the cluster becomes too big, I put it in a VI to save space on the diagram.
That is another good point. If a state machine has a lot of states and a value is only used in two of them, an Action Engine is a nice approach that really cleans up the state mahcine code. Of course this is not an easy method to use if the state machine has to be re-entrant since the AE would either be shared by all of the instances or else I would have to bend-over backwards to use VI-Server and invoke nodes to keep the state info distinct.
Hi Ben,
This is not what I meant. It is often difficult to express things in detail because of my rather poor English ! I give my best but it would be much easier - and faster ! - to write in French or German.
This VI - which contains nothing more then a control of the strict typed def cluster and a constant of the same type - is used only once outside the loop to specify the data type to the SR. Instead of a constant which may be very large, there is then only a VI icon on the diagram. The values are not important because they are all set in an initialization state of the state machine. Therefore this works also with re-entrant or template VIs.
Below pictures may clarify what I try to explain.
Use of the VI :
Diagram of the VI :
Message Edité par JB le 04-17-2008 04:09 PM
