LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get information inside a state machine from outside state machine

HI,
I have a UPD RX vi which is a  subprogram which outputs some data couple times a second. This vi is being run outside of my state machine (SM).  Inside my SM, in one of the states ("Measure") I have a need to stop and wait for the UDP RX  vi to receive a specific type of data.  Is there a way to iplement this data transition from outside SM to inside  SM? The UDP RX sends only false or true type of data several tymes a second and I pretty much need to wait untill  UDP RX will receiv a true. I have attached the pic of my code.   Please help.

0 Kudos
Message 1 of 6
(3,064 Views)
Ummmm... do you actually have that VI just sitting there by itself? Why isn't it called after the TX?
0 Kudos
Message 2 of 6
(3,056 Views)

This is one of those situations where the code would be better than an image. 

Some questions:  What is "Source"?   Is it to select from Thor's TX or some other Tx?  And why is it a property node?  (instead of the actual control).

Can you explain this a bit further?       "Is there a way to iplement this data transition from outside SM to inside  SM? The UDP RX sends only false or true type of data several tymes a second and I pretty much need to wait untill  UDP RX will receiv a true."

From what I read, within the Measure state, you have the case statement which selects the source.  "Thor's Tx" in this example.  Where does "UDP RX " come into play?  I see it outside the while loop. 

Where I'm confuse is that you say: "The UDP RX sends only false or true type of data", and then it continues to say "wait untill  UDP RX will receiv a true".

I think it's a typo..  But your case has a comment saying that "Thor's TX" waits until UDP RX responds back. 

So does THor's TX send a boolean (T / F) to the UDP RX and then UDP RX sends an acknowledgement back to Thor's TX which waits for it before the sub-vi ends and returns control to the state machine?  If that's the case, are you trying to send these transactions between the sub-vi(s)?  or does Thor's TX run, and returns a boolean which is what you want to send to UDP RX?  --- looks like I'm even more confused -- 😉

Can you provide more description? 

The short answer is yes... you can send data from within a state machine to outside it, but depending on what you want to do, the approach may vary..

R

0 Kudos
Message 3 of 6
(3,052 Views)
Sorry guys for being vague.
Pretty much the Thor's  transmitter is a UDP tranmsmitter which sends a command to an outside HW.  After  I have send  the command using Thor's TX  I need to wait untill the  UDP RX will receive and output a boolean TRUE.  UDP RX is a continous  receiver which outputs boolean output several times per second based on a response from a remote HW. UDP RX is outside my  State Machine because it needs to run constantly together with my SM.   In short, what i am trying to implement is this. I send a command to an remote HW via the Thor's TX.  After that I need to wait for response from that HW  using the UDP RX on whether the command is implemented (TRUE) or is pending (FALSE). Please let me know if more details are needed.

EDIT: I have attached the code of the  UDP RX.


Message Edited by RSibagatullin on 08-01-2008 06:24 PM
0 Kudos
Message 4 of 6
(3,047 Views)

I will start with some questions about the UDP_RX code...

Items 1, 2 & 3 seem to be tied together.  It appears that you stop the top left loop by causing an error at 1.  The error at 1 is caused by stopping the bottom left loop or if it has an error (at item 2), thus resulting in closing the queue reference (item 3) which innevitably causes a queue error and stops the top left loop at 1.  This is a strange way of implementing a solution..  We'll get to that later.

Item 4 will never stop the outer right loop. It is not recommended to code in this fashion. 

Is item 5 the boolean that you wish to send to the state machine from your original post?

 

What I would do is the following.  Convert your UDP_RX to a dynamic VI (daemon).   You call the dynamic vi from your other code (from original post).  Your dynamic VI could contain an Action Engine (or more specifically a Functional Global Variable) whose task is to provide a status on a timely basis.  You could even create your dynamic VI to contain a timed loop which will update the status at regular intervals.

When you end (stop) your program, you would also kill the dynamic VI.  A dynamic VI can have a continuously running loop, since the intent is to spawn and kill the VI from the calling program.

Below are the items I refer to in the top portion of this reply.

R

 

EDIT REASON: Shrank image (it was much bigger)



Message Edited by JoeLabView on 08-02-2008 09:22 PM
Message 5 of 6
(3,008 Views)

*** went beyond the 10 minutes with all the edits ***

Message 6 of 6
(3,000 Views)