interrupting a prodcer consumer structure to test servo position regularly

[pathare535]

hey guys, I'm relatively new to labview, and am currently trying to make a multi stage snake like robot. I'm interfacing with USB controllers from pololu and want to manualy control the first stage and have the remaining stages follow, I've got the first stage working with commands from the front panel. I use a producer consumer template and have button pushes activate an event and then queue a case in a second "hardware loop". 

my current problem is now I want to start working on controlling the secondary stages passively, so I want to move the front stage angled up and then start to drive foward and the second stage begins to follow into the same position. I want to regularly interrupt and check the positions on the servos to compare and act accordingly. my first thought is to interrupt on timeout in the event structure and test if the servos are at the same postion. the problem is my visa reference is in the other loop. 

what would be the best way to go about this? should I just queue into my hardware loop on a time out and test the servo positions. or is there a way to share my visa resource in the producer loop? I originally wanted to store the reference in the producer loop and pass it everytime I went to the consumer loop but I couldnt figure out a good way to return the updated reference and I kept  getting errors.

are timed loops an option here? any advice would be helpful. even if you have a better structure to redo the whole project. I'd love to hear it for next time if nothing else. also if theres a better sub forum ill gladly move the post. 

thanks guys

[Kevin_Price]

I wouldn't use the "Timeout" case of an event structure for things that need to occur at a fairly regular rate.  Every event that the structure handles will reset the timeout timer, so the time between timeouts will be quite variable.

It's unclear who "owns" the VISA ref in your code so far, but I tend to build these things up where I have separate loops for each of the devices I'm coordinating.   I tend toward something like the Queued Message Handler architecture, so each of my device loops can receive messages and deliver back responses.  

In this kind of approach, one loop would "own" the VISA ref to a USB controller.   When the main app needs info, it would send a message to request it.  The USB controller loop would receive it, recognize it, act on it, and possibly send back one or more response messages.    It feels kinda indirect when you first start doing things this way, but there are a number of benefits as you need to support more kinds of functionality.

-Kevin P

[pathare535]

thanks for the response

I threw a screen shot of the block diagram this time. I think im using a queued message handler, I basically just used a template that a coworker gave me. I understand how to pass data from the event structure to the working loop but would I put a case structure in the UI creation loop to pass data back to that?

also if im not using the timeout on the event structure how do I generate an interrupt to test the servo position?

Thanks

[aputman]

Your VISA reference does not change and does not need to be updated or passed thru the shift registers.  It is only a name of the port being used (COM1, etc). 

Edit: FYI, you can wire a string into this VISA resource but you will get coercion dots.  There are no settings or refnums stored in this field.

[Kevin_Price · Accepted solution]

1.  I'd aim to pass info/data back to the UI Reactor loop.  Let the UI Creator loop just catch GUI events and dispatch work to the Reactor loop.  You can build in more brains to the Reactor loop and let it also receive info/work from the Hardware loop(s).

2. One simple concept for a regular request for servo position would be an additional loop.  It's only job is have a wait timer and then queue up a request to the Hardware loop to ask it to send the servo position.  It will send it to the Reactor loop, as always, and the Reactor loop will have been built to react appropriately when it gets servo position info. 

3. I would not talk to the servos from any other place than the Hardware loop.  It's all kinds of messy if you can send serial commands from different loops at the same time, then receive the wrong reply or none at all.

Sorry, don't have any more time to get into finer details, but hope this helps a bit as you think about building up the app.

-Kevin P

4. P.S.  I meant to also mention: it looks like both your Reactor and Hardware loop are consumers of the same Queue.  Even though I see how you're previewing first and then only dequeuing if relevant, it's still not a recommended approach.  Consider: if one loop gets stuck while one of its msgs is in front of the queue, it will make the other loop get stuck too.

[pathare535]

I like the idea of another loop that has no case structure and just a timer to send messages to a data processing loop.

To the point about the multiple consumers I've definitely expienced that problem and usually just terminate and start over.
Your suggestion is to have the case structure generate two queues one for ui/ data processing and another for hardware events. Then have a new loop produce a queue for the ui/ data processing and a final queue for the data processing to hardware. Is that correct?

I'm am definitely having robustness problems in the few programs I've created and would really like to develop good practices early on so I appreciate the more general suggestions in coding practices.

Thanks so much for your help.

[pathare535]

Oh to aputman. Can I then just create a local variable that references the visa reference and feed that into any VI that needs it?

[aputman]

You can do that....not saying that you should.  I only told you that tidbit to help clean up your diagram and maybe eliminate some of your heartache with wiring.  I agree with Kevin that you should keep your hardware calls to one loop and have your event structure send messages to the hardware loop.  

[aputman]

Here is a simple example with some commands that I just made up for the sake of an example.  Drag the snippet to your desktop and then drag to a block diagram to paste in the code.  It is by no means a complete example.  

[pathare535]

thank you guys for your responses so far, I see what you're both saying and I think this is the direction I want to go at this time. do either of you have resources I could try and read about things like design patterns? My background is EE and ive been basically thrown into more programming than Ive ever done and am trying to create the best programs I can.

I was trying to impliment the interrupt loop and queue that into the hardware loop also, is there a way to "or" strings for the case structure? or is it an acceptable practice to have multiple case structures for each of the queues?

is there a better way to pull data from queues other than the case structure strings?

thanks again guys for all your help.