
heel
Members-
Content Count
8 -
Joined
-
Last visited
-
Days Won
1
heel last won the day on September 29 2020
heel had the most liked content!
Community Reputation
1 Neutral-
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