Jump to content

Jim Kring

JKI Team
  • Content Count

    1,357
  • Joined

  • Last visited

  • Days Won

    16

Everything posted by Jim Kring

  1. Jim Kring

    UI monitoring in sequence

    Hi @Naoki. Yes, you can just put the call to "Idle" inside of your sequence of calls, and then the JKI SM will handle the subsequent states after checking for user interface events. There are some considerations, but it's totally possible and works well. Remember to set a Timeout greater than zero (but NOT zero, due to CPU usage concerns!) so that if there are no events, the Timeout frame will execute and your sequence will resume.
  2. Great. We've just released 3.0.2 for download with VIPM.
  3. Hi @Bhargavi, I’m glad to hear it’s working for you. Thanks for testing it out. -Jim
  4. Jim Kring

    UI monitoring in sequence

    Hi Naoki, You can explicity call the “Idle” (“Event Structure”) state, in your measurement sequence, to check for events. There some lessons on how to do this in the JKI State Machine Online Training. -Jim
  5. Hi @Bhargavi, Can you please try this pre-release build 3.0.2, and see if it works for you? Please let me know how it goes. Also, how are you planning to access the reference (inside the TestSuite) from within the TestCase?
  6. OK, I think that's the best approach. I think that we may still need to fix some of the flattening/unflattening issues inside of TestSuite.lvclass:WaitOnTestComplete.vi (and the TestSuite runner), in order for the reference to be valid.
  7. Hi @Bhargavi, Thank you for posting this example project. The breakpoints do a great job of showing the problem you're seeing. I did find that some of the deprecated control value methods are being used and the typecasting issue is present (and those should probably be replaced with the variant counterparts). However, that's not the only/main problem at hand. Another big issue I see is that the TestSuite's New.vi method is being called when VI Tester first loads the Test Suites, and then the New.vi goes idle, which means that any references created inside of New.vi will get disposed of automatically by LabVIEW (when the VI goes idle). VI Tester works around this with the TestCase and TestSuite setUp.vi using the TestCase.lvclass:WaitOnTestComplete and TestCase.lvclass:WaitOnTestComplete VIs, which keep setUp.vi running until the test case/suite completes. However, that's not exactly what you're after -- you're trying to initialize the data of the TestCase inside the TestSuite New.vi. I'll need to think about this some more, to see if there's a good solution.
  8. Hi @Bhargavi Would you be able to create a very small test project (and zip+attached it) that demonstrates the issue? That will make it easier to debug. Thanks!
  9. Thanks for reporting this @Bhargavi. We've just released VI Tester 3.0 with a fix for this. Please let us know if this works for you.
  10. Hi @jamesmc86. Thanks for letting us know. I'd like to get this fixed, if possible. Would you be willing to put a very small/simple example .vipb project together and share it, so that we can easily reproduce and investigate? Thanks.
  11. 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
  12. 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
  13. Hi SGI, Sorry for the delay in response. Have you tried using the Enum as String argument?
  14. 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
  15. That's a great idea, Ajay!
  16. This has been officially released in Caraya 0.6!
  17. Hi Everyone. I've just posted an idea that I'd like people's feedback about. It's to create a polymorphic VI for Assert and show the Polymorphic Selector Ring, by default. You can see more details about the reasoning behind this proposal, here: https://github.com/JKISoftware/Caraya/issues/26 Thank you for your comments and ideas. -JIm
  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. 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.
  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).
  21. 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.
  22. 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.
  23. 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.
  24. 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...
  25. Hi Sam, Thanks for posting this example. I'll pass it along to our team to reproduce and review. As always, we can't commit to a fix timeline, but we'll certainly look into it.
×

Important Information

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