trobertson79 Posted April 20, 2020 Report Share Posted April 20, 2020 I was surprised to hear in the state machine course the best practice of adding states at the front of the state queue. I've always added them at the back under the theory that I'm "queuing up" states to be run, but I don't want to hijak the order of exectution if there's already seme states enqueued. The only time I add to the front is in an interrupt type situation. Can someone explain why adding to the front would be considered best practice? 1 Quote Link to comment Share on other sites More sharing options...
Jim Kring Posted April 27, 2020 Report Share Posted April 27, 2020 Hi @trobertson79. It's a great question! The sort of simple answer is this: In most programming situations, the developer should pick one way or the other (either add to front or add to back). Mixing front and back is a recipe for hard debugging. And, since the template already enqueues at the front then this is why we recommend to stick with that. Quote Link to comment Share on other sites More sharing options...
heel Posted August 21, 2020 Report Share Posted August 21, 2020 (edited) Suppose you have an architecture where states calls sub states to do the details of the action then you have to queue to the front. Example of a motor stage with a break: Top level commands queued are1) Move_To_Pos >> A 2) Move_To_Pos >> B where stateMove_To_Pos (PosArg) issues the actual string of commands or states: Break >> Off Goto >> PosArg Break >> On The initial queue after 1), 2) are queued will be: (Front) Move_To_Pos >> A; Move_To_Pos >> B (tail) which if you use add to front of queue gets expanded to (Front) Break >> Off; Goto >> A; Break >> On; Move_To_Pos >> B (tail) and if using add to tail: (Front) Move_To_Pos >> B; Break >> Off; Goto >> A; Break >> On; (tail) And this gets replaced with (Front) Break >> Off; Goto >> B; Break >> On; Break >> Off; Goto >> A; Break >> On; (tail) As you see the sequence of positions will be B then A and not as the example presumes A then B So for the concept of subroutine-like states to work you have to add to front. Edited August 21, 2020 by heel premature submit 1 Quote Link to comment Share on other sites More sharing options...
heel Posted August 23, 2020 Report Share Posted August 23, 2020 (edited) On 8/21/2020 at 11:04 PM, heel said: Suppose you have an architecture where states calls sub states to do the details of the action then you have to queue to the front. Example of a motor stage with a break: Top level commands queued are1) Move_To_Pos >> A 2) Move_To_Pos >> B where stateMove_To_Pos (PosArg) issues the actual string of commands or states: Break >> Off Goto >> PosArg Break >> On The initial queue after 1), 2) are queued will be: (Front) Move_To_Pos >> A; Move_To_Pos >> B (tail) which if you use add to front of queue gets expanded to (Front) Break >> Off; Goto >> A; Break >> On; Move_To_Pos >> B (tail) and if using add to tail: (Front) Move_To_Pos >> B; Break >> Off; Goto >> A; Break >> On; (tail) And this gets replaced with (Front) Break >> Off; Goto >> B; Break >> On; Break >> Off; Goto >> A; Break >> On; (tail) As you see the sequence of positions will be B then A and not as the example presumes A then B So for the concept of subroutine-like states to work you have to add to front. Sorry my conclusions are incorrect - please ignore the posting. Reason: The last replacement when going from: (Front) Move_To_Pos >> B; Break >> Off; Goto >> A; Break >> On; (tail) should also obey the "add to tail" to become: (Front) Break >> Off; Goto >> A; Break >> On; Break >> Off; Goto >> B; Break >> On; (tail) which gives the same result as when add to front. Only difference would be seen if there were other items in the queue. Edited August 23, 2020 by heel clarification Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.