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.

That's brilliant! Congratulations Jack!

I'm not a hater, but saw this sticker over at the Evil Mad Science storefront and thought it was pretty funny. If anyone hated LV enough it definitely wouldn't be worth spending the time to make a post about - instead they would just stop using it. Some of us are always looking for something to complain about when we don't have enough other things to keep us busy.

http://evilmadscience.com/directory

How much data are you wanting to write real time?

TDMS might be the way to go.

I can't downconvert to 7. Here's a screenshot of what I did.

chrichter,

Attached there is a VI that makes the tanks run backwards with both in a While loop instead of a For loop. There is lots to study up on in terms of events, state machines, etc.

This looks like a cool program. You are well on your way. Keep tinkering and making programs. That's the best way to learn. Hopefully you can convince your company LV is a tool they need.

There is a lot to point out, but one thing I'll say right now is that property nodes that only need to change a property once can be placed outside of your main loop. That way they only happen at startup. You can use your error wires to make sure they happen before entering the main loop.

Another thing I'll say is that in you'll find For loops are most often used to perfrom repetitive iterations on arrays of data. It's not that they don't have other uses, but that's where you'll see them most commonly used.

Application design is something that takes a lot of studying and understanding of most of the basic LV structures. I think all of us are always trying to become better at this. Read the message boards and get your hands on some of the more advanced LV programming books to help understand these things.

Regards,

Eric

supply collect resized 5.1-edit1.vi

This sounds like a good project to learn about image acquisition.

Christopher Relf (http://lavag.org/user/181-crelf/) has written a book about this subject. I'm sure he would appreciate a plug for his book. It's probably one of many places you could start.

http://www.amazon.com/Image-Acquisition-Processing-LabVIEW/dp/0849314801/ref=sr_1_1?ie=UTF8&s=books&qid=1302458393&sr=8-1

http://zone.ni.com/devzone/cda/tut/p/id/2808

Eric

Ian,

I'm not sure if you're still working on this, but it sounds like what you're tring to do is allow the user to configure the setup of the channels to acquire. This should be simple enough using the DAQmx functions like create task, creat channel, etc.

This could be done in a VI at application startup before the main application loads. The output from that VI could be a cluster containing the data for your channel configuration. Is that what you're going for?

The information could be updated easily enough during the middle of a test, but the application would continue to acquire data from all originally configured channels until you stopped the loop in charge of data acquisition and restarted it so it loads the new channel configuration. If the loop needed to continue to run and acquire data you could just wait until the next application startup to remove the unecessary channels or implement a reload button. If it's just a matter of hiding information in the middle of a test, hiding indicators is simple to implement with property nodes.

Eric

Wow, I remember that hardware from LV 3.1 days...

Ha ha! I thought vintage was in these days...

Neville,

Thanks for your insight/ideas. Splitting the tasks seems like a good idea. The application works, that's the important thing. For my own education I was wondering if there was a really convenient way to make the hardware scan channels differently. At this point it seems like I know all the options I have to work with.

Eric

I know there will be many points, may be bugs in my program. Also let me know how I can avoid using local variables and still update "Wash Options" control.

I have two local variables. How bad effect it will have on scoring ?

Gaurav,

I'm not sure a couple of local variables would hurt your score all that much. If you really wanted to avoid using those you could make sure you've set the default values for all controls in the entry console, then create an invoke node for your cluster to reinit all to default values.

I think it's not a bad idea to have separate folders for your controls and subVIs as illustrated in the sample exam solutions.

You could consider using a typdef enum for your case selection. It might be faster to code than using strings, but I don't know that they would take away points for this.

I didn't check functionality/bugs, but at first glance it looks pretty clean and well documented.

Good luck!

Eric

How about setting up the channels that don't need to be scanned multiple times in one task and the other channels in separate tasks?

That's one idea. However, I'm still starting and stopping tasks to accomplish this.

I'm using an old SCXI system for all analog measurements - thermocouples, 4-wire RTDs, current inputs. I average measured samples to increase accuracy, especially on the 4-wire RTDs. The RTDs happen to be connected to a mechanically multiplexed module. The NI manual suggests scanning multiple samples from one channel before switching to the next channel to avoid wearing out the mechanical multiplexer. The channel switching is actually audible. Imagine switching a mechanical multiplexer 100 times/second - it would wear out quickly.

I've seen this recommended scanning method mentioned multiple times in NI documentation, but there doesn't seem to be any obvious and convenient way to implement it using channels configured in MAX without starting/stopping tasks. I'm just hoping I'm missing something.

Maybe this is further incentive to stop using MAX...

I saved the edited version in 8.5 and attached.

A queued state machine could work for what you're doing, but might be more than you want to look into right now.

If you're really going to use the timeout event like that, at least wire a number other than zero to it. That prevents it from eating up as much CPU by limiting how often it executes. Keep in mind that making your application work this way is something you should consider changing in the future as it's not considered best practice.

I added a clear button and a corresponding event case that writes zeros to all your indicators.

After a loop executes data is written to the shift register on the right side of a loop then that data becomes available on the next loop iteration on the left side of the loop. Spend a little bit of time learning about shift registers. I attached an example to show you what happens with shift registers. Watch numeric2 and see how it contains data from the previous loop iteration.

State machine description

http://zone.ni.com/devzone/cda/tut/p/id/3024

If you want to see some state machines implemented in examples, the CLD sample exams are a good resource for that.

https://lumen.ni.com/nicif/us/ekitcldexmprp/content.xhtml

rajnew-edit1 8.5.zip

shift register example.vi