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

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

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 g

If you have a slow - heavily loaded pc (win7/64b) and LabVIEW(2018) is exceeding the timeout time. Then if you retry the installation from VIPM I have seen that two instances are launched. VIPM ought to see that there is already an instance being launched and wait for that to be ready.

Tools: LV2013/32b, VIPM2013.0.1-1905(free) , Win 7/64b I have a LVLIB with a polymorphic VI+ its sub instances, which i want to package. For this, I add all the relevant source files - including the lvlib file. Destination is toolkit, and user.lib (see attachment) The functions palette is auto-generate for a start, then all but the polymorphic top instances are removed. (want a dense palette with only the essential vi's) Generate and install. BUT the installed palette looks like the auto-generated palette before editing. I.e. all the vi's are in the palette - also the instance v

Hello, Has there been any updates which takes care of this issue? henning

I can only report same problem also with Win 7/64 bit and with LV2009/32. The coinstalled LV2009/64 does not have any menu item for TSVN, only LV2009/32. I dont recall to have seen any place in VIPM (vers 3.0 build 1280) where I can select between installation under LV2009/32 or /64. I guess this must be a feature to add then. Anyway the main problem is that it does not work as descibed in this thread, under any of the setups. I may add a piece of debug information. I tried to lower the user access control level to minimum - similar to what was the patch with TDMS under Excel TDMS