egraham

That's a good catch. I never use this function for millisecond accuracy, but it's drifting by about a millisecond every time it elapses.

I don't get a carriage return when I run that in LV2014.

At JKI we have a tool we use internally to do this, but I haven't looked at the code under the hood and can't confirm it works cross plat form. It does work correctly on Windows, though.

I didn't read this discussion closely enough to see if you were already part of it, but if you haven't read it, I think it touches on your problem. Steven Mercer talks about the differences in typedef behavior between different LabVIEW versions and says 2014 vastly improves upon this. https://decibel.ni.com/content/thread/20339

Wilfried, I just saw this post. To answer the question you asked on the NI forums, yes, it's the same guy answering your Reach questions over there.

A while back I was using DashCommand in my car with pretty good results. The updates were about 1-2 times per second. I wanted to see smoother updates on things like RPM. I used it a few times to read diagnostics codes and reset my engine check light. Also, my car didin't display gas mileage so I would use it on longer trips to see what type of gas mileage I was getting at any given point in time. Linking to the bluetooth ODB2 transmitter was kind of a PIA because it took about 10-20 seconds to get it set up so it's not the kind of thing I would use around town or on shorter trips. Around town it seemed like it was another thing that could distract me and take my eyes off the road. California is really starting to crack down on smart phone usage in cars these days.

The difference is that you now have a way to have multiple processes (state machines) running simultaneously and communicating with each other. In that example, events are the communication mechanism.

JKI has a presentation on how to do this using their state machine and user events. It's a convenient and simple way to expand on an already very useful architecture. You'll find the JKI state machine gets used a lot in the LabVIEW community. Check it out here: http://blog.jki.net/events/niweek-2011-beyond-state-machines-slides-and-code-now-available/

I should post this for anyone's future reference who happens to be doing a search. There is an example provided by REACH that I had overlooked. They call it ikb and it's one of the demos. It's a more complete keyboard, but is stil lacking as there are some undesirable visual artifacts on some of the bitmap images used. I had to modify some of the macros to make it useable for my application, but a lot of the functionality was already there in the example macro so it definitely saved me some work.

Thanks to both of you for pointing out these keyboard options. Unfortunately the REACH touch screens rely on bitmap images that have to be uploaded via serial or using an SD card. They can't actually display LabVIEW front panels. At this point it's looking like I will have to create my own.

For those of you out there that have experience with the REACH touch panels, has anyone created a complete keyboard yet? The examples provided by REACH are limited in that they are only letters or numbers and lack a lot of the additional characters that make up a complete keyboard. If anyone has done this work already and wants to share it, let me know! Thanks, Eric

Karol, Are you wanting to open the subVI front panel if it's already running? If so, you need to use the reference to the subVI to check its state so that you don't try to start it asynchronously if you've already started it. Rather, you would just open the front panel of an already running VI. When you use the stop button on the subVI you can start it again from your main VI, but closing the front panel of the subVI leaves it running... so you can't start it again since it's already running. You can override the panel close of the subVI using an event structure (see attached). Or you can leave it running if that's the desired behavior and just open the front panel. Like I said, you have to check its state before you decide if it needs to be started or if you just need to open it's front panel. Regards, Eric

This should be one of the more interesting sessions at NI Week. I'll definitely plan on being there! Thanks JKI for always putting such great material together.

I've realized there are a few caveats to keep in mind when looking at optimizing array manipulation functions. 1. Optimization of code for one data type does not necessarily affect other data types the same way. 2. The type of computer/processor can have a HUGE affect on how effective your optimized code performs. 3. There are likely significant differences in the code performance between different versions of LabVIEW. Do some benchmark tests with different data types, different methods of processing your arrays, on different types of processors. I was astounded at the differences and realized there's a lot of low level processing going on behind the scenes that I would need to understand to know why performance differences existed between the different scenarios.