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.

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 vi's which were deleted. What could I be doing wrong her? Edit: If I unselect: palette->Custom Category, then the function palette is correctly installed in the edited version - but I want it to be in User Libraries sub palette. For this I can of course browse for the desired location, but I don't understand why the previously described method should not work as well. palette support.pdf

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 Excell plugin, but unfortunately it did not give any improvement. I hope you get this to work. I would certainly pay for such a tool. Henning