controlling one item from multiple sources

[johnnyt]

Hello all,

I'm working on a project that involves multiple fieldpoint controllers and a PC.  The fieldpoint controllers will each control 4 small test stands, the PC will be used to configure, calibrate, start/stop tests, manual control, display, and any other non-real time tasks.  I haven't started building the apps yet, just sorting the architecture.

I plan on using the state machine found in this article: http://expressionflow.com/2007/10/01/labview-queued-state-machine-architecture/  and shared variables as described in this article:  http://zone.ni.com/devzone/cda/tut/p/id/4679

This morning, I came across Labview's HMI touchpad device while reading Labview's latest newsletter.  I found this article on the website:

http://zone.ni.com/devzone/cda/tut/p/id/2698

It would be really, really, nice to display data, do manual control, and start/stop tests directly from the touchpad.  The simple example they give shows one "publisher" loop and one "subscriber" loop.  That's nice, but it won't work if you have two publishers, since two loops writing to the same shared variable will overwrite each other.

In fact I could have four "publishers": the PC, the HMI touchpad,  maybe a website, and the test sequencer running on the cFP.  For example, it's typical for the type of tests we do around here to throw a controller into manual during the test.  If we have a slider bar on the PC, touchpad, and website all connected directly to the analog output, how do we synchronize this with the cFP that's running the test?

My thought on this is that we would have a boolean "manual" button on each of the three requesters,  when the cFP test sequence sees the "manual" request, it will then allow the requester access to the analog out, suspending it's PID loop and notifying the other publishers that they are locked out while the requester operates the slide switch. When the requester is finished, it releases the "manual" button and the cFP regains PID control.

Another example would be digital outputs,  if I want to turn off, let's say, a heater from the PC, I would have to request control from the cFP and the cFP would have to change the digital state to off and update all the other requesters so that there toggle switches move to the off position.  In other words, I believe all my toggle switches would need to be momentary state requests that need feedback from the cFP as to what state the digital is actually in.

Does this make sense?  Would I be able to accomplish this with the state machine and shared variable architecture?  Anyone have a good example they would like to share?

Thanks very much!

[tst]

If I understand what you want correctly, I would advise against shared variables for the command interface. Instead, you can either use VI server to call VIs running the cFP (example, plus more links there with more details) or you can use some sort of messaging architecture to have a direct point-to-point channel (example).

The biggest issue is usually passing the state data correctly to the clients so that they are up to date. If you have a decision that you will only have one client at a time, that becomes easier, because you can just transfer all the data when the client connects. Depending on your network setup, you can have the cFPs use UDP to publish themselves every second or two, so that when your client connects to the network, it will see a list of cFPs.

[johnnyt]

Hi, tst, thanks for your taking time to give me a reply.  I had spent many hours reviewing different methods to communicate to the cFP and settled on the shared variables.  I did some sample testing and they seemed to work fine, plus they were very EASY, which goes a long way.  Would you mind sharing more info on what kind of pitfalls I may run into with shared variables?  Have you had experience with them?

For more of what I'm trying to do, you can check this post:

http://forums.ni.com/ni/board/message?board.id=170&message.id=298493#M298493

Thanks, John

[tst]

I don't have any experience with shared variables, because they were only released with LabVIEW 8.x, which I don't use. I do have some experience with the technology they are based on, though, and the reason I advised against them was because of my understanding that they are inherently a publish and subscribe system. That's good if you have one publisher and you want to publish state. It's not good if you want to do two-way communication. It's also not good if you want to verify that the client got the latest data. They might be suitable for part or all of your application and if your testing was enough to cover the different possibilities, then you should be able to use them.

[johnnyt]

tst, thanks again for taking time out of your day to reply.  I really appreciate when people give just for the sake of giving.

As far as the shared variables, they are new and I will keep in mind your thoughts as I progress.