Jump to content

controlling and syncing multiple statemachines


Recommended Posts

Hello, I am new here. I am having a difficulty setting up a application. I have three vi's I am running to do some data acquisition, stage control and processing respectively. One of the vis is running on a 64bit labview platform. The other two are running on a 32bit platform. They all internally are statemachines, but I would like to design I way to activate certain states based on states from other vis.

 

For example here is what I am trying to do, below is a diagram of the internal states and how I would like them to communicate:

 

vi_A: 'Idle'->Do_SomethingA_1    -> Switch_vi_B_to_Do_Something_B_2 ->...

vi_B: 'Idle'->Do_Something_B_1  -> Wait_for: Switch_vi_B_to_Do_Something_B_2 -> Do_Something_B_2 ->...

vi_C: 'Idle'->Do_Something_C_1 -> ...

Link to comment

JKI has a presentation on how to do this using their state machine and user events. It's a convenient and simple way to expand on an already very useful architecture. You'll find the JKI state machine gets used a lot in the LabVIEW community.

 

Check it out here:

http://blog.jki.net/events/niweek-2011-beyond-state-machines-slides-and-code-now-available/

Link to comment

Sorry if I was not clear. All of the vi's for now run on the same machine. The problem is that I need to control the states of all three vi's based on what states they are in respective to each other, one waits for a 'trigger' from another vi inorder to progress. I have two vis in a 32bit version of labview and a vi running in 64bit labview.

 

I just installed JKI I will take a look. I am not sure what differentiates it from a standard state-machine although I know it must be more robust. 

Link to comment

I was just reading this topic and realized the suggestion to use Notifiers across LabVIEW instances (they have to be different instances between 64bits and 32 bits).  I never ran into a situation requiring this personally but does this mean that Notifiers (named) (and possibly Queues (named)) allow communication between LabVIEW instances?

 

I looked at the Help file and under Notifier, it says:

"Note If you obtain a notifier reference in one application instance, you cannot use that notifier reference in another application instance. If you attempt to use a notifier reference in another application instance, LabVIEW returns error 1492."

 

Doesn't this imply that it is not possible?

 

There might be something more fundamental I don't understand in this issue since I thought it was not possible to install and run both 32 and 64 bits on the same PC...

Link to comment

Therefore, my recommendation for drbrittain would be to use the TCP/UDP communication method.  I personally use the AMC (http://zone.ni.com/devzone/cda/epd/p/id/6091) library from NI a lot within a single LabVIEW instance but there are VIs in there to communicate seamlessly accross different machines over UDP I believe.  You will need to tweak the code wherever "AMC_UPD port.vi" is called to use two different ports since you are on the same IP address.

 

Otherwise, I just did a quick test with Shared variables and they successfully communicate accross LabVIEW instances (2009-2011) and should also work between 32 and 64 bits.  You can use a few variables to allow each process to know what the other processes are currently doing.  You can even use those as queues if you configure them as FIFOs. (http://www.ni.com/white-paper/4679/en)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.