08-02-2024 06:17 AM
Hi,
I have a producer loop, that contains continuous temperature measurement from NI DAQ with thermocouples and a consumer loop which is a event driven state machine. I'm transferring the temperature through Tag tunnel. The temperature is then processed in few states in consumer loop. When I run the application, the temperature in producer loop is continuously updated but if I put an indicator to consumer loop, the indicator is frozen and only updates for a brief moment when I switch to another state and once the state machine goes to default state (ready) the indicator is frozen again.
I want to continuously update the temperature in the producer loop no matter what. Am I missing something? How to implement this?
Thank you
Solved! Go to Solution.
08-02-2024 06:39 AM
Several points:
Sounds like you want to have a DAQ loop that continually runs, sometimes "exporting" data to a Consumer, sometimes not. A State Machine (coded as a Channel Message Handler?) tells the DAQ Loop (via a Tag?) to start/stop "exporting" the data to a Consumer (via a Stream Channel). Does that sound about right?
Bob "Channel Wire" Schor
08-02-2024 06:47 AM
@JKLV wrote:
the indicator is frozen and only updates for a brief moment when I switch to another state and once the state machine goes to default state (ready) the indicator is frozen again.
I'm guessing you have a loop inside of your state machine that is keeping it from iterating. In a proper State Machine, you do not have loops inside of the states. Instead, you do whatever inside of the state and then set the state to repeat. This will allow all of the support code that is outside of the Case Structure to update as well.
08-02-2024 08:37 AM
I want to continuously update the temperature in the producer loop no matter what.
what prevents you to put the indicator on the producer loop ?
By inserting the indicator on the consumer loop, the indicator updates only when it is running or changing states (as expected).
I don't understand what is your problem.
08-02-2024 09:59 AM
Thanks for the feedback Bob, this is my first application of this kind, so there are some mistakes.
I can't provide original VI as it contains confidential data but I'm appending simplified VI which should support my point.
In the real project, we are measuring stator losses of an electric motor inside thermal chamber by power analyzer. The temperature inside the chamber is fixed and due to losses, temperature on stator (measured by thermocouple inside the producer loop) will rise. The state machine loop handles some events based on user actions on the UI (initialize the machine, set temperature, stop, etc) and some actions based on logic - start measurement when thermocouple temperature = thermal chamber temp and stop when it rises by 1°C for example (This might take few mins).
That's why I need the temperature to constantly update in the state machine loop, so 'measure' state knows when to stop. I didn't run a test on real HW just yet but when I see that 'frozen' indicator, I'm guessing the state will not know when to stop as it won't update. I hope this makes it more clear now.
Perhaps this design is not suitable for the thing I'm trying to accomplish (I don't know).
08-02-2024 10:05 AM
crossrulz and LVNinja, thank for your responses.
I think, I understand it better now. Please see the VI provided above. Originally I have a while loop inside the 'measurement' state which is violation of a state machine architecture, right? Instead of that, I should place a logical condition inside that state that would loop through this state for as many times as needed until that condition is satisfied. Everytime the state changes, the temperature is also updated, so it is technically continuous. Right?
08-02-2024 10:18 AM
Your Event Structure is "freezing" your State Machine as the loop will not allow the loop to iterate until an event is triggered. What I have done in the past was to use the timeout for the Event Structure to keep the loop iterating.
Another route that I have seen is to rethink the placement of the structures. Instead of having the Event Structure in a case of the State Machine, you flip that and have the Case Structure for the State Machine inside of the Timeout case of the Event Structure. The idea here is that an event takes priority. If there is no event, you perform the case required for the State Machine. You will have to wire up the Timeout so that it doesn't wait forever.