Comments on Code

[pierroil]

You know what... I actually didn't knwo I could stretch that bundle by name function...

I'm fixing that right now.

Thanks.

[pierroil]

Last question by the way.

What is the different between the two pictures below:

For the longest time I've been using the second one and it's been working. The comments above introduced me to reentrant VI's (I assumed using Templates was the only way to do it...).

Which has better runtime?

The VI that is being called is the one that I asked for comments on. I'll eventually need to programatically and/or manually control this VI - which is why I chose to build my application this way.

Also: Is abort usefull? I used it to get rid of all the memory.

[nathand]

I said "Re-entrant VI" not "dynamically-called VI."  It's a little hard to see your images given the way they're scaled, but the right way to do it is the way it is in the first image, except that you should be calling a re-entrant subVI instead of a template VI.  That will be the more efficient than either of the ways you propose.

Abort VI is not useful, definitely not the way you used it in the first image.  All you're doing there is aborting the calling VI 4 times (which will have the effect of taking out all the subVIs).  The right way to do this is to use a notifier, queue, or other message-passing approach to signal the subVIs to exit.

What is this VI supposed to do?  How are you using it?  Again, it looks way too complicated.  Something happens in the bottom loop that generates a user event that triggers the top loop to enqueue an item that is the dequeued in the second-to-top loop.  Isn't that excessive message-passing within the same VI?  Is there some reason you need so much complexity?

[apok]

i agree....abort vi is a nasty thing,imho. abort a vi without handling a proper shutdown process,while it is operating (for example: heavy machinery) could be costly and deadly. use a notifier to the various loops you need to stop...

[pierroil]

So if you notice, I did handle a proper shutdown inmy VI - closing all references etc etc. I just did the abort in case. That is fine, I will remove it and ensure that shutdown actually happens with the appropriate debug tools.

Also, I changed it from a VIT to a reentrant VI, no idea it was possibel before this thread. Last time I asked, soeone pointed me to that template solution. This makes the code more elegant and makes more sens.

So what do these VI's do?

tldr; I am trying to automate a 4 axis system by analysing incoming data from a digitizer card. The top level VI is the 4 motor controller ones (4 axis in total) which I will eventually call on to take the desired inputs (speed, go to position, stop...) and move my motors accordingly. The motors are referenced via an "address" so that is also included in the cluster.  

More details: 

Well the top level one (posted later in this thread) is currently a UI - it will feature all of those motor  controllers running in parelle along with other pieces of code.

The one I posted originally is the actual motor controller VI. Its input are a reference to a cluster of controls, an encoder counter and an abort signal. I used an event loop to monitor changes to that but eventually realized you can't monitor the change of an individual control within a cluster - so I had to lump it into 1 signalling event and monitor the != value from there (see second loop from the top).Looking back - I guess I could do everything I want in 3 loops. I don't really need the event loop for the cluster - the same behaviour can be accomplished by putting that whoel chunk of code in the other loop and just checking if Old Cluster = New Cluster on every iteration

There is one more event loop( the one above) which handles encoder events. These events are created when the encoder (a seperate entity from the motor) detects that the motor has arrived to the desired location or has reached software limits (I don't have limit switched so I hardcoded them into software to "try" and ensure my motor doesn't go out. I seperated this loop from the signalling one since I don't want the hard stop signals to ever be queued behind the non hard stop signals. I understand that event structures will queue events - potentially queing the hardstop before other events. This event flushes the queue getting rid of all other commands and simply adds a stop command.

The SUB vi's within this main VI will generate the appropriate code that my motor contrller is fed. It will convert my inputs into an acceptable motor input - which is fed into the "write function" (the small consumer loop). That one will write to my motor.

The bottom loop includes other pieces of code such as a module that will run once to configure the motor controller.

Anyway, I will clean up the easy stuff for now and really appreciate all the learning in this thread, but anything that involves changing the entire architecture will have to wait. For now this should work - still haven't tested the encoder (user events) but have tested the second loop and it works.

If you really want to see the rest of the VI's, I can lump them up in 1 zip but trust me, none of them any anything complicated - they are linear pieces of code accomplishing one task no state machines or anything.

 Thanks a lot

[pierroil]

"re-entrant subVI" and not dynamically?

So the first picture is re-entrant right? I found the button in the setting and checked that off - it is no longer a template VI. This is correct right?

[pierroil]

"excessive message passing". I guess this will create race conditions?

I'll can reduce it to 3 loops, or I could use a queue to trigger the top two loops adding a layer of safety.

[nathand]

Going to respond to several of your posts in one reply:

If it's still a VIT, it's still a template, just a re-entrant one.  In addition to making it reentrant in the VI properties, you should save it as a normal VI, not a VIT.

There's not necessarily any inherent risk in a lot of message passing, but I find it makes code execution very difficult to follow and debug.

You can, in fact, set a value change event on an individual element in a cluster - what makes you think you can't?

Why are you setting an event on a front-panel control that's hidden?  I think you have some confusion about how references work.  There's no connection between the cluster reference you pass in, and the hidden instance of the cluster on the front panel of your VI.

[pierroil]

It was a work around.

How can I put an event on a reference Cluster's individual components?

That was the major problem. I tried to transform it into an indicator and then I couldn't pass value change on an indicator. So I had to create a new hidden Control and change that value.

If you can explain me to a way to monitor value change on a reference to a cluster I'm all ears. I just haven't been able to figure it out.

[pierroil]

The problem is really the cluster reference. I need to use reference in order to alter the value from the outside. Which no longer makes it a "control" per say - which means it doesn't show up in the event to pick from. 

Writting to a new hidden cluster was a work around - seems to work.