Grumpy Old Men

[ErnieH]

Looks like a good place to hide my rant. Not starting a flame, just griping.

BEGINNING of RANT

A manufacturing engineer comes to me. Wants a minor tweak to a problem with a program that was developed a few years ago under LabVIEW 8.2. Simple change.

 Here is the way is should work.

-       I make a change.

-       Compile it as the same version it was released.

-       Put executable on machine. Problem solved. If I have an issue, just have them run the older version while I evaluate it.

-       Total time. 30 minutes or less (probably 10).

-       No shutdown of production.

-       Engineer happy with minor tweak that really does not do anything.

-       Might even get a beer out of it if I make it sound harder than it really is.

Here is a way it works now.

-       Move program to LabVIEW 20XX project. Currently using 2009.

• Could reload 8.2. Would have to unload 2009 and install them in order.

-       To change his app, I would have to reload his computer with all the latest drivers and run time engines. Production is down.

-       Be prepared to fix any new problems. Usually you can’t go back to the original program because of the updates. I would have to reload the previous drivers while I figure out the problems. Production is down.

-       Total time: a few hours to a few days if a bug is encountered in code that worked before the upgrade.

Summary

-       I need to keep the latest version because I use the real time and FPGA a lot. Some of the newer parts are not supported on previous versions. Plus, since this technology is newer, I get real improvements with a newer version on these systems.

-       Loading multiple versions on one PC is doable, but can be problematic, especially for older versions.

-       Loading DAQ drivers may support older version of LabVIEW, but may than exclude older versions of boards still used in production.

-       I don’t mind doing the yearly updates, but why should it make my life harder?

-       I look like an idiot for not being able to make a minor tweak in a reasonable time and with little effect on production.

-       I have already spent more time on it than I should have.

-       Basically, if we have something that works on the manufacturing floor (here, at remote sites, etc) we don’t want to make major changes to the drivers, runtimes, etc. What value does that add for me to update it?

-        I pay a yearly and dearly for this software, why does it have to make my life not only harder, but much harder the longer you use it? It makes it harder every year.

What do I want?

-       To easily be able to support current systems quickly and efficiently.

-       Not to jump through hoops every year when they release a new version of software. If I load a new version, don’t change my previous development system in any way.

-       The development system should serve the engineer, not the other way around.

-       How about a “compile for previous version’’ option.

-       My beer from the manufacturing engineer.

Questions:

-       Why does LabVIEW market itself as a product to increase productivity make my productivity less each year?

-       Why should I waste one minute upgrading a system that has worked for years to make a very minor tweak? The software should work for me, not me for it.

Other rants

-       What’s up with the marketing of SBRIO? What the heck are they thinking? Why can’t I just order it online like anything the rest of their products?

I ended up putting off the manufacturing engineer. I did not have time to deal with the above issues right now and the risk of downtime for something that would not improve the process. If it worked like the first scenario, I would have already been done before I wrote the first scenario.

It is pretty simple. Let me load and use versions independent of each other. Don’t update and “improve” my older development systems when I add a newer version. It should work and compile identically after the newer system is installed. That would make most of our lives easier and make my customers happier. That is the very least you can do for your customers.

END of Rant

[tst]

First, when you install a new version of LV, it doesn't touch the old versions. It is true that if you install a new version of a driver (VISA, DAQmx, FieldPoint) the old version of the driver is replaced, braking old LV versions which can't use the new driver. I have no idea whether creating a system which has multiple driver versions installed in parallel is possible.

Second, look into virtual machines. In my case, making a change to a program written in LV 7.0 (or 8.6) looks like this -

1. Run the relevant VM.
2. Open LV.
3. Make sure I have the updated version of the project.
4. Make the change.
5. Build the app.
6. Commit the changes to SCC.

Sounds awfully similar to the process you wanted to have, with the addition of the first step. VMs have their own set of headaches (and you're welcome to search here and on LAVA to see more), but this isn't one of them. Also, if you have any practical ideas, I suggest you post them to the idea exchange, so that they have a chance of being implemented.

[jcarmody]

---

@ErnieH wrote:

Looks like a good place to hide my rant. Not starting a flame, just griping.

BEGINNING of RANT

A manufacturing engineer comes to me. Wants a minor tweak to a problem with a program that was developed a few years ago under LabVIEW 8.2. Simple change.

 Here is the way is should work.

-       I make a change.

-       Compile it as the same version it was released.

[...]

---

This is where I left your line of reasoning.  Revision n goes to revision n+1 no matter how small of a change you make.

[Ben]

I started collecting machines, one for every version then started using multiple Boot partitions.

Now I just boot the version i need to work with adn no complications.

Ben

[ErnieH]

Of course I have to make a new revision. The point was, if I have to update the version on the target machine, it makes it much harder for me. I would:

1- Create a new version. Recompile it and load it and all the drivers onto the target machine.

2- Test it. If it does not work, go back to the old version. Sometimes I have to reinstall it because of the update.

3- Figure out the problem, or if there is not a problems, leave it there while I make the changes in a new revision.

4- Put this on the machine and test.

If the version does not change, I would save a couple of steps. Simply create a new revision, compile, load it and test it. If it does not work, it is much easier to go back to the working program. It saves time also because I do not have to focus so much on the program as a whole, since it is changing less and it is doubtful there will be any new bugs. Much less time and effort on my part.

We have updated most everything in the building to 2009. We have stuff in remote sites that are anywhere from 7.1 to 8.6. We skipped 2010, but we have some people in other groups who use it. We plan on using 2011, since I use the FPGA and the real time for most of my new projects. Some of the new parts are only supported on later versions, plus they are making huge improvements in these every version.

If NI is coming out with a new version every year, they should make the impact minimal on their users. Maybe allow me to load a older version in a mode where it loads the older drivers in such a way where I can build applications like it was originally installed, but not necessarily run on the development machine. More like an application virtualization instead of the the whole OS. This goes for the toolkits also. Don't update the older versions toolkits. 

Not sure how, but that should be part of the consideration on any upgrade. I have been using LabVIEW since 3.1. The yearly updates are taking more and more of my time to keep up with. The less time I spend rehashing older programs that I need to support, the more time I can develop new programs (with the associated component purchases, since I typically use only NI equipment).

[GregFreeman]

This thread hasn't been added to in a while. Dennis's posts here actually had me laughing out loud. Especially when he says to the OP "You are deeply disturbed"

[crossrulz]

Yeah, and then the OP called him arrogant.  I was cracking up myself.  I've learned that Dennis will say what we all are thinking to these newbies ("Please try to think things through and get rid of some of your own rubbish").  Ok, he may be a little harsher than what most of us are thinking.  But it's in the same line of thinking.

My favorite lines from that thread was "I feel really, really confident that at some point in the tutorials, a case structure was mentioned" and "I know more about LabVIEW than you could ever possibly know and I gave you the solution".

I was also disturbed since the OP has the same avatar as Altenbach!

On another thread, GerdW is joining the fun:http://forums.ni.com/t5/LabVIEW/ONE-BUTTON-DIALOG-BOX/m-p/2141802#M692850

[Cory_K]

HELLO EVERYONE, I HAVE COME TO THIS POST TO ASK WHY DENNIS WILL NOT TELL ME WHERE THE FUNCTION IS TO CHECK IF A BOOLEAN IS TRUE.

[GregFreeman]

---

@crossrulz wrote:

I was also disturbed since the OP has the same avatar as Altenbach!

---

This seriously threw me too. I took a double take, then later I had to do it again with one of the responses. It shows me how much I associate the avatar with a specific person without even realizing it.

[GregFreeman]

---

@cory K wrote:

HELLO EVERYONE, I HAVE COME TO THIS POST TO ASK WHY DENNIS WILL NOT TELL ME WHERE THE FUNCTION IS TO CHECK IF A BOOLEAN IS TRUE.

---

stop yelling, you're making my eyes ring.