LV Executable

[becktho]

Hi all

I just read a thread in the LV board, where one tried to convert a LV7.1 vi to LV6.0. The vi was developed under LV7.1 whereas on the target machine LV6.0 is running. This led me to the question "why does this guy not work with executables?".

This is the only way to go. Each testrig I had to write a program for, is controlled by an exe. No LV development environment. Just drivers, LV runtime and the simple exe. No need to ask "how can I remove the run-button" or "how can I avoid the user accessing the block diagram".

So  here is my question to you: What is your final product? A lot of simple vis or an executable? If it is not an executable - why not?

I'm very looking forward to reading some very interesting answers ;).

Thomas

[TiTou]

Hi Thomas,

---

becktho a écrit:

This is the only way to go. Each testrig I had to write a program for, is controlled by an exe. No LV development environment. Just drivers, LV runtime and the simple exe. No need to ask "how can I remove the run-button" or "how can I avoid the user accessing the block diagram".

---

I agree with that and any application I develop for a customer will be an exe, that's a rule in the company I'm working for and I wouldn't change it ; but here is the point... "who will use the application ?"

For "limited test application", I mean code that is not meant to be part of a customer application but code to "clear" feasibility doubts don't need to be exe of course because they have to be easy to modify quickly.

Talking about code to make a demo for a customer... well it depends on what we want to sell to the customer. Sometimes we want to show an exe so that the soft appears "like a real soft" and sometimes we want to demonstrates how easy it is to maintain/rescale/modify the code, so just VIs.

😉

Message Edité par TiTou le 03-31-2006 07:42 AM

[AnalogKid2DigitalMan]

All coding I do is for internal company use in Production or Engineering.

100% exe's. I may run under the development environment while working the bugs out when code is delivered to the floor, but that is only temporary.

Personally, I can't envision leaving 'exposed' code and the LV IDE out on the production floor, that is asking for disaster (operator error, unintended edits or changes, hacks...)

[jasonhill]

For the most part, I am my own customer.  Nearly all of my code is written for my own use in the test lab.  Therefore, it is exclusively used as .vis instead of .exes.  The joys of working for a small company.  Do it yourself, or it don't get done.

[tbob]

Our company policy is to issue software to the production floor in the form of LLBs made with all block diagrams removed.  The vi's are then called by a TestStand like hombrewed sequencer.  Therefore no one can change anything.  For modifications, the developer changes the original vi's and has to build into a new LLB with block diagrams removed.  Actually, we have build tools that make a cab file, and the cab file is extracted into an LLB and supporting files.

Why this method, I don't know.  This was dictated long before I got here.  I like the exe idea better.  In fact, I recently developed a tool to report test set configuration and I made it into an exe.  I didn't have to follow the policy because it is not being used to test product.  The exe is easier to deploy.

[Albert.Geven]

Hi

We are working with a team of four people to support about 200..300 researchers (out of 1000). We decided always to give the source code with the software, so that the researchers were able to modify and adapt the programs. If we had to do all changes ourselves it would have taken more then 20 people doing the programming.
When big changes are needed or the mess gets too big we help or write a new starting point.

This makes it possible to have fast changes and we learn a lot of how bad programs can get. That also is the reason that we beleive in software tools that help to structure the program, not only in LabVIEW but also on disk and therfor we hope to see a real program manager in lv8.

The basic problem in research is that you try to find something that requires changing the measurement tool when you see the first measurements.
For repetitive measurement on a production floor or a standard system we also use runtimes but not much during the research phase.

I hope I did not make you too jealous.

By the way it's raining again....

Greetings from a wet country

[Joe_H]

For me it depends on where it is going. If it is staying here in the Lab were I have control then I only use *.Vi's but if it is going to the production floor then it is most certainly an .exe. It is just more simple for me to manage that way. Sometimes and in rare cases it is both because I use the exe to call the vi's in an llb doing it this way makes it easy to update the code with improvements. Just my 2 cents.

[cs42]

We're using exes only in the lab as well. Other way it wouldn't be feasible, because we have currently about 10 laboratory computers controlling test rigs and/or smaller tests. To buy development packages for all these would be complete overhaul. Most of the tests are running or used for a longer time anyway. And as many control structures are similar we can reuse much of the code. Logging is done by DSC Tag Engine, so you only have to setup a database and don't have to program anything to write you data.

So we have now one development pc in the lab. Testing some software can be done there using the development environment but the real test shouldn't be run from there. Additionally our main LV developers have LV at their desk.

I couldn't imagine keeping all the test pcs up to date with installed development environments anyway... (there's even no office installed there)

Cheers,
    Carsten