Jim Kring

How do I get my own custom controls (or theme) to appear in the JKI Design Palette?

My answer: You can flush the queue by writing an empty string to it — do not use the "add state(s) to queue" VI, but instead wire an empty string into the state string shift register. That will clear all the remaining states.

A user asked me: How do you flush the state queue of remaining states?

Hi @Naveen. This is a great idea! It’s not currently supported, yet I can see that it would be extremely useful to be able to interact with an existing state machine, and to facilitate migration to a JKI state machine. Note: i’ve moved your question/idea into this new “ideas and future requests” forum, and I’ve given it an upvote! Jim

Hi @Daklu. Thanks for reporting this, and sorry for the trouble. I wanted to give you a quick reply to let you know we got your message and will look into this.

hi @holyna For the base URL, you would want to put the part that's common to all your method calls. Note: You might want to use HTTPS instead of HTTP, so it's more secure. Looking at some of their documentation, the base URL includes the version (e.g. "v1") as shown below: base url: https://api.favoriot.com/v1 Yes, you will need to put your API key in the "Default Headers" structure, and you'll also need to set the "Accept" header to "application/json" Accept = application/json apiKey = <YOUR API KEY> Hope that helps get you going. Good luck! -Jim

Hi Guillaume. When VIPM builds a VI Package, it makes a copy of your source folder right next to it and with a "." in front of the name. So, the ".BB Series x32" folder is that temporary copy of your "BB Series x32" source folder. I'm not sure why the DLL path is getting messed up. One possible work-around is to dynamically load the DLL by passing in the path to it yourself -- the CLFN supports passing in the DLL file path. Maybe that could be a good solution?

Hi Jatin, I’m glad you were able to figure this out and upgrade to the latest version. Hope the course is going well for you so far. Let us know if you need anything else. Jim

Hi Helcio, Yes, this happened in 2018. Our official statement about this is included in the release notes: "In order to best support our customers and ensure LabVIEW compatibility, VIPM supports new versions of LabVIEW as they are released. There are many instances where older versions of VIPM do not work well with newer versions of LabVIEW, due to changes in where/how LabVIEW and its files get installed." JKI has to provide support for each new version of LabVIEW as it's released, so we needed to align our support and releases with LabVIEW.

Hi Helcio, Yes, you will need to use VIPM 2019 in order to manage LabVIEW 2019. You can upgrade via the menu in VIPM (Help >> Check for VIPM Updates) or download from vipm.jki.net/download -Jim

That's a great idea, which we've been considering. We've posted a related idea and request for feedback, here: https://github.com/JKISoftware/JKI-State-Machine/issues/11

Hi @Jonathan. I'm glad you find the JKI tools helpful! It's possible, but will probably take some tweaks. There's a post here about how to use a Proxy with LabVIEW's built-in HTTP client VIs, which the JKI HTTP REST Client uses, under the hood. If you need support in figuring this out and implementing a solution, you can also Contact JKI to discuss your project.

You might need to install some extra libraries. See here. I'm not sure about your package manager, but something like: apt-get install libxinerama1:i386 libgl1-mesa-glx:i386

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.

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

This has been officially released in Caraya 0.6!

It looks like you need to install the LabVIEW 2015 run-time engine for Linux. http://www.ni.com/download/labview-run-time-engine-2015-sp1/5838/en/

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

Thank you. We'll take a look at reproducing this and if there's a future fix for the issue. We can't commit to a timeline, but we certainly would love to see this issue addressed in a future release, if there's a solution to be found.

Hi. Thanks for reporting this. Would you be willing to spend a small amount of time to create a super simple VI Package project that demonstrates this issue and share that with us (as a zip file)? We'd love to be able to reproduce this issue and see if there's a work-around or fix.

Not totally sure what the issue is. Have you tried running both VIPM and LabVIEW as the root user? Also, might be because LabVIEW is running in Evaluation mode. Linux is a bit tricky, since it's so configurable and quirky...

Hi @Jim C I split this discussion into a separate discussion thread. I like you're idea about the JKI State Machine Follower. I've been collecting some ideas about possible run-time and debugging tools: https://github.com/JKISoftware/JKI-State-Machine-Editor/wiki/Roadmap#run-time-tools Here are a few ideas: State logging - Show which states executed in which order Data logging - Show what data was changed between execution of frames Single stepping - Execute one frame at a time and pause between execution Breakpoints on individual states - Pause when a state is executed, so that highlight execution can then be enabled (and maybe we could turn execution highlighting ON, but I'm not sure how to do that programmatically) These tools would probably require temporarily swapping the Parse State Queue function in the user's instance of a JKI State Machine with a special one that has debugging features under the hood (there could be a debugging and non-debugging version of Parse State Queue that we could script in/out of the VI to enable/disable the debugging features). Anyhow, I wanted to let you know that this is a direction we're looking into, in case you have any ideas you've already been thinking about or working on :-) Thanks,

Thanks for the feedback @Jim C. I'm glad you like this new feature. I also like the idea of allowing the JKI SM Editor to help with debugging and have it highlight the actively executing frame. I've been toying with some similar thoughts :-)

We've made another great round of improvements to the JKI State Machine Editor that we're excited to tell you about. This release adds a pretty cool new little feature that we've heard several people ask for... Now, you can right-click on a state string wire and select Insert "Add State(s) to Queue" to automatically insert this VI.

Just a quick update that there have been some minor fixes and improvements over the past couple weeks (since the last big release). Fixed issue where tree fully expands after any edit of JKI SM frame names Fixed issue where sometimes state strings were not recognized correctly if they were inside or wired through structures Fixed some quick search/filtering bugs Added right-click option JKI SM Explorer tree view to Expand All and Collapse All items You can download and install the latest version using VIPM.