Queues even driven state machine

Hello,
    i am working on this software and doing it via queues even driven state machine but Im having problem with. I understand how queues and event structure work but here's my problem. when I pass a massage to my state machine from the event structure via Queues. It works fine then stop. My goal is for the second loop where the state machine is to continue working but not wait on the next message. I tried ot use a time out on the queue but that didnt work. Is there anyway i can do that. I attached the VI. it's not finished yet but you will see what Im doing with it
Attachments:
check.vi ‏38 KB

Bob, thanks for your input. I attached the full vi for you to have a better understanding of what Im talking about. Keep in mind though it works it isnt closed to finished.
  My goal is to toggle different boolean that will generating different data. Each Boolean will generate a messgae via event structure to my message handling loop. once the message is passed, that loop will queue in the state of the data to generate. Once dequeued my plotting loop will generate the data then queue it in for display. It seems like there are too many queues being used but that is how I plan to write the VI. I want my 3rd loop to always generate the data so that my fourth one can display but that isnt working for me since the 3rd loop is always waiting on a message from teh 2nd loop ( messge handler). If you foolow the data flow you'll see what I am referring to
Attachments:
check2.vi ‏499 KB

Similar Messages

  • Wiring constants into the queue in a queued, event driven state machine

    I'm creating a queued state machine. Every time I change the queue control options to create a new event I have to recreate a constant in each queued event. Is there a way around this? I'm up to 27 events and changing them all is cumbersome. And I'm sure there are more to folow.

    Are you using enums for your constants? If so, make a control from one, right click on it and under "advanced" select "customize" and when in the control editor change the pulldown from "Control" to "Type def." Save it with a useful name, and then in the vi in which you originally created it, use it to create a new constant. You will be able to select the different constant values were you need them and now when you want to add or subtract a "named" value you just click on the closest copy of the type def, either control or diagram constant, and choose customize (or double click into the tool editor if you made that choice in the options in the Tool pulldown at the top of the screen). Any changes you make will automatically be replicated everywhere you have used the typedef, whether a control, indicator or constant. Using enums also allows having case statements that have cases with the same names at the "named" value.
    Hope this helps and is what you were refering too.
    Putnam Monroe
    Certified LabVIEW Developer
    Putnam
    Certified LabVIEW Developer
    Senior Test Engineer
    Currently using LV 6.1-LabVIEW 2012, RT8.5
    LabVIEW Champion

  • Run Code Continuously in Event Driven State Machine

    Hi there, I was wondering what is the best way to run code continuously in an event driven state machine. Particularly, I am going off the JKI state machine. At the moment I put the code I want to run continuously (acquire from an instrument) in the timeout case of the event structure. When the user presses the button, the event sends the value 0 to the timeout terminal of the event structure (through a shift register). If the user stops the acquisition then the value -1 is sent to the timeout terminal. This is a tip that I took from an article by Mike Porter.
    Would it be better to run this process in a separate loop? Is a state machine a bad design choice for running code continuously? I don't like my current solution because if I have another process I'll have to start putting case structures into the timeout case. Also, if the process takes a while then the event structure will take a while to respond.
    Thanks for your input!

    AKA_TG wrote:
     Adding to that I believe Preview Queue element to read the data and Lossy  enqueue to transfer the I/O output, especially if the I/O device responds slowly. This should keep your event structure polling along very nicely during I/O calls to the other structure.
    I actually prefer to use an User Event to send the data to the main event structure and/or whoever else needs it.  I am not a fan of the lossy enqueue (loss of data).  At that point, I might as well just use a Notifier and/or global variable.

  • Shutting down a queued event state machine with multiple parallel loops

    I am trying to find the best way to shutdown a program that consists of a queued event state machine architecture with multiple parallel loops. Can anyone recommend the best way to accomplish this in my attached VI? (From browsing the forum, this seems to be a common question but I haven't found a solution that works for me.)
    I welcome any other feedback on my code as well, if anyone is willing to offer it.
    My Program Requirements:
    If the user presses the "Shutdown" button, the program should prompt the user with "Are you sure you want to stop the program?" and then either return to the Idle state or proceed to stop the program. Additionally if there is an error, the program should prompt the user with "Clear error and continue, or Stop program?" Then either return to the Idle State or proceed to stop the program.
    Details of architecture:
    The program consists of 3 parallel loops: (1) an Event Handling loop that enqueues various States to a State Queue, (2) a State Machine which enters the latest state that is dequeued from the State Queue, and (3) an Error/Shutdown handling loop which processes any errors in the Error queue.
    During normal Shutdown, in the Event Handling loop the "Program.Shutdown" event case executes, and the States "Shutdown" and "Idle" are added to the State Queue. In the State Machine, the "Shutdown" state is invoked. A special error code "5000" is added to the Error Queue. In the Error/Shutdown handling loop, the "5000" error triggers a prompt that asks the user if they want to stop the program. If the user chooses not to stop, a notifier StopNotif is sent to the "Shutdown" state and "Program.Shutdown" event case with the notification "Go". If the user chooses to stop, the notifier sends the notification "Stop". The Event handling loop and State Machine are terminated if they receive the notification "Stop".
    In case of error, the program behaves similarly: if the user chooses to clear the error and continue, the program returns to the "Idle" state.
    HOWEVER - if the user chooses to stop the program, the program stalls. The notifier that is sent to stop the Event Handling Loop and State Machine cannot be read because the Program.Shutdown event case and the Shutdown state (which contain the "Wait for Notifier" function) are not active.
    I have been able to activate the Shutdown state by enqueuing it in the Error/Shutdown handling loop. But I don't know how to activate the "Program.Shutdown" event programmatically, and thereby access the "Wait for Notifier" function inside it.
    I tried to place the "Wait for Notifier" function outside the event structure, but then the Event Handling loop never completes. Placing timeouts on the "Wait for Notifier" and on the Event structure makes the program work, but I want to avoid using timeouts because I don't want to turn my event-driven program into a polling-based program. I'd also like to avoid using variables or property nodes to stop the loops, because that requires creating a control/indicator for something that the user doesnt need to interact with.
    Thank you!
    Solved!
    Go to Solution.
    Attachments:
    Queued event state machine parallel loops empty.vi ‏46 KB

    Thanks for clarifying that, Ravens Fan.
    I marked crossrulz as the solution for pointing out User Events to me.
    I also adopted Ravens Fan's suggestion to keep the Shutdown procedure out of the Error Handling Loop. This has simplified the architecture by eliminating the need for Notifiers. Instead, I have used booleans in case structures to stop the Event Loop and State Machine, and Release Queue to stop the Error Handling Loop.
    For reference, I'm attaching my corrected code.
    Thank you to everyone who helped!
    Attachments:
    Queued event state machine parallel loops empty in progress.vi ‏44 KB

  • Producer Consumer with a state machine within the consumer

        Hi All,
    I have been trying to develop a data acquisition system with the producer consumer architecture.  To the left of the two main loops I initialize the serial port and any constants and variables im using.  I also have an obtain queue VI needed for enqueue and dequeue. Then in the producer loop i have a state machine.  The first state is where I wait for a button press on the front panel to write a GO signal on the serial line which will tell the device connected to the serial port to begin sampling data.  After this button press I go into the next state which is called my read state.
    In the read state I use a property node to read all of the available bytes at the serial port and then enqueue this collected data into a queue.  The state machine then is directed to continously go to the read state again and collect more data.
    Now this is where my dilemma is......  The consumer loop has the dequeue VI inside it and after this VI i have a state machine (while loop and case structure) which contains the following states
    1.  Build Array - build an array from the dequeue element and if there is any left over data from the parsing states it will build an array with the left over data and the dequeued data
    2.  Determine packet type - this state looks for the packet type byte(not necessarily the first byte in the message) and also check the next byte (packet length) to ensure that I am at the begininng of this chunk of data.  This state may be a little slow because there can be three different packet types and based on this byte and the packet length it may have to search the array several time to find the valid starting point.  This state also determine the next state to go to based on the packet type.
    3 packet type 1 parsing - parse data and store the remaining data it leftOver array.  Go to exit state.
    4 packet type 2 parsing - "" ""
    5 packet type 3 parsing - "" ""
    6 exit - leave this state machine and fall back to the consumer while loop.
    After it exit I think it should fall back to the consumer while loop and dequeue more data and enter the state machine again to build a new array with the dequeued data and leftover data.  It seems to work when I trace the execution using the Highlight execution feature, however when I run this all at full speed, it seems to go into the consumers 1st and 2nd states back and forth and not completely go through the state machine.
    I tried adding in a delay in the producer loop to give the consumer loop time, but I didnt notice any difference.  Is it possible that my dequeue element is retreiving more data while im still in the state machine, causing the execution to leave the state machine before it finished all states?
    Is there a better approach to take to solve this problem. Basically I need to read data at a 1,000,000 baudrate and parse it as quickly as possible so that I can break it up into 3 different packet types, write the data to a file, and graph the actual data (header info removed) in realtime.  I need to also ensure that I am not losing any of the collected data.  Data loss cannnot occur.

    A couple of things more to go along with Ben's pointers:
    You convert your data from a string, to a U8 array, to a Hex string array in the producer loop, then convert back to a integer to determine what to do with it.  In the process, you create two or three copies of your data, slowing yourself down quite a bit.  The code would be quite a bit more efficient if you left the data as a U8 array.  You can change the format of the controls and indicators to show hex values instead of integer by right clicking on them and selecting Format and Precision...
    Your search code is fairly inefficient.  I made a whack at making it a bit better.  See attachment below.
    If you continue to run into race conditions, you can debug them using a calls to the Windows debug write sprinkled liberally about your code.  Check out the post here for more information.
    Don't let your lack of format LabVIEW training stop you.  The biggest thing to get is the data flow paradigm (aka data is wires, not registers).  Once you get past that and learn how to pass data around using shift registers, queues, events, etc, you are most of the way to mastering LabVIEW.  The rest is just learning the plethora of functionality LabVIEW gives you (yes, I have reimplemented LabVIEW native code more than once in the process of learning).
    Let us know if you need more help.
    This account is no longer active. Contact ShadesOfGray for current posts and information.
    Attachments:
    serialUtil_V3_DFG.zip ‏137 KB

  • Tcp state machine trigger

    Hello, I am working on some statemachine architecture, I was wondering what the best method of sending states between vis could be. Essentially I would like to send states to be read over TCP as triggers for the various parts of the statemachine in another VI. Basically it would be like the following:
    VI1: Statemachine1: Idle->State A->Send Trigger (Trigger1)->Wait for trigger (Trigger2)-> State A or ->End
    VI2: Statemachine2: Idle-> State B-> Wait for trigger (Trigger1) -> Send Trigger (Trigger2) -> State B or ->End
    State A and State B are arbitrary, Trigger1 and Trigger2 I am hoping to be merely state cases sent via TCP. 

    my suggestion would be in each application have a tcp loop and a Queued message handler loop. State machine 1 goes to state A, puts a 'send trigger1' message in a queue to its tcp loop. The TCP loop reads this from teh queue then sends this message to application 2, which reads it, stick the message in a queue to the state machine 2 loop to process.
    By doing this you decouple your tcp logic from your state machine logic. From my experience, it is never good to mix network communication logic in the same loop as your data processing. TCP does some weird things if you aren't getting back to the "TCP Read" function on one end as quick as you are writing on the other end. I tried this once a couple years ago in order to simplify my architecture on a relatively simple and quick program, but it actually ended up taking more time troubleshooting the TCP IP. Now I always keep them separate.
    CLA, LabVIEW Versions 2010-2013

  • New LabHSM Toolkit - Agile development of complex event-driven maintainable LabVIEW applications with active objects / actors based on a universal Hierarchical State Machine / statechart template.

    Dear Fellow LabVIEW programmers:
    Most of the systems you deal with are reactive. It means that their
    primary function is constant interaction with their environment by
    sending and receiving events. But most likely, they can have something
    happening inside them too, even when they are not processing messages
    received from outside. So, such systems have to continuosly react to
    external and internal stimuli. Right? Moreover, most likely, they
    consist of subsystems that are reactive too and, in turn, can have
    their own "life", to an extent independent from other parts (with
    which they still communicate, of course). Reactive (event-driven)
    systems are more naturally modeled with active objects. So, why then
    should we try to model and code them with GOOP and its passive
    ("dead"!) objects?
    "Flat" State Machines have been known for decades to have severe
    limitations. It's been more than 20 years since Dr. Harel invented
    Hierarchical State Machines (statecharts) to fight those limitations.
    Then why does NI still tout the same old good Moore FSM as the
    ultimate tool for event-driven programming in LabVIEW in its $995
    State Diagram KIt?
    The LabHSM toolkit we are happy to present, makes it possible to
    easily create and then maintain complex event-driven applications in
    LabVIEW as a collection of HSM-driven active object VIs using a higher
    level of abstraction and agile software development methodologies.
    These active object VIs are created based on a universal Hierarchical
    State Machine ( HSM or statechart ) template. So. all your code looks
    similar regardless of its functionality!
    We all love just jump to code, right? However, to be good boys, we
    need to do design first. Then implement it in code. If the logic is
    modified we need to redo the design first and then redo the code. When
    using LabHSM where behavior information is abstracted into a separate
    HSM data file editable with a supplied editor, there is no need for
    coding separate from design any more. The modified behavior becomes
    code automatically as soon as the HSM file is saved. Design is code!
    The implementation basically follows Dr. Samek's Quantum Programming
    paradigm. (see http://www.quantum-leaps.com). However, as already
    mentioned, LabHSM stores the behavior information in a file separate
    from the code itself. It also adds state dependent priorities to
    events, a separate queue for public events/messages, and, of course,
    some LabVIEW specific code like capturing front panel user events and
    putting them into the private Events queue. Communication and
    instantiation functions are also rather specific for LabVIEW.
    It is available for UNLIMITED PERIOD trial. Please visit
    http://www.labhsm.com for details and download. The site also contains
    references which you may want to check to learn more about
    hierarchical state machines and active object computing.
    Since this is our debut we will appreciate any comments and
    suggestions. Our contact information is available on our site, of
    course.
    Have a G'day!

    Symtx is currently hiring the following position. Please contact me if interested.
    Amy Cable
    Symtx, HR
    [email protected]
    Symtx, the leading supplier of functional test equipment, hires the brightest & most talented engineering professionals to design & manufacture complex custom electronic systems for advanced technology leaders in the defense, aerospace, communications, medical, transportation & semiconductor industries. Symtx’ challenging & dynamic work environment seeks to fill openings with highly qualified electronic engineering design professionals.The ideal candidate will be responsible for defining the requirements, software design and code development, and integration of test control software for custom functional test systems. Candidate should be familiar with data acquisition concepts, instrument control, complex test, measurement and calibration algorithm development and definition and implementation of control interfaces to hardware. Prefer familiarity with instrument control via GPIB, VXI, MXI, RS-232 desirable. Requires BS/MSEE and 3 -7+ yrs of experience in one or several of the following test applications in a Windows NT/2000/XP environment using Labwindows CVI, TestStand, Labview, Visual Basic, C++ and knowledge of RF systems is a plus. Job responsibilities will include software design, development, integration, team leadership, and interfacing with customers( includes PDR’s & CDR’s).

  • Simple State Machine Vs Queued State Machine

    Using LV2009 + WIN7+Pentium 4 @ 2.5Ghz with 3 GB RAM.
    I have a machine control code inside a 10mS main loop that has 7 ( yes seven ) Queued State Machines (  QSM) and I find the  Finished Late boolen keeeps poppping often. Not a very good sign if you ask me.
    And the code itself does not have too much of computation or FP activity. But it has four Graphs with one plot on each of them. These are updated once every 10ms. Can slowing this update ( say once every 250ms ? ) help ? 
    A simple query : In terms of performance overhead, does a QSM  demand more than a  Simple State Machine ( SSM ) ? Can I avoid the Finished Late warning by switching over to SSM at least in three of the cases out of the seven ?
    Thanks 
    Raghunathan
    LV2012 to Automate Hydraulic Test rigs.

    I think your question demonstrates my point.  Unfortunately, I don't have a good example to point you to and don't have the time to write one.  I will try to explain better.  Let's take a simple example - a landscape watering controller (sprinkler controller).  This controller will have several states (e.g. initializing, waiting, watering, closing). Each of these states will accept several commands, but not all commands are accepted in all states.  For example, if the system is watering, a command to start watering could be ignored.
    In most programs, at least some states should be interruptible.  For example, if it starts to rain, the watering system should stop watering immediately instead of watering for a set length of time.  However, if the system is in the initialization state, this will probably not be interruptible (but also short).
    As you said, the classic LabVIEW way to implement such a thing is to have a case statement to represent the state, and a case statement (usually queue driven) in each state frame to handle the commands.  You thus have a loop with a double case structure.  This can get somewhat unwieldy for large programs.  Note that which case structure represents what will be determined by the relative number of each item. For example, if you have fifty commands and three states, the state should go into the command case.
    So how do LabVIEW classes help?  They can eliminate one or both levels of these case structures through the use of dynamic dispatch.  This is done as follows.  A parent class is created that is a generic command.  It has commands for each state.  For each actual command, a class is derived from the parent class.  There are VIs in the specific command class for each state.  A command is generated by creating the correct object for the current state, then calling the parent class command.  Dynamic dispatch will execute the code for the correct command.  The command execution loop is then reduced to a single command VI which dynamically dispatches based on the actual command and the current state.
    In practice, things as usually not quite this simple, and you may want different cases for either different commands or different states so that you can change the connector pane of the dynamically dispatched VI as needed.  Look up the LabVIEW examples on dynamic dispatch to see this in action.
    I am afraid I have still not made myself clear.  Keep asking questions and I will try to keep answering.
    This account is no longer active. Contact ShadesOfGray for current posts and information.

  • Double Click Property Node not functioning with Queued State Machine

    I am writing an application which relies on input from the operator to start different steps in a process of steps.  I am using a queued state machine, however I cannot get the Double-Click property of my listbox to function with in this Queued state machine.  I have tried Creating a refrence to the Listbox and creating a property node from that refrence.  I have tried a property node of the control.  The double click functon works only if the queueing is not occuring.  It has something to do with the queue but I am at a loss as to what is causing it.  Any help would be GREATLY appreciated.  I have attached a simplified version of the state machine with the double click function.  Thanks for any help on this.  It is written in LV7.1
    Attachments:
    Test Q.llb ‏55 KB

    Hi
    Its  Simple....
    Your Properrty node is not getting read..... dont understand how..
    see the attachment...
    now laugh at your small mistake... (even i have the habbit of making such small mistakes ;-) )
    Message Edited by Tushar Jambhekar on 01-11-2006 11:38 AM
    Tushar Jambhekar
    [email protected]
    Jambhekar Automation Solutions
    LabVIEW Consultancy, LabVIEW Training
    Rent a LabVIEW Developer, My Blog
    Attachments:
    Test Q.llb ‏55 KB
    Picture.JPG ‏44 KB

  • Advantages of Using Queued Message Handler vs. Standard State Machine

    Hello,
    What are the advantages of using a Queued Message Handler?  Also, why are they more powerful than using Standard State Machines?
    Thanks!

    They are really just sort of an extension of a state machine.  The general idea is that you have one loop doing a specific job.  You then use a queue to tell it how/when to do this job.  For instance, I might have a log file loop.  I will send it commands to open a file, write some data, write some more data, and finally close the file.  Each of those commands are coming from the queue.  The beauty with this setup is that anybody that can get a reference to that queue can send the command to that loop.
    So the QMH is "better" than a state machine mostly because of the decoupling of functions.  In a given application, I will have a loop for log file writing, GUI updates, reading of a DAQ, instrumenet communications, server communications, etc.  Trying to do all of that in a single loop state machine is a major pain in the rear end.  Seperating them out makes life so much easier.
    There are only two ways to tell somebody thanks: Kudos and Marked Solutions
    Unofficial Forum Rules and Guidelines

  • Queued State Machine, not a state machine?

    I've been reading up a bit on design patterns that seem popular among LabVIEW users, and I have a question with regards to the design pattern described in the following article:
    http://expressionflow.com/2007/10/01/labview-queued-state-machine-architecture/
    I don't see how this is a state machine at all. To me it just looks like a producer/consumer pattern for queuing up actions (what is described in the article as states) to be executed in the consumer loop. I don't see where a state machine comes into play, determining state transitions based on current state and inputs, like shown in the following:
    http://zone.ni.com/devzone/cda/tut/p/id/3024
    Am I completely off?

    Yeah exactly.
    I was thinking a nice way to implement something QSM-like would be to produce instances of a message handler object that maintains its own state and a message queue. You could produce a new object for network I/O that inherits from the general message handler, one for managing the UI, data aquisition etc. They would communicate in a network by passing messages back and forth to their respective queues and each would be a true implementation of a state machine.
    Has to be right up LabVIEW's visual alley
    Edit:
    Now that I come to think of it, this would be almost exactly what could be done compactly with LabVIEW event handlers and user-generated events.

  • Need help with basic user events in Queued state machine example

    I have written a little queued state machine example to try to teach myself about creating and using user events.  The objective of the machine is to periodically choose a number (I'm doing it now with a control instead of a random number generator for troubleshooting), and compare that number with the number I have set in a control.  When they match, I want to cause an event to fire so I can do something about having found a match.  The examples in the LV Help file references show the events within the event structure, but I want to reach out of a state and cause an event ....
    Can someone point me in the right direction here?
    Thanks
    Hummer1
    Solved!
    Go to Solution.
    Attachments:
    User Event Generator Example01 snip.png ‏102 KB

    Yep....That was it...I had tried to do that but got fouled up with the variant definition...so defined the user event using a boolian and did the same in the case structure where I wanted to create the event and it worked great...
    Thanks.
    Here is the final version...not bulletproof, but does have a queued state machine using a user event to cause an event to fire.
    Hope you find it useful.
    Hummer1
    Attachments:
    User Event Generator Example01.vi ‏45 KB
    Operating States Enum Example01.ctl ‏5 KB

  • Tips to remember when using Queued State machine

    I have been able to work through to convert my State Machine architecture to a QSM thereby eliminating using Local variables/property nodes to send values/data to my State machine but instead sending them through queues.
    I would like some tips/advice on making use of them perfectly. Especially, "Not to do" stuff with queues and How to efficiently release a queue etc. What is the convention when using queues? Thanks!
    V
    I may not be perfect, but I'm all I got!
    Solved!
    Go to Solution.

    VeeJay wrote:
    Hmmm!! I jumped the gun... I would have to say, Neither... I guess it isn't really QSM or Queued message handler. My State machine is the generic one. But, data for the SM is obtained from a queue and feedback is sent back from the State machine through a queue. Does that clarify ?
    BTW, good to know more variations.. Thanks!
    That is a QSM.
    I will defer to those that use them regularly.
    I would only use such a a construct if the queue was limited to a single entry and prevented inserting multiple states at the front or back of the queue.
    As long as the queue is limited to a single entry then a State Transition Diagram could be used to described all of the states.
    The multiple entry version can be thought of as a method to implement a "goto" statement in LV. Very useful for those that come from a background working with stacks and pushing and popping off work and those that use them often love them.
    But for me let me refer to a letter from Dijkstra quote from here
    "GOTO Staements Concidered Harmful" goto statement introduces chaos
    Ben
    Ben Rayner
    I am currently active on.. MainStream Preppers
    Rayner's Ridge is under construction

  • Exit of queued state machine

    Hello,
    i have probleme existing an queued state machine vi :
    I can't see how to do to make my vi stop before the wainting time here example is 3s (splitted in 25ms) .
    I
    thinkthere is a probleme flush queued or course competition  something like that
    but i a little new to this kind of codind that i'm a little bit lost.
    here zip file of a minimized programme to isolate part that make me crazy
    For the moment to make it run in a trash mode i put the 25ms wait out of case structure , it works but it means that every case take 25ms
    and is not  good job , because i have something like 20 cases in reality  
    Thank you for help
     Best regards
    Tinnitus
    CLAD / Labview 2011, Win Xp
    Mission d'une semaine- à plusieurs mois laissez moi un MP...
    RP et Midi-pyrénées .Km+++ si possibilité de télétravail
    Kudos always accepted / Les petits clicks jaunes sont toujours appréciés
    Don't forget to valid a good answer / pensez à valider une réponse correcte
    Attachments:
    Ma distribution du code source.zip ‏97 KB

    Well..
    I was not able to get events you have registered with event structures. And also couldnot understand properly because of french texts.
    Anyway, you are facing this problem due to the STTM Q MGR_new.vi in the consumer loop. You are queing more elements in each iteration. This causes your loop to hault untill this vi finishes execution although you have dequed exit case in the end.
    So is it really necessary to have this vi outside the case structure? cant you use this vi to que elements in the producer loop? (loop above?) 
    . Or you can queue required elements inside the case structure of consumer loop.(Place this vi in whichever cases necessary)
    As shown in the figure,  move that vi either inside the case, or you can just que those when the user action takes place in the producer loop.
      I hope i am clear in what i am trying to say. Your lower loop will never stop untill the STTM Q MGR_new.vi stops its execution, so it is necessary to meve as mentioned in the figures
    Attachments:
    Deque.PNG ‏64 KB

  • Queued State Machine skipping states?

    Hi,
    I started out writing my application using a simple state machine but I realized it was necessary to make the application more interactive and prevent the UI from freezing when interupted. For example, I want the user to be able to abort the test by clicking the stop button or a reset button that sends the state machine sequential flow to the reset state.
    I implemented the my QSM by looking at the example in the link below.
    https://decibel.ni.com/content/docs/DOC-14169
    However, the problem now is that the state machine no longer runs sequentially as in my initial simple state machine. Sometimes a state is repeated and at other times a state is skipped. By skipped, I meant it didn't follow the order I tried to implement in my code. I flush the queue before any new user input so I don't know what's causing this behavior in my application.  Has anyone experienced this type of problem before? If so how can it be fixed.
    Thanks

    Hi
    I'm still trying to find a solution to this problem. I was able apply a temporay remedy in an earlier application but in my current application, I'd have to find a permant fix to it.  This problem is described in comment number 4 of the community example code link below. I tried to apply the recommended solution but it didn't work. Perhaps, I was doing it the wrong way. How will the example code be modified to fix the problem described in the comment? I will appreciate any suggestions.  Thanks
    https://decibel.ni.com/content/docs/DOC-14169 
    Comment4
    This pattern has a potential risk of get cycled or get into unwanted states. Let me explain it. When you click on button, an event occurs and typically an element is enqueued to the queue. But in the lower loop another element is enqueued (in this case Report or Process). So when you for example want to go to idle state by clicking on the Stop button, you go to idle state but then you go to report or process state because the element was enqueued behind the idle element as explained above. The solution is to check if the queue is empty before enqueuing the element in the lower loop:
    If the queue is empty, it is safe to enqueue element in lower loop:
    If it is not empty (this occurs when an element is enqueued in the upper loop due to event occurence), the element will not be enqueued:

Maybe you are looking for