Jump to content

All Activity

This stream auto-updates     

  1. Yesterday
  2. Jim Kring

    Loading Tests

    @Croohcifer Thanks for reporting this. I've filed a bug in the issue tracker, here: https://github.com/JKISoftware/JKI-VI-Tester/issues/33
  3. Jim Kring

    Test Cases not found

    Thanks for reporting this. I've filed a bug in the issue tracker, here: https://github.com/JKISoftware/JKI-VI-Tester/issues/33
  4. Hi SGI, Sorry for the delay in response. Have you tried using the Enum as String argument?
  5. Last week
  6. Croohcifer

    Loading Tests

    @Jim Kring I realize that this comment is almost 8 years later, but I can confirm that the UI does not appear to find any tests in classes contained in auto-populating folders.
  7. Croohcifer

    Test Cases not found

    @Robert Smith I know this is four years later and probably not very helpful, but I just used VI Tester for the first time and found that my tests would not appear in the UI if the test classes were in auto-populating folders. This may have been your problem. Hopefully this helps someone else who might come across this thread.
  8. Earlier
  9. Ruslan

    STATE MACHINE (*.vip)

    Hello! Thank you!
  10. Jim Kring

    STATE MACHINE (*.vip)

    Somehow the VIP file didn't get uploaded/attached to that github release. I fixed it -- you'll find the VIP file located here: https://github.com/JKISoftware/JKI-State-Machine/releases/tag/2018.0.5.41
  11. Ashish

    STATE MACHINE (*.vip)

    Ruslan, I will suggest to leverage VIPM's capability. Refer this link: https://support.jki.net/hc/en-us/articles/214135803-How-do-I-transfer-packages-with-VIPM-to-a-non-networked-computer-
  12. Ruslan

    STATE MACHINE (*.vip)

    Hello! Where can I download the latest versions of the state machine and the state machine editor as a vip file (there is no Internet access on that computer)? Or maybe you can get out of any directory when installing via vipm? https://github.com/JKISoftware/JKI-State-Machine/releases? here?
  13. For some reason I am currently getting this message when I try do build my project: Error 1 occurred at A VI broke during the build process from being saved without a block diagram. Either open the build specification to include the block diagram of that VI or enable debugging to include the block diagrams of all VIs in the build. Report this error to National Instruments technical support. C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\JKI\JKI SMO\SMO\Private\LaunchProcess.vi Click the link below to visit the Application Builder support page. Use the following information as a reference: Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi Possible reason(s): LabVIEW: Cannot save a bad VI without its block diagram. Possible reason(s): LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. The VI is perfectly fine outside the build process. Any ideas what could be the issue here?
  14. That's a great idea, Ajay!
  15. It would be great if there is a preview window along with the description editor. Right now, after formatting the description with various tags (like bold/italics etc.,) I would need to build the package in order to see the formatting. If there is a preview pane along with the description, it would easy to see the final formatting. Thanks, Ajay.
  16. This has been officially released in Caraya 0.6!
  17. Sorry to open this thread again. However, I have VIPM 2018.0.0f1 and I am trying to build a package with VIMs in and I am getting exactly the same issue that James Powell posted earlier in this thread. Please can you tell me what the workaround was? As simply upgrading VIPM didn't work.
  18. Jim Kring

    [FIXED] JKI SM - problem with JKI SM Editor...

    Great! Thanks @wyzromek for reporting the issue (especially the steps to reproduce). It was very helpful in finding and fixing the issue. I'm sure lots of people are happy about this fix, too
  19. Yep, the new version works well. Many thanks!
  20. Jim Kring

    [FIXED] JKI SM - problem with JKI SM Editor...

    We figured it out -- it was getting an error during Macro Exit (shutdown), that was causing it to go into the error handler, which was going into Macro Exit (an infinite loop). You can work around this issue by tweaking the code inside the JKI SM Explorer window to look like the following. (You can open the JKI SM Explorer then press Ctrl+Space to stop the VI, then Ctrl+M to go into Edit mode). Update: This has been fixed in version 2018.0.1.36 of the JKI State Machine package, which has been published and is available for download and installation using VIPM.
  21. Jim Kring

    [FIXED] JKI SM - problem with JKI SM Editor...

    We figured it out -- it was getting an error during Macro Exit (shutdown), that was causing it to go into the error handler, which was going into Macro Exit (an infinite loop). You can work around this issue by tweaking the code inside the JKI SM Explorer window to look like the following. (You can open the JKI SM Explorer then press Ctrl+Space to stop the VI, then Ctrl+M to go into Edit mode).
  22. Jim Kring

    [FIXED] JKI SM - problem with JKI SM Editor...

    OK, we're looking into it. I see what you're seeing -- I'm also using LabVIEW 2018. I'll check on older versions of LabVIEW, too, to see if this is a new problem.
  23. No, CPU usage is high all of the time. Yes, Mass Compile is enabled (always). I reinstalled JKI State Machine, but still nothing. So, I have to remember to close the Block Diagram first or JKI SM Editor (Explorer in fact...). Maybe it is important or not... my LabVIEW version is 2018 (18.0f2)
  24. Jim Kring

    [FIXED] JKI SM - problem with JKI SM Editor...

    Hello @wyzromek. Do you notice that the CPU usage goes down after a minute? Do you have Mass Compile (in VIPM options dialog) enabled or disabled? I did a little testing and see that if I do not have JKI State Machine Editor mass compiled during installation, then I have this increased CPU issue (but that it goes away after a minute). However, if I I let VIPM Mass Compile the JKI State Machine Editor on installation, then I do not see the CPU increase after closing the VI that was using it. I'm curious if you see a similar behavior to what I'm observing.
  25. I've got a problem with JKI SM Editor (JKI SM ver. 2018). In one case, it increases the CPU resources consumption. The procedure is as follow: 1. Open New VI or existing VI with JKI SM. 2. Open block diagram. 3. Open JKI SM Editor. 4. Close front panel of the VI. CPU usage increases - in my case (i5-4210M) up to 38 - 40%. Have to reset the LabVIEW. Has anyone observed silmilar behaviour? [Update: This has been fixed in version 2018.0.1.36 of the JKI State Machine package, which has been published and is available for download and installation using VIPM.]
  26. Jim Kring

    Error 1055 in JKI State Machine Editor

    Hello @Bhaghyaraj. Thanks for letting us know and I'm glad you were able to figure it out. It's probably a good idea not to rename the frame that contains the Event Structure, since the JKI SM and it's under the hood APIs depend on some of those conventions.
  27. Bhaghyaraj

    Error 1055 in JKI State Machine Editor

    The issue is because I renamed the event case to "Idle" from "" (empty string). Renaming the case name will resolve this issue.
  28. Hi @kevin.j.r.ross, @Sam Taggart, We can reproduce the issue and it's a bit tricky, due to limitations in the scripting APIs associated with project libraries and the fact that these project items are not LabVIEW file types. There's no scripting API function to move a project item on disk that is a non-labview file type (and the build process used by VIPM loads the lvlibs and VIs into memory and moves them on disk, causing the links to those lvlib/project items to change). The work-around to this would be to do a lot of fancy, custom relinking on disk, which involves parsing and modifying the raw XML files for the lvlibs. This could work for unlocked lvlibs, but won't work for a password-protected lvlib. Now, it's possible to do these changes in memory, but I think it would involve removing items from the lvlib and then re-adding them to the lvlib after they are moved on disk. I looked to see if anyone has solved this problem and there's a discussion on LAVA about it -- I checked out these resources (GOOP Developer and Darren's Hidden Gems) and these don't deal with non-labview file types, from what I can tell. Now, you could work-around this LabVIEW limitation with a post-build custom action (requires VIPM Pro) that temporarily unpacks (unzips) the package, modifies the lvlib's (and lvproj's) xml files to link to the correct paths, and then re-packs (zips) the package. I've created a sample project that shows this technique and it works for the Simple Example that Sam posted earlier. Here is that work-around in action: >>> Simple Example - Post Build Fix.zip <<< Some notes about this example work-around: Requires VIPM Pro Uses OpenG Zip Tools to unpack/repack (I've included a VIPC file you can apply to quickly install this) Has a very brittle XML parser/fixer (you can see the code, below) -- you'll want to put some of your own love into this (e.g. depending on the actual relative paths to the items inside the lvlib) 🙂 Hope that offers some possibilities for you...
  1. Load more activity
×

Important Information

By using this site, you agree to our Terms of Use.