Wire Warrior

We bought ours from CyberResearch and had good results, however, that was several years ago. Jason

If you add the files to your project then you have have the installer place them on the target computer no problem. As for creating directories, I am not sure how to do that if they are empty. New directories with files are auotmatically created by the installer. jason

That's awesome! Not were does one get the funding to build such wonderful toys???? Jason

Configure the 1st loop as a state machine and create a "pause" state for the state machine that automatically calls itself. Use a queue or other messaging structure to pass the pause command from the processing loop to the acq. loop. That would be one way. Jason

You can double click the package file which will open the VIPM automatically also. And asking the basic question, you are aware that VIPM is a different program that you have to install separate from LabVIEW? Jason

is there a Droid app yet?

Have you contacted NI? They might be able to overnight you one.... Jason

Whoo-Hooo! My NI Week is confirmed. :beer_mug::beer_mug::beer_mug: After years of trying I finally get to go. Jason

Yes it is true for all controls. Of course some require processing that others. The important component when overlaying is the rate of update. How often do your graphs update? Once a data run would likely not be a noticeable issue. At 1000 Hz it maybe an issue. Probably the best thing to do would be to test your system as early in the build as you can and measure the performance time. Jason

NI talks about this particular issue in the LabVIEW Performance class. When you overlay controls, the LabVIEW execution engine must "redraw" ALL overlaid controls every time either of the controls are updated. It the situation you mentioned I would suspect one or both of the overlaid controls were updated frequently. If so, then the Google Earth ActiveX would be executed at the same frequency. I can see where that might chew up some serious processor cycles. If you could move those controls to a different area of the UI, you would likely see an improvement in the performance. Jason

Now those were amusing. Jason

That's a broad question and the answer really depends on how your interface to the chip is configured, what the supporting circuitry looks like, etc.? It's hard to assist you with out more info about your setup.... Jason

The DETT will allow you insight into the memory behavior of your program. Among other peices of information you can see every memory allocation call made by the program. The DETT also allows the inclusion of custom user events that can assist isolation of the program. You can also use VI Profiler (located in the Tools Menu under the Profile >> Performance and Memory option) in the development environment that can assist in tracking down a memory leak one a per VI basis. Jason

You might try looking at the examples that shipped with LabVIEW.

Congratulations!

Excellent yet another peice of code to taunt the text based programmers at the office with! Jason

I feel better now. I'm not the only one who wondered about the logo. I won't say I lay awake at night. It's usually more of a drive time commute thought process at the end of the day. Jason

Remember, chicks dig giant robots. Jason

Hmmm...The menu suggestion makes me wonder. Does the menu have to be shown on the front panel to generate events using hot keys? My gut feel is yes but I really don't know. Jason

Congratulations to all three of you! And welcome to your son. Jason

It sounds like what you want to do is create a source code distribution. There are options in the build specification for including information in the user.lib and vi.lib. This article on NI's Developer Zone might help you Distributing Applications with the LabVIEW Application Builder. Hope this helps. Jason

Well, to start with your going to need some type of analog input/digital output hardware as part of your system. I would imagine the best place to start is with some of the examples which ship with LabVIEW. If you look under the Help tab on the menu, you will see the "Find Examples..." option. This will bring up a dialog that will allow you to look at a variety of solutions to some of the basic problems. You would probably find lots of help looking at the Digital Output examples and the Analog Input examples. Jason

I have solved the problem I think (at least as far as testing to this point has revealed). After I added in the ability to log the states passed to the QDSM's, I was able to determine that the program was "crashing" after I dynamically closed the front panel of the launcher. My program was designed to close the front panel of the launcher then pop-up the front panel of the main UI. My EXE is built on to contain the launcher with my other QDSM files being maintained externally in specific directories. What appeared to be happening is that when the launcher closed its front panel and before the UI opened up the run-time engine would decide since there were no windows open it would close itself down. This is my supposition about what may be happening any way. I modified my code to changed the launcher window to hidden and delay for 1/2 a second to give the main UI a chance to start fully running. This fixed the problem, or at least worked around it. If someone out there can explain to me exactly what is happening I sure would appreciate it. Thanks for all the help those of you who responded. Your advice was very beneficial and certainly led me to a resolution faster. Jason

Thanks for the suggestion...I downloaded the f2 patch and recompiled yesterday. Didn't help the problem. Jason Thanks for the suggestion, I have some error logging in place but having the state machines log behavior I had not thought of. Jason