NI: Get to grips with Fundamental LV Shortcomings.

[MichaelAivaliotis]

Mike, what are you talking about?

If NI creates a feature that allows you to create SV, does this mean that they should cripple the usability by not providing an easy way to find references to them? Global variables are considered bad too but at least you can right click on them and select "Find global references". We're not talking about shortcommings in the capabilities of the language but limitations in usability features for the programmer.

[mikeporter]

Yes, if NI does decide to implement something they should do it well... But my point goes beyond that. The real questions is why are there "Shared Variables" in the first place? LV certainly doesn't need them and they add nothing to the language that couldn't be done just as easily in other ways. Like so many things that have been grafted onto the language in recent years, they are things that LV doesn't need but NI implements them because they are things that "...all real programming languages have..." .We need good tools - not fads like shared variables and state charts (another poor implementation of a bad idea).

Mike...

[geirove]

---

@mikeporter wrote:
....Most of the "shortcomings" that LV exhibits arise from NI trying to placate people such as yourself who have no idea about how to go about creating a good LV-based application.  and immediately assume that LV is only for "small" projects....

Mike...

---

Taking into  account that you know nothing about me or our application, your response seems very arrogante. There is a reason for the number of varibles we used, and they are used in a simple way: Sending status data over the network. I have never made any assumptions that LV is for small applications only. Our application has approx 300 VI's.

We do indeed understand the difference between OO and Dataflow programming.

That aside, I am human, and I do make mistakes: Even if I had only ONE Shared Variable in my application: How can I find if this very variable is used in the wrong place if I cannot search for references to it?

I am all in favour of promoting good programming practices. However, that is not an excuse for, or not the same as,  not supporting fundamental tools in the programming environment.

[Wiebe@CARYA]

Mike,

I agree with you on the use of shared variables.

In my opinion, SV's are globals, with (limited) OPC functionality. And I
think we agree on the use of globals... And as long as I can't get a list of
references to each SV in my project (so I can save and load them), I'm not
going to use them for sure. Or perhaps if I desperatelly need OPC. Guess we
learned to build code without them. But since they are here, people will use
them.

In the years I've been using LabVIEW, I learned not to depend too much on
new features in new releases. Recently I fell for it again. I used the new
pane background. The bugs just kept on comming... And jet another example...
The runtime menus for controls. First thing I wanted to do is change them
during run time. Perhaps I'm stupid (probably), I still haven't found how to
do that. So I did what I am used to after years of using LabVIEW: I made a
workaround...

NI is very eager to add new "hot" stuff, and not so eager to work on
shortcommings. We still cannot rotate a control! How's that for a
"graphical" language?

Regards,

Wiebe.

[billings11]

Weibe,

Exactly, all NI's work goes in to marketable new features.  Any effort towards implementing those features properly is second-tier in their priority list.

Take LVOOP for example, even after numerous complaints they still released 8.5 on their marketing department's schedule with absolutely no effort to allow proper building of exe's with LVOOP.  They knew there were problems but prioritized the fix behind the marketable features.  Its actually just like this poster's problem with shared variables.  The idea is good, the concept can be beneficial, but if the feature is 95% complete that's enough to stick it on a marketing sheet and release a new version.  The last 5% or the feature may never get done.

Most newer features have this problem.  LVOOP and the project manager have the same kinds of detail issues.

Even easy things, like if I "View this vi's callers" it just opens the front panel of the caller.  It should give me a list of instances like it does in the find and replace menu!  But instead I have to use the find and replace menu, and by-hand browse to the vi.  And don't use NI's installers if you try to deploy exe's.  No NI installer will work through a network group policy, so IT people hate NI installers because they can't even do network installs.

And every labview developer I know agrees that they aren't ready to upgrade again for a very long time. 

For a large GUI level windows app it only takes about 20% longer to code it in C# with Visual Studio than it does in labview.  And I think it will be way easier to maintain and transfer your project to VS 2008 (properly beta tested before release by the way).  And you will only have to worry about doing that upgrade once every 3 years (not like once every 6 months to keep up with new labview releases).  And way less stuff will break during the upgrade process because you will be using a much better quality-controlled platform.  So in the long run, for a lot of projects I think it is actually less time consuming to develop in VS than it is in labview.

Message Edited by billings11 on 10-05-2007 07:14 AM

[Wiebe@CARYA]

On the other hand, if you have a running project, nobody is forcing you to
upgrade 😉

LabVIEW has a big disadvantage over other programming languages. LabVIEW is
the programming language, and the IDE in one. So when you don't like VS, you
can use DevCpp. And complains about VS (why do I have to select "Build
Solution" to compile (VC++ Express Edition)? talking about marketable buzz
words) don't end up as C++ compains.

Also, NI's mentality has changed for the better in the past year. For
example, I'm sure NI is reading this thread, while a few years ago, all
customer suggestions where ignored.

The upgrade policy is also changing. I think (don't know where I heard this)
they are going to release a new version every NIWeek, and they told to deal
with shortcomings as well (I think there is a percentage they strive to
solve, but I'm not sure 'bout that either). I am sure they will never give
any guarantees through. We can only hope. Especially the past years the
number of upgrades is getting out of hand (8.0, 8.0.1, 8.2, 8.2.1 and 8.5 in
about one year?).

Another annoying thing is that each version is bigger (and slower to use,
although 8.2 was faster then 8.0). I know that is in the line of any other
software (like Windows, and VS), but as far as I'm concerned it's not
progress. Not just LabVIEW, but also the run time engine. And developers
have been complaining about that since 4.1!

Regards,

Wiebe.

[billings11]

That's a very good point about labview being at a disadvantage because it is both the language AND the development platform. 

Part of the why I can code really fast in labview is that at this point I have a huge library of reusable code from all the projects I've done in the past.  When labview upgraded from 7.1 to 8.2, probably 98% of that code transitioned without a problem.  But 2% of it broke.  And not just broken wires, but changed functionality.  I spent about 400 hours finding problems and creating "workarounds" for unintentionally changed or broken functionality.  Database functions stoped adding rows, waveforms got resampled differently, none of my old *.bld files ported properly into the project manager and were buildable without creating a new project and executable build from scratch.  And from NI's perspective I was taking a risk by jumping multiple versions at once, from 7.1 right past 7.1.1 and 8.0.  But all those releases were less than 3 years apart!  And I sort of have to upgrade everything at once, otherwise I'll be maintaining different or duplicate libraries of code in two different labview versions, which just sounds like a nightmare to me.  But 400 hours of work fixing code that once worked perfectly will change one's outlook.

Now if that were a library of C++ code, that code is still C++ regardless of the development platform's version.  So it will still work, and it will work even if I completely change development platform companies.  A library of C++ code will never require 400 hours of work to fix it if VS goes from 2005 to 2008.

[Darren]

I definitely agree that the Find functionality in LabVIEW should be able to locate specific instances of Shared Variables, just like it currently does for Locals and Globals.  I have pointed the appropriate developers in LabVIEW R&D to this thread so they'll know about the issue.  For now, I have a temporary solution to this issue for anyone who has the VI Analyzer Toolkit.  The VI Analyzer is included in the NI Developer Suite...otherwise, you must purchase it separately.

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 tested this VI Analyzer test in LabVIEW 8.0, 8.2, and 8.5.  I cannot guarantee that it will work in future versions.

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.

[Wiebe@CARYA]

I'm not too experienced with C/C++ code, but I disagree that you can switch
development platform without problems.

Especially if you take into account c#, MFC, and stuff like that.

Compiling a VC++ program with GNU C++ isn't always easy (although it should
if the program follows all the c++ rules).

Regards,

Wiebe.

[tbob]

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.  The top dogs at NI feel that they have to come out with new products or they will not be perceived by the Wall Street jerks as making any progress, and their stock value will go down.  That is the bottom line.  So the developers are forced to come up with something new (rather than fixing the old) and push it out to market before it is completely ready.  Problems like the ones that started this thread are not critical enough to halt the introduction of a new product.  NI top dogs, like all other companies' top dogs, bow to Wall Street, not to the people that use their products.

I will say this about NI though.  They do care more than the average company about getting opinions from its products users and will make an effort to fix the problems.  That is very evident.  Even on this forum there are threads started by NI employees to get our inputs and to hear our problems.  I am very thankful for that.  But some of these problems are just not as important as showing company growth by introducing new versions of Labview.  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.