JKI Open Source Projects

We are excited to announce that JKI has officially launched its open source software projects on GitHub.

jki+github

JKI strongly believes in contributing to the open source movement and has made several of its LabVIEW libraries and tools available under the BSD License, a very commercial-friendly and permissive free software license (meaning, it’s very safe to use in your proprietary and commercial software applications and you won’t have to share any of your own code with anyone).

For starters, we’ve open sourced the JKI State Machine, JKI State Machine Objects, Command Line Build Tools for LabVIEW, and we’ve got plans to release a lot more projects very soon.

You can find out more information on our JKI Open Source Projects page here:

http://jki.net/open-source

 

 

Posted in Company News | Tagged , , , , , | Leave a comment

CLA Summit 2013 Europe: “Public Events for Modules” Video & Slides Now Available

I had the pleasure of being invited to speak at the CLA Summit Europe 2013, at NI France in Nanterre (just outside Paris).  This was a fantastic event and it was a lot of fun to meet CLAs from around the world (and especially Europe) and learn from them about this year’s theme: Interprocess Communication.  The food was also terrific — I’m just sayin’ :-)

My talk, titled “Public Events for Modules,” was about a technique for Interprocess Communication in LabVIEW using Dynamic User Events as a core aspect of one’s software “modules” (classes, libraries, components, or whatever modular programming style you’re using in your LabVIEW applications).

In addition to showing how to expose Dynamic User Events for your modules, I showed some of the ease-of-use benefit this technique offers to both developers and users of software modules.  I also show some of the caveats and gotchas of this approach.

This was a really fun talk to give and I hope you enjoy it!

Here’s the video of the presentation:

 

Download the presentation slides here:

2015-02-24_13-06-58

Posted in Events, LabVIEW | Tagged , , , , , | Leave a comment

#4 Best Practice for using the JKI State Machine: Use macros instead of “chaining” together sequential states

In my last post on JKI State Machine Best Practices, I explained the #3 Best Practice: Keep the Original Size (i.e. don’t grow the structures).  In this post, I’ll tell you which best practice came in fourth place.

The #4 Best Practice: Use macros instead of “chaining” together sequential states

Here’s what we mean:

A “Macro” is a state that simply builds up a list of other states; calling the macro is like calling all the other states in the list.

2015-02-13_10-58-17

Note: There’s no actual work done in a “Macro” frame/state of the Case Structure. We simply add a sequence of states to the front of the queue.

Example of Good Practice: Using a Macro to Invoke Three States

Here’s an example of a macro that calls three states, sequentially:

2015-02-13_11-14-06

Macros make it easy to understand the flow of the code; it’s obvious that a call to a macro will execute a sequence of states, and it’s easy to see what that sequence of states will be.

Example of Bad Practice: Chaining Together States

Here is an example of “chaining” together states to create a sequence, where each state in the sequence call the subsequent state:

2015-02-13_11-06-38

This is much less desirable than a macro, because:

a) It’s not obvious that a call to a state my result in a call to the chained state — In the above example, it may not be obvious that a call to “State 1″ will result in a call to “State 2″ and then a call to “State 3″

2015-02-13_11-25-47

 

b) It is much more difficult to reuse states/code in other sequential operations, because each state in the chained sequence is tightly coupled to the sequence. For example, it is impossible to call “State 2″ in the above example without it invoking “State 3″.

It’s hopefully clear, now, why macros are so useful and why chaining states may get us into trouble.

Looking ahead, there may be cases where you need to build up a macro dynamically/conditionally, depending on the state of system. And, you might not have that information at the time when you construct the macro. In these cases, there are some special techniques we can use that we’ll talk about that in a future blog post. Stay tuned!

We’d like to hear about your best practices for using the JKI State Machine. Please post comments and suggestions, below.  And, if you have ideas for making the JKI State Machine better, please post them to our Idea Exchange.

And a note from our sponsor: At JKI we use the JKI State Machine every day to help our our clients get their innovative high-tech products and technology to market fast. If you need help taking your system software to the next level or reach an important milestone, contact us to learn more about our services.

Posted in JKI State Machine, LabVIEW | Tagged , , , , | 4 Comments

#3 Best Practice for using the JKI State Machine: Keep the Original Size (i.e. don’t grow the structures)

In my last post on JKI State Machine Best Practices, I explained the #2 Best Practice: Don’t add code and logic inside the Event Structure.  In this post, I’ll tell you which best practice came in third place.

The #3 Best Practice: Keep the Original Size (i.e. don’t grow the structures)

2015-02-11_12-58-33

Here’s what we mean:

The size of the JKI State Machine was carefully designed to fit on one “reasonably sized” VI Block Diagram.  The LabVIEW Style Block Diagram Checklist tells us:

“Avoid creating extremely large block diagrams. […] The size of the block diagram window can affect how readable LabVIEW code is to others. Make the block diagram window no larger than the screen size.”

Of course, as monitors have grown in size (I’m looking at you, Thunderbolt Display!) block diagrams have gotten larger.

2015-02-11_13-21-10

Still, you’ll want to exercise caution and avoid growing the size of the JKI State Machine, since limiting its size encourages the use of SubVIs and modularizing your code (and that’s a good thing), as we’ll discuss below.  There are a couple ways to achieve this…

First and foremost, keep the JKI State Machine size from growing by doing the following: 

  • Avoid using CTRL-drag to insert space into a LabVIEW diagram.
  • Leave the “Auto Grow” setting turned OFF for all the structures inside the JKI State Machine (it’s While Loop, Case Structure, and Event Structure)

2015-02-11_13-07-07

Second, as your application logic and code naturally grow in size complexity, you can modularizing your code (i.e. don’t try to do everything in the block diagram of one frame) by doing the following:

  • Move code into subVIs (we’ll have a blog post in the future on how your JKI State Machine application architecture evolves over time, so stay tuned for that)
  • Create add’l state frames of your state machine and organize them into related sections (as shown below — we’ll talk more about that in a future blog article, too).

2015-02-11_13-05-38

Keep in mind, once you grow the size of your JKI State Machine, it’s nearly impossible to shrink its size again (but, there are a couple of cool LabVIEW idea exchange posts about how this might be possible in the future).

We’d like to hear about your best practices for using the JKI State Machine. Please post comments and suggestions, below.  And, if you have ideas for making the JKI State Machine better, please post them to our Idea Exchange.

And a note from our sponsor: At JKI we use the JKI State Machine every day to help our our clients get their innovative high-tech products and technology to market fast. If you need help taking your system software to the next level or reach an important milestone, contact us to learn more about our services.

Posted in JKI State Machine, LabVIEW | Tagged , , , , | 3 Comments

Bay Area LabVIEW User Group (Feb 10, 2015) – Come learn about JKI State Machine Objects

If you’re in the Bay Area, come to the NI offices this evening, Feb 10, 2015, for a LabVIEW User Group presentation on JKI State Machine Objects, an easy and scalable way to manage and reuse multiple JKI State Machines in your LabVIEW Projects.

2015-02-10_12-59-11

These are the same software architecture and tools used by engineers at JKI on our projects, and we hope they can help you create even better LabVIEW code for your projects.

2015-02-10_13-01-41

We hope you can make it. If you can’t, don’t worry, because we’ll be posting and talking a lot more about this exciting new tool for LabVIEW developers.

>> Click here to register for the meeting <<

Time and Location
02/10/2015 | 05:45 p.m. – 08:45 p.m.
National Instruments – Santa Clara
103 – Sales Training Room
4600 Patrick Henry Dr
Santa Clara, CA 95054

 

 

 

Posted in Bay Area LabVIEW User Group, Community, Events, JKI State Machine, LabVIEW | Tagged , , , , , , , | Leave a comment

#2 Best Practice for using the JKI State Machine: Don’t add code and logic inside the Event Structure

In my last post on JKI State Machine Best Practices, I explained the #1 Best Practice: Don’t hide your state strings in subVIs.  In this post, I’ll tell you which best practice came in second place.

The #2 Best Practice: Put code and logic inside the Case Structure. (Don’t add code and logic inside the Event Structure.)

Here’s what we mean:

Good Practice: (a) The Event Structure enqueues a state string and (b) the Case Structure frame does the work.

(a) In the Event Structure, handle User Interface events by simply adding a state to the queue to do the actual work (i.e. don’t do any actual work inside the Event Structure).

2015-02-02_13-30-20

(b) In the Case Structure, put your code that does the actual work.

2015-02-02_13-29-17

Bad Practice: Event Structure does all the work

The “bad” way to do this is to put all the work inside the Event Structure, as shown below:

2015-02-02_13-34-28

Why? The Reasoning Behind this Best Practice

The reason we want to put code in the Case Structure and not the Event Structure is because, (1) it’s hard to reuse the code and (2) it locks up the user interface.

Said in a slightly different way:

1) Code inside the Case Structure is easy to reuse, since you can simply invoke that state of the state machine — that’s how the JKI State Machine is designed to work. Conversely, it’s very hard to reuse the code inside an event structure — you’d have to call the Value (Signaling) property to fire the event that the frame is handling.  This is a generally frowned upon practice, since it’s very hard to read and debug the code (you don’t know if a UI event was generated by the user or programmatically by the code).

2) Code executing inside the Case Structure does not lock up the user interface (UI). Conversely, code executing inside the Event Structure locks up the UI and therefore slows down the responsiveness of the UI (as perceived by end users of the software). In some cases, it can even lock up the UI so badly that it may seem to the user that the software has crashed!

Bottom line: you should, in general, only use the Event Structure frames for catching Front Panel and Dynamic Events. Put your functional code inside the Case Structure and call those states from the Event Structure by adding a state string into the queue.

Note that it’s OK to do some conditional/state checking logic inside the Event Structure to make decisions about which states to add).

2015-02-02_13-45-10

That’s all there is to it. Just remember: Don’t add code and logic inside the Event Structure. Do put code and logic inside the Case Structure.

We’d like to hear about your best practices for using the JKI State Machine. Please post comments and suggestions, below.  And, if you have ideas for making the JKI State Machine better, please post them to our Idea Exchange.

And a note from our sponsor: At JKI we use the JKI State Machine every day to help our our clients get their innovative high-tech products and technology to market fast. If you need help taking your system software to the next level or reach an important milestone, contact us to learn more about our services.

Posted in JKI State Machine, LabVIEW | Tagged , , , , | 1 Comment

#1 Best Practice for using the JKI State Machine: Don’t hide your state strings in subVIs.

At a recent JKI Team “LabVIEW Lunch” (where the team gets together to eat and talk shop), we were discussing JKI State Machine Best Practices. Note: the JKI State Machine, an easy-to-use yet powerful state machine template we created to help LabVIEW developers write code faster.

After some brainstorming and discussion we took a vote on what was the most important best practice to follow.  It was unanimous…

The #1 Best Practice: Don’t hide your state strings in SubVIs — keep them on the block diagram of the JKI State Machine.

Here are a couple screenshots to show what we mean:

Good Practice: Keeping the state string on the block diagram.

2014-05-14_13-36-04

Bad Practice: Putting the state string into a subVI

2014-05-14_13-36-20

By keeping the state strings on the block diagram of the JKI State Machine (rather than buried deep inside subVIs) we gain a couple key benefits:

Benefit #1) The readability of your code improves — you don’t have to navigate into subVIs to figure out the logical flow of the JKI State Machine.  This allows you to code more quickly, which is one of the key goals of the JKI State Machine.  Putting code into subVIs just slows down code readability and maintenance.

Benefit #2) You can use LabVIEW’s built-in “Find” dialog — you can search for instances of a specific state string on the block diagram of the VI containing the JKI State Machine.

For example, open the Find dialog by selecting <Ctrl+F> and search for a state string like “UI: Initialize”.  Be sure to set the Search Scope to the VI containing the JKI State Machine.

2014-05-14_13-45-48

Clicking “Find” will then locate all instances of “UI: Initialize” in the block diagram of your VI.

2014-05-14_13-47-53

This ability to Find (and Replace) the state strings in your VI’s block diagram is a hugely powerful tool and it doesn’t work nearly as well if you start putting your state strings into subVIs.

Benefit #3) The coupling is loosened between the state transition logic and the rest of the application code — the JKI State Machine logic/flow stays loosely coupled from all the other code/VIs in the software. This means that changes to one VI don’t inadvertently change the functionality of code in other place.

Bottom line: Take advantage of these great benefits to keeping your state strings on the block diagram of the JKI State Machine (and please, don’t hide your state strings in subVIs) :)

We’d like to hear about your best practices for using the JKI State Machine. Please post comments and suggestions, below.  And, if you have ideas for making the JKI State Machine better, please post them to our Idea Exchange.

And a note from our sponsor: At JKI we use the JKI State Machine every day to help our our clients get their innovative high-tech products and technology to market fast. If you need help taking your system software to the next level or reach an important milestone, contact us to learn more about our services.

Posted in JKI State Machine, LabVIEW | Tagged , , , , | Leave a comment

JKI State Machine Best Practices

At a recent JKI Team “LabVIEW Lunch” (where the team gets together to eat and talk shop), we were discussing best practices for using the JKI State Machine, an easy-to-use yet powerful state machine template we created to help LabVIEW developers write code faster (and can even help you pass the Certified LabVIEW Developer exam).

2014-05-13_18-28-23

As a result of this meeting, we had a lot of great ideas and we decided that we would publish some of them for your feedback and to share them with others in the community.

Here is a list of JKI State Machine Best Practices:
(I’ll be updating this list as new articles come out)

  1. Don’t hide your state strings in subVIs
  2. Don’t add code and logic inside the Event Structure
  3. Keep the Original Size (i.e. don’t grow the structures)
  4. Use macros instead of “chaining” together sequential states

We’d like to hear about your best practices for using the JKI State Machine. Please post comments and suggestions, below.  And, if you have ideas for making the JKI State Machine better, please post them to our Idea Exchange.

And a note from our sponsor: At JKI we use the JKI State Machine every day to help our our clients get their innovative high-tech products and technology to market fast. If you need help taking your system software to the next level or reach an important milestone, contact us to learn more about our services.

Posted in JKI State Machine, LabVIEW | Tagged , , , , | Leave a comment

Happy Holidays from JKI!

Happy Holidays 2014

To our Friends and Partners,

Best wishes for a happy holiday season

and a wonderful new year.

From all of us at JKI

Posted in Company News | Tagged , , | Leave a comment

New LabVIEW Tool: LV 2009-2013 Icon Version Overlay

I wanted to share a new package I create that adds a four digit year overlay (e.g. the text “2009” in orange font) to the LabVIEW EXE program icon (similar to LabVIEW 2014 icon), as shown below

2014-12-12_09-50-54

You can >> download and install the package here <<

Now, for those interested, here’s a little bit of the backstory on this useful tool…

A while back, the great @dnatt posted an excellent idea for a new LabVIEW feature — adding a version number to the LabVIEW icon so it’s easy to tell them apart when they are on your Windows taskbar. Since that was a such a wonderful idea, this feature was added to LabVIEW 2014 (thanks, NI!).

loc_env_new_system_tray_icons

But, what about older versions of LabVIEW? How do you tell those apart?

In response to this need, several people posted customized icons for various versions of LabVIEW. This now made it possible to tell all of these older versions apart.

You can tell which version you’re launching from the Windows taskbar (as shown at the top of this post).

And, you can see on the icon in the Window Titlebar which version of LabVIEW a given VI is open in (since sometimes when you double-click a *.vi file it opens in the “wrong” version of LabVIEW and you don’t realize it — that’s painful especially if you save it in a newer version!).

2014-12-12_09-43-25

In closing, I’d like to give some special thanks, not only to @dnatt, but to everyone who posted the icon files that I used in this package: blawson, John.P, Bob_Schor, asbo, David_L, and others. The LabVIEW community is truly a great thing — I can’t take credit for the idea or the great icons. I only packaged them up so they would be easy for everyone to find and use :-)

I hope you find this tool useful in your LabVIEW programming! If you have any issues, let me know @jimkring.

Posted in LabVIEW | Tagged , , , , , | Leave a comment