heel

Ok, It was not that hard to backtrack what created the malfunction of JSME: Adding a case structure after the SM case as shown in attached snippet breaks the JSME. The intended purpose is to take a snapshop of the state queue when an error is detected. I will find another way to do this kind of logging which is compatible with JSME. Suggestions are invited. I am curious as to what are actually the requirements for proper function of JSME. Again on the logging side - I have made a small vi which will record the history of the states. Uses a queue and functional global for ease of use. As here placed on the diagram it does not break the JSME. Maybe it is useful to others. State History Recorder - finite depth - FGV.vi

Hi, My design with JKI-sm has evolved into a state where I can no more start the "Jki State Machine Explorer" (JSME) on the project. I assume it is because I have added som changes to the architecture which prevents JSEE to recognize the JKI-sm structure - but I cannot figure out which. It works nicely on a fresh (and empty) design so it is not an installation issue and it has started to appear during the development phase. I use JKIsm version announcing it as 2018 on the while loop rim, (vipm says version 0.7.45), LV2019/64bit but LV2020/64bit behaves the same. What I see is that Right-click on the rim of while loop, case structure or event structure does not show the JSME menu item. Only right-click on the state string enables the JSME menu item for selection but the JSME does not appear, and no errors are shown - just silent Hope to get suggestion on how to fix this as the Jki State Machine, primarily because of the Jki State Machine Explorer, are very useful tools! thanks

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.

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 are 1) Move_To_Pos >> A 2) Move_To_Pos >> B where state Move_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.