Using the JKI State Machine to Interface LabVIEW FPGA Webinar

Recording of a webinar with Javier Ruiz

In this hands-on demo, Javier Ruiz, a Certified LabVIEW Embedded Systems Developer (CLED) and JKI Senior Project Engineer, will show you how to create real-time and desktop applications with the JKI State Machine for LabVIEW to interface with LabVIEW FPGA for high-speed measurement and control.

Watch this webinar to learn:

  • How to create a basic LabVIEW FPGA application
  • How to read and write signals using the FPGA
  • How to communicate between real-time and FPGA applications
  • How to interface to the FPGA directly from a remote computer
  • How to transfer high-speed measurement data using DMA

Using The JKI State Machine To Interface LabVIEW FPGA Webinar
Duration: 45 minutes

Level: Basic / Intermediate

Watch Now!

 

Posted in LabVIEW | Tagged , , | Leave a comment

Announcing the New “Magic Delay Fairy” Tool for LabVIEW

JKI is pleased to announce the release of the new Magic Delay Fairy Tool for LabVIEW,  a revolutionary new tool for LabVIEW developers working to solve some of the toughest system timing and synchronization challenges.

Here’s how this tool can help…

Some Bugs Need Fairy Power

Let’s say you have a bug in your code shows up as an intermittent problem. Often times, adding a perfectly timed delay into your code can cause the problem to go away… almost like magic.

.                                           DelayMagic Delay Fairy

For example, say you’re configuring an instrument’s voltage range (sending the “CONF:VOLT:RANG 0,10″ command)  and then querying a measurement (sending “MEAS:VOLT?”). Sometimes the voltage is out of range and sometimes it’s not — the instrument gives you a beep, letting you know it’s not happy. In this situation, inserting a “magic” delay between your configuration and measurement steps might help.

Here’s a video that shows what we mean…

Before Magic Delay: Code is not working! :(

Before Magic Delays

After Magic Delays: Code is “working”! :)

Magic Delay After

How does this tool work?

The Magic Delay Fairy fixes race conditions in your code by inserting magical delays into your code that are specifically tuned using advanced magical algorithms to fix your race conditions. Don’t ask how it works, because it’s magic.

Warning! You may be so excited by this great tool, you may want to prance and frolic.

norm_delay_fairy_small

Act Now! Download and Install the JKI Magic Delay Fairy Today!

Download and Install the JKI Magic Delay Fairy using VIPM.

Downloadjki_magic_delay_fairy-1.0.0.11.vip

Special Thanks

Norm Kirchner for doing the magic fairy dance
– The guy whose face is on Norm’s presentation about the Magic Delay Fairy (we’ll update this description later)
Gavin Burnell for awesome Scripting Tools.
–  Brian Hoover and Yair on LAVA for help getting screen coordinates of GObject on Block Diagram
Darren Nattinger for making QuickDrop awesomeness
– OpenG for the Wait (ms) VI with error handling :)
– Everyone at JKI who contributed to this tool

Join The Discussion

What will you do with the JKI Magic Delay Fairy?  Will it save your project?  Your job?  Your life? Tell us in the comments below!

Posted in Company News | Tagged , , , | 2 Comments

JKI State Machine 3.0 Released (Open Source)

We are happy to announce that JKI State Machine v3.0 has been released as a JKI Open Source Project (BSD license) and is available for download using VIPM.

JKI State Machine

Additionally, we’ve upgraded the sources to LabVIEW 2013 and made a few minor cosmetic tweaks:

– Built in LabVIEW 2013
– Added “Event Structure” to the “Idle?” (“”) Case Structure frame
– Cleaned up floating labels used for documentation

This is a minor release, in terms of new features, but major in terms of it being the first release as an open source project. We hope this proves to make a big difference to the LabVIEW community. If you have questions or comments, please post in our discussion forums.

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

At JKI, we are on a mission…

At JKI, our team has spent a great deal of time over the years thinking about what it is we do, for whom, and why. Now, I’m proud to publicly announce JKI’s official mission statement!

JKI_Mission

Our mission has, naturally, permeated all of our work and resulted in a lot of happy customers who call us back over many years. This mission has also resulted in many significant technical contributions to both the high-tech industry and the state-of-the-art in LabVIEW.

More about our mission

JKI is located in the San Francisco Bay Area and serves start-ups and advanced R&D groups within high-tech companies in Silicon Valley and beyond. Fast-moving technology companies hire JKI to help them get their innovative products and technology developed quickly. LabVIEW and the NI Platform are tools we use extensively to help make this possible. Additionally, we employ software engineering best practices and tools in our work with LabVIEW, such as object-oriented frameworks and architectures, fully-automated software unit testing and executable builds (continuous integration), source code control, issue trackers, and Agile development processes.

These tools and techniques enable rapid development; the ability to iterate and change the software quickly as the requirements change. This helps JKI’s customers to continue to innovate and evolve (or even pivot) their product throughout the R&D process.

Are you building a next generation system or high-tech product?

If you’re in need of a team to help you build a next generation instrumentation system or product, give us a call — we’d love to chat with you about your project.

Want to join a great team and use LabVIEW on exciting projects?

And, if you’re a passionate engineer who loves LabVIEW, likes working with an amazing team, and wants to help high-tech companies create innovative products powered by LabVIEW, check out our careers page.

Join Our Team

Posted in Company News | Tagged | 1 Comment

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 , , , , | 5 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