NI: Get to grips with Fundamental LV Shortcomings.

[geirove]

---

@tbob wrote:

This has been a very interesting thread.  Here is my opinion on why NI comes out with so many upgrades in such a short period of time and puts old problems on the back burner:

MONEY!  Its always about money. 

.......

If NI didn't bow to Wall Street, the company would go down the tubes, and there would be no more Labview.  I, for one, am willing to put up with the LV problems and workarounds (at least the company gives them to us like Darren just did) for the sake of NI's existence. 

In this highly competitive business world, there is no other way.

The trick is to keep complaining about LVs shortcomings and be patient.  Sooner or later, probably later, NI will fix those problems.  Its the only way that we will be able to keep on using a great (and fun) programming language like Labview.

---

Well, NI should be aware of this: All the larger PLC Companies are also producing PAC's and PAC related software. If the usability of LV is destroyed by new features that makes it impossible for Developers to Navigate the Source Code, NI is open for attack by these new products. Then they will loose money big time!

In my particular project we had installed the Control System in the Factory when we needed to do some urgent changes: The change should be real quick to implement, but due to two problems with LV 8.2 (no Shared Variable Search, and LV working painfully slow with Shared Variables), I used 3 hours, while production was waiting and loosing money, on something that should have taken 15 minues or less! There's more to the story, but I think I have said enough !

Again: Please NI, the product has tremendous power: Unleash the full power by making it easey to Navigate the source code !

Geir Ove

[MichaelAivaliotis]

I've been using LabVIEW almost since inception V3.1 or something. There is a common thread among all new LabVIEW features. They are never fully fleshed out. What I mean is that, they deliberately, or ignorantly just leave out key usability features on the initial release. This is most likely due to the fact that they have some kind of priority list and the non-implemented parts of the feature fall off the bottom of the list. I'm sure they are aware of all the suggestions we make since they probably have them listed internally already. The order they implement amendments to the initial feature depends on how loud we shout back at them that we want this fix or that fix. This is basically my observation and I don't think I'm that far off.

Having worked on several "off-the-shelf" software products, I can understand how this all works. One thing that helps flesh out a feature internally is if the company developing the software actually uses it as well for internal development. This is called "eating your own dog food" and has been mentioned by people such as Jeff K and the like. The problem with NI is that they can only do so much dog-fooding. Until they start developing automated test systems on a daily basis or even developing LabVIEW with LabVIEW then there will always be areas where they can never grasp how the average LabVIEW users use the environment.

I think NI will always be chasing their tails when it comes to satisfying user demands for IDE enhancements. You just can't please everyone. One solution would be to open up the IDE and offer an API and hooks where users like you and I can add stuff or change stuff we don't like. For example, you could add a hook to the right-click menu where you could add your own options... why not? Then you could write a script (or a VI analyzer action) that would find all SV's. You would name the menu "find all SV's".

I can just hear someone form NI: "are you crazy? You know how hard that is to implement?"
Well, that's not my problem now is it?

[tbob]

Replying to Geri Ove's remark: "If the usability of LV is destroyed by new features that makes it impossible for Developers to Navigate the Source Code, NI is open for attack by these new products. Then they will loose money big time!"

Maybe in your case the navigation problem with shared variables is a show stopper.  But I would say over 90% of the Labview developers don't have this problem because in their projects they don't use many shared variables, or none at all.  In my environment I don't have any use for them at all.  Usability of LV is not destroyed because one can't navigate shared variables.

Labview is not for 100% of the people who develop software.  Because you have a problem with it does not make Labview useless for everyone else.  NI will not lose money big time because there are enough users who are quite happy with it just the way it is.  It doesn't have to be perfect nor does it have to satisfy everyone to make it usable.

In a test engineering environment, Labview is the greatest thing on earth.  If I were an applications programmer, I would probably stick with C++ (yuck!).  In a SCADA or Controls environment, it could go either way; Wonderware is designed just for such an environment and it beats Labview.  So it depends on your intended use if you think it is great or shoddy.

I would suggest you stop whinning and use some other programming language if you have such a huge problem with Labview.  I could offer complaints about VS, but instead I choose to use Labview because it suits my purpose just fine.

[billings11]

tbob said:

"In a test engineering environment, Labview is the greatest thing on earth.  If I were an applications programmer, I would probably stick with C++ (yuck!)."

In my opinion labview has a lot of key flaws in a test engineering environment.  Of course it is easy to use.  But in test engineering it is doubly important to know your tests will produce the same results today as they will tomorrow.  I am currently maintaining about 10 large-scale manufacuring test applications.  Because I need to say somewhat current, I had to upgrade all my code from 7.1 to 8.2.  Every single one of my test applications broke in some way.  Many of my "Save to Database" functions build around the database connectivity toolkit stopped working.  No broken wires, just stopped inserting columns in certain rows with no error message.  Resample Waveform.vi changed a default from open interval to closed, meaning every single labview waveform that I resampled and did not hard-wire this input produced a different result in 8.2 than it did in 7.1.  Like I said, it took about 400 hours of workarounds, finding every instance of broken functionality.  And they weren't always apparent!  Some were only noticeable in test results of the same UUT's on 8.2 systems versus 7.1 systems.  The same code, no changes other than upgrading to 8.2.  And I was very careful throughout this process, maintaining teh original code, etc.  But there is no easy way to maintain multiple labview versions, and also no easy way to maintain multiple applications over time as versions get updated.

I have a production floor with 30 or 40 different deployed executables running different test stations.  These need to be maintained and updated by my IT department.  But since NI's installers are not manageable by user-group policy in windows 2000 server, the only way to deploy an installation is to either do it by hand or spend tens of hours researching the variety of switches required to do a batch installation of the labview runtime, daqmx, cvi runtime, NI-motion, etc.  The 7.1 runtime engine overwrites the 7.1.1 runtime engine.  But DAQmx 8.3 installs the 7.1.1 runtime so if you install that before you install a 7.1 executable packaged with a 7.1 runtime, you will break all the runtimes and executables on that machine.  Stuff like that gets very tedious and its just a lack of attention to detail by NI.

These are all simple details that NI could fix, but they fall off NI's priority list release after release.  Do they make labview utterly unusable?  No.  Do we have a right to complain?  YES!

So yes, labview is much easier to develop than C++ at first, but even in test engineering there are major flaws that NI does not consider important, even in a test engineering environment. 

[tbob]

---

@billings11 wrote:

So yes, labview is much easier to develop than C++ at first, but even in test engineering there are major flaws that NI does not consider important, even in a test engineering environment. 

---

Of course NI should consider all flaws as important, but there is only so much resource to go around, and NI must choose to direct their resources the best way that will keep the company going strong.  That is not to say that your problem is unimportant, but staying alive on Wall Street is of utmost importance.  I agree that we all have a right to complain, and that is something that I have done in the past.

Not having experienced any problems with upgrading, I can't say that I feel your pain.  If I had to spend 400 hours fixing stuff after an upgrade, I would be upset too.  Perhaps you should not have upgraded at all.  You don't always have to keep up with the latest version.  That is a decision that will vary from situation to situation. 

I've worked for a company that to this day still use 5.1.1.  They have no compelling reason to upgrade because that old version does what they want it to do.  It's like if you have VB code, and now VB.net comes out, do you really have to modify all your old code to go to VB.net?  No, you can stay where you are until you have compelling reasons to upgrade.

[geirove]

---

Darren wrote:.

To use this solution, create a folder called "VI Analyzer Tests" under your [LabVIEW Data] folder (on Windows XP this is located at C:\Documents and Settings\[username]\My Documents\LabVIEW Data).  Place the LLB attached to this post in the VI Analyzer Tests folder.  Now, the next time you launch the VI Analyzer (Tools > VI Analyzer > Analyze VIs...), this new "Find Shared Variables" test will be located under the "User-Defined Tests" category in the Tests list.  Just specify the name of the Shared Variable you wish to find, and the VI Analyzer will detect all instances of that Shared Variable in the VIs you added to the "VIs to Analyze" list.

.....

I hope it helps,
-D

P.S. - Please realize that I'm not suggesting you should have to pay $995 to find shared variables in your code...we definitely need to address this Find shortcoming in the core product.  I'm just offering this solution in the event that you already have the VI Analyzer and can utilize an existing tool to solve an immediate problem.

---

Hello Darren,

Thanks for the effort: I would be willing to pay $2000 to get ALL the Navigation issues fixed without blinking !

I have the Analyser Toolkit, and I tried your trick, but have no success finding all my Shared variables: If I open the Top Level VI, only this VI is searched: But I of course want the whole Hierarchy to be searched: I have gropued my VI's into several folders, and including all folders is very cumbersome. Even If I try that, the search takes about 10 minues !!

Indeed need the fundamental Navigation Tools to be fixed !

[Darren]

Regarding the folder selection, aren't all the VIs in your project located under a single folder?  Sure, you probably have a nested hierarchy of folders for your project, but ultimately, don't they all reside under one owning folder?  If so, that top-level folder is the only one you need to add to the analysis.

As for it taking a long time, there are a couple of reasons this could happen:

• Are you running every single test in the VI Analyzer?  You don't need to do this...you only need to select the Find Shared Variables test.
• Do you have your project mass compiled?  If many of the VIs are saved in older versions of LabVIEW, it will take longer to load those VIs because they need to be recompiled.

In trying out this test before making my initial post, it seemed to run extremely fast on the VIs I checked.  The test itself doesn't do very much...it only looks at a certain class of nodes on the diagram to see if they are Shared Variables, and if so, checks the variable name to see if it matches.  I'm hoping the multiple tests issue or the mass compile issue I mentioned above is the cause of the slowdown.

Keep me posted,
-D

[RobbieG]

This has been a great thread and I appreciate everyone who has contributed.  As Michael A. has observed, our prioritization is somewhat based on the volume of the complaints, so this helps us to determine how important this fix is, and I strongly encourage everyone to continue to report bugs that are inconveniencing them as soon as possible.  This issue was first reported through AE channels late in 8.5 development (post beta), which means it went more than two and a half releases without being reported.  It's probably just a case of an issue being so glaring to people that they had to assume that it was a known issue, but don't make that assumption, or you risk waiting longer for a resolution.

I'm not trying to deflect blame off of us, but LabVIEW is a big product and ensuring all new features work with all existing features is an n^2 problem, one that we're working hard to do a better job with.

Robbie

P.S.  To the initiator of this thread, it sounds like you would have some ideas on how LabVIEW should handle searching through source.  Please visit <a href="http://forums.ni.com/ni/board/message?board.id=features&message.id=234">the brainstorming forum topic about it</a> to give your opinions. 

[geirove]

---

@RobbieG wrote:

This has been a great thread and I appreciate everyone who has contributed.  As Michael A. has observed, our prioritization is somewhat based on the volume of the complaints, so this helps us to determine how important this fix is, and I strongly encourage everyone to continue to report bugs that are inconveniencing them as soon as possible.  This issue was first reported through AE channels late in 8.5 development (post beta), which means it went more than two and a half releases without being reported.  It's probably just a case of an issue being so glaring to people that they had to assume that it was a known issue, but don't make that assumption, or you risk waiting longer for a resolution.

I'm not trying to deflect blame off of us, but LabVIEW is a big product and ensuring all new features work with all existing features is an n^2 problem, one that we're working hard to do a better job with.

Robbie

P.S.  To the initiator of this thread, it sounds like you would have some ideas on how LabVIEW should handle searching through source.  Please visit <a href="http://forums.ni.com/ni/board/message?board.id=features&message.id=234">the brainstorming forum topic about it</a> to give your opinions. 

---

Hello Robbie,

I will sure do my best to give proper feedback on the subject.

As I said, the Eclipse project & environment (www.eclipse.org) has the best tools for Navigating Source Code that I have ever seen: Senders / Receivers  / Implementors of methods. Where Variables are Read / Written. Navigating Up / Down and Displaying Class & Interface Hierarchies (in one or multiple Browsers) and so forth.

[Ben]

gierove  wrote " ...but have no success finding all my Shared variables:"

If you are looking for ALL of your shared variables the you can serach on that.

I have been hesitant to step in on this thread.

Aside from the DSC customers, I do not feel pressured to push into the new technology.

Last I read LVOOP was a public Beta  and I know Aristos Queue is working hard to make it real. Cut him a break and feedback.

The passing of the State Diagram Editor will be sorely missed. I'll probably jump to the State Chart Editor once I learn all that "UML speak".

I have only seen performance increases over the years but again, I am not using the Shared Variables unless I have to (with exceptin of DSC apps that have seemed to decline in performance).

I am not using 8.5 in many apps yet but the cFP 2120 seems to be suffering. We really need to be able to monitor CPU usage and memory usage. We lost this with the switch to 8.0.

The Modbus Liibrary is undocumeted and seems to like to create new intsances everytime you want to poll.. It also will dominate the CPU on a cFP 2120 if anything real is being done with the Modbus. I had to recomemd adding 0 ms Waits to all of the data processing loops to get more than one thing running. Since they are installed to VI.lib I was hesitant.

But with all of that said, I repeat, NI has not forced my hand to use the newer stuff (except in DSC).

Data socket reads still work. So does VI Server and plain old TCP/IP. This stuff seems unaffected by the upgrades.

To quote an old boss of mine.

"Ben, whe you are running in the dark, it is the lead sled dog that runs into a tree."

I personally try to stay close enough to the "lead sled dogs" (like the initaitor odf this thread) to watch and see when they "bloody their noses"

Final thought:

When we run into a tree, we have to let NI know about our pain. The pubishing of the bug fixes for each realease show that bugs are getting fixed and NI listens and cares. Not every bug gets fixed. I have a coupple I'd like to seee fixed but I admit mine are trivial.

So PLEASE take the time to report bugs and discrepancies!

We are the users of LabVIEW and know better than NI what LV needs (Oh NO there goes Ben getting argant again ). This is no insult to NI. This same question was addressed by Socrates in the Republic and it was deemed that

"The expert in a thing it the user of the thing." (paraphrased from memory)

So LV is and will be only as good as we the "users of the thing" make it through our feedback!

I have thoroughly enjoyed this discustion and appologize for yelling.

Go ahaed flame me if you want.

Ben