Comments on Code

[pierroil]

Ok globals don`t trigger events apparently...

[nathand · Accepted solution]

---

@pierroil wrote:

I guess what I`m trying to say is: Can you find me an architechture - and i will actually change my entireee code if it`s possible, that will allow me to send values from a higher up VI?

---

Yes - QUEUES!  As I've been trying to tell you.  I admit that "queues" is an oversimplification more than an architecture, but they're the backbone of most message-passing architectures in LabVIEW.  They have a lot of advantages over references to front-panel controls.  The idea is that you pass a command to a component that causes the component to take some action (and possibly return a result, which can also happen over a queue, or a notifier, or maybe a user event as appropriate).  So, you should have a command that tells a particular motor to go to a location.  The individual motor control VI should not care what the user interface looks like - it doesn't need a reference to the final front-panel control.  It just accepts a command.  One level up from that, you might have a VI that accepts the "go to position 50" command and translates that into individual commands to each axis (one possible arrangement).

If I were designing your Main Motors VI, I might do something like this (VIs attached as well):

It would be easy to add another loop to this code that can read from a queue, and send commands to each axis, allowing this VI to become a component of your larger system.

[pierroil]

funny, I remade my VI and it looks very close to yours.

🙂

[pierroil]

This is actually very interesting. I haven't done enough LabView programming to think of this architecture from the top down. But I have been looking for a way to try and make my Sub VIs independant from my higher up VI's.

I guess Queues do answer my question - sorry I'm quite new to them.

I still don't see how you could go one level up from this.

So you would have a queue coming from above and that queue itself would write to the front panel controls which are referenced in the event loop you have?

[pierroil]

Never mind - I understand. The same way you passed down the data to that SUB VI woudl be same way I pass down data to this VI. This is awesome indeed.

Thanks for your help - this community is actually really sweet and graphical programming gets better the more menus I open!

[pierroil]

I'm goign to ask one last question - very short and simple.

I have another piece of hardware that needs to flush the motor queues in specefic cases. Is it OK to create a seperate event loop for this. This State machine is not related to the other state machine - other than flushing the contents.

I do not want to queue it behind all the other event sequences as it is an immediate hard stop to my commands - it also takes my commands about 200ms to write (except this E Stop one which takes 40ms) so I don<t to lag behind it.

[nathand]

Why create a separate event loop?  Wherever it is that you'd trigger the event, just flush the queue and then put the appropriate command in it.  No advantage to routing it through an event structure. 

You seem very excited about using events for everything - are you coming from some other programming environment that relies heavily on them?  This is why I was really confused about your original structure where you were reading from the control by reference and then constantly sending events - what was the reason for using the event structure at all at that point?  And same thing with the Encoder events.

[pierroil]

I guess that works - well it's the fact that my encoder should trigger different events - there are more than one, but I guess I don't need an event loop.

[pierroil]

Still confused about this after all this time...

1. So yeah, I got my motor working, but now I need to monitor an encoder - how can I send data from the Encoder loops to my main code. Is the best way to actually just keep queuing my new encoder values each and every time and then sending that queue reference to another VI to compare position? This would be very consuming...

So it would look like this:

Main Logic Vi would have a parralel loop that keeps Dequeuing the positon from the Encoder. That loop itself has 2 states - one being the Idle state and one comparing Current Position and the desired location. Outside the state structure - it is constantly dequeuing data from the Encoder. 

If the code finds itself in the compare state (triggered by pushing a setting/button on the main UI) then it compares the dequeued location value to the desired value. When the desired match occurs, you go to a third state - which does some Command Execution - then you hurry back to the wait state...

So I'd have 2 Queue's here... sound about right? Is there no better way to get data from the Encoder to another part of my code without a Queue?

 This seems really dumb lol

[crossrulz]

---

@pierroil wrote:

Still confused about this after all this time...

1. So yeah, I got my motor working, but now I need to monitor an encoder - how can I send data from the Encoder loops to my main code. Is the best way to actually just keep queuing my new encoder values each and every time and then sending that queue reference to another VI to compare position? This would be very consuming...

So it would look like this:

Main Logic Vi would have a parralel loop that keeps Dequeuing the positon from the Encoder. That loop itself has 2 states - one being the Idle state and one comparing Current Position and the desired location. Outside the state structure - it is constantly dequeuing data from the Encoder. 

If the code finds itself in the compare state (triggered by pushing a setting/button on the main UI) then it compares the dequeued location value to the desired value. When the desired match occurs, you go to a third state - which does some Command Execution - then you hurry back to the wait state...

So I'd have 2 Queue's here... sound about right? Is there no better way to get data from the Encoder to another part of my code without a Queue? I'll admit, Queue's are pretty elegant, but still not quite sure about their timing.

---

Do you care about every encoder value or only the latest?  If you only care about the latest, use a notifier.

It might be better to do the comparisons inside of the Encoder code.  Use a queue to send down updated limits and do the comparison when you read the encoder position.