A scathing review based on my experience upgrading from labview 7.1 to 8.2.

[Travis_M.]

Hello again everybody,

I have another issue on this list that I would like to talk about this morning, and that is the comments that NI has been forcing it’s free tag color scheme on developers for stylistic reasons.

There are important reasons to maintain consistent style in both your C programs and in your LabVIEW programs (I use C as an example only; the concept really applies to ALL programming languages).  This should really not be a surprise to anyone, and I think we all understand the merits of good style.  That being said, here is the NI LabVIEW Style Checklist.  You’ll notice that in this document, we don’t mention the color of free labels, with the exception of labels along wires.  This is because there are sometimes good reasons to change the color of the labels, such as those cited in this thread.  NI would never deny certification for not using the default yellow/black free labels (yes, I did verify this).  If anyone was previously counted off, I’m not sure what could have happened on those tests.  If anyone is interested in discussing it further, we might be able to look into those test results for you (please contact us directly, as I do not believe this forum is an appropriate place for us to discuss specific test grading).

As far as the “why was this option removed” question is concerned, I’m still looking into that.  At least I can say that for the past 5 releases it hasn’t been an option that you can configure in the LabVIEW options.  Needless to say that if you changed the default color of your LabVIEW free labels it wasn’t a widely-used or known thing (though, it does sound like a useful feature in some cases).  If it was done through changing ini settings, I just want to broadly state that we do not recommend modifying or relying on ini settings in LabVIEW.ini as a way to configure LabVIEW environment options.  The vast majority of options configurable through the ini are configurable through the LabVIEW options.  I know that there are exceptions to this rule, and we try our hardest to preserve the behavior of ini keys across versions.  I will continue to look into how this was done, and maybe comment as to why it no longer an option

[Travis_M.]

OK, so I have one last update for the day, then we’ll take a heartbeat on the issues and continue where we left off.

We have been looking into the label color issue from a technical standpoint recently.  It looks like the behavior you desire is to 1) have the ability to set the background color of the labels to transparent, and 2) change the default application font color.  

The first point on here, is something you used to be able to do through the options, and was removed from the options in 8.2.  You can still set this option through the ini file.  Normally NI employees and beta customers are specifically asked not to talk about features, changes, etc. in unreleased software.  However, since it was already mentioned and it’s an important change we made, I’ll let you know that that option has been put back in the options page, and if for some reason we need to pull it, I’ll be in your corner and make the argument that we should not remove it.  The lava post linked earlier also describes this issue in more detail.

With regards to the second point, as far back as 6.1 the application font color is preserved only while LabVIEW is open.  When you restart LabVIEW the color reverts back to black and you have to set it again.  The font size is preserved, and I agree that the color should probably be preserved as well (after all, why keep one option and not another?).  I went ahead and filed a bug report on this (CAR# 4A5GT93A), and we’ll look into fixing it so that it behaves better.  If there is some way to preserve this between LabVIEW launches (even in 6.1) I’d be very interested in knowing it, and I can add it to the known workarounds for the issue.

Ok, so I think I’ve addressed the first 2.5 issues -- Resampling Waveforms, free text  default colors, and NI style guidelines.  The Pasting of Control Images into MS word, was concluded to be limited to cluster controls.  I’ll go ahead and file another bug report on that one as well (CAR# 4A5H4G3A).

With regards to the Toolkit Installation Errors issue, I’m not sure from your description, but is this the problem you are having?  If so, the fix is to repair your runtime engine.  If this is not the issue, can you please describe in more detail the circumstances of the error, and maybe include the error text and/or a screenshot?  

Thanks again folks for your participation and feedback!

[tst]

---

@Travis M. wrote:

Normally NI employees and beta customers are specifically asked not to talk about features, changes, etc. in unreleased software.

---

Yeah, sorry about that, but since it was actually an old feature and since Christina already said that it will make its way back into the dialog, I figured there would be no harm done in this specific case.

Now, if I wanted to talk about interesting new features, I could bring up ************** and **************, not to mention the *********************, which is really cool.

[Ben]

"*********************, "

Oh Yes! Now if I only had more time to Beta test!

Ben

[billings11]

Travis,

Thanks for your efforts here.  I have gotten better response through you and the discussion forum that any of my local reps.  The biggest other issue is he broken connectivity toolkit and changes to the variant structure which are undocumented.  I have developed a network of ATE's that manage firmware and software for various devices, and they all save that firmware as binary images in an SQL server database.  In labview I represent those "firmware images" as variants, so when the connectiovity toolkit could no longer save variants it broke every application I have entirely.  It took a long time figure out what was wrong and to re-write things.  Basically the database toolkit parses out how many bytes to put in each database column by size.  It flattens the whole cluster of data and then by type parses out how many bytes are in each column, so if the type is a double it assigns teh next 8 bytes, for example.  Variants used to represent their size in the first four bytes, so the toolkit looks at those bytes as an I32 and parses out that many bytes.  But now since the size of the variant does not appear to be contained anywhere in the data, the whole parsing concept doesn't work.  It saves some random number of bytes to the next column and corrupts the data.  So the architecture of the connectivity toolkit itself is incompatible with variants, and its not an easy fix. 

I also think that even though you are fixing the specific problem of Resample Waveform (single shot).vi, you should also do some sort of corrective action internally to make sure this type of thing doesn't happen again.  It just can't happen ever if you want labview to be used like a real language.  Since it does happen and has happened, we have to react accordingly.  So one option is to take all the NI palette vi's out of the NI directory, rename them, and call them from a new directory I maintain.  This way my code won't target the NI directory for anything and I can be sure it hasn't changed.  Or I can rewrite low level code in C and call dll's, so I can be sure anything I wrote in a dll won't change.  In addition to these practices I will have maintain multiple versions of labview.  If I develop an application in 8.2, I will never upgrade it to a new labview version, and always maintain it in 8.2.  This is exceedingly difficult because of the way labview searches all over the place for subvi's and then likes to mass compile things automatically.  But if I am careful and back things up I can do it.  As long as the runtime engines are backwards compatible, (so the 8.2 runtime will run 7.1 vi's), I should be able to have applications in all different versions of labview.  This way new bugs will only affect current projects and not requires weeks of work to fix all previous projects.

By the way I can report one more very minor bug, but I figure while I'm at it... When you create a dynamic vi from a labview class, the dynamic vi comes up with a default grid spacing of 12 even though I have it set to 6 in my options.  It probably should come up the same grid spacing as everything else, but since its generated from a template or something I can see why it works like this.  I know how to fix it, but would be better if the grid spacing adhered to my custom settings.  Kudos on the LVOOP stuff though.  I'm only just starting to re-implement code using LVOOP, but it seems to be effective and make good sense so far.  I have coded as OO as possible already by using variants to pass in very structured ways, but since you could never really use classes, object oriented stuff also tended to consume a lot of memory as it would be copied all over the place.  Now with a real class implementation I'll save a couple hundred MB of RAM and have much better performance I think, since I won't have variants copied in memory everywhere.  My only concern now is that it all still works in any future releases!

[Odd_Modem]

They probably had to rework the variant to allow it to support more data types like I64 etc. I have talked to a MSSQL database that had 64 bit primary keys, with the 7.X database toolkit. It did work after awhile. This variant issue does seem a bit more important than the color of comments, although I have never used variants as the data of persistent storage; they just run around in the wires of my program. I suppose your problem raises another issue with LabVIEW in that the compiler reports either errors or no errors, never a warning.

[Travis_M.]

Hello everyone,

To begin addressing the next issue, let me first explain why we changed the Variant type with respect to the witticism "if it ain't broke don't fix it".  It turns out that the variant type wasn't really broken, but there were a couple of things that could be improved upon.  Variants themselves are not flat.  That is, the memory that represents a variant can exist in many non-continuous places.  However, many times there is a need to be able to "flatten" the variant to send it places (such as to a database), and a pair of flatten and unflatten to/from string primitives exist to help out with this.  Because the flatten and unflatten require a type descriptor for the operation, and the type descriptor had to change for other reasons, we needed to change the variant and flatten primitives.  We had a choice; we could continue to require users to choose which version they want to unflatten from and add a version, or redesign the variant to do it automatically (which required us to store the LabVIEW version in the variant).  To make things simpler and overall better for people, we choose the second option.  To improve performance of variant operations, we removed the size.  I don't want to get too into the details of why the performance is impacted by this, so you'll just have to trust me that we concluded that the size was redundant, and resulted in a performance hit.  We accordingly removed the size in hopes that people weren't relying on raw bit operations on the flattened data (which is always risky).  It turns out that our database toolkit was relying on the size, and accordingly yes we did break our own toolkit for this particular use-case.  I assure you that we do test all of our toolkits for version compatibility even when the toolkit does not rev (meaning we don't revise the toolkit for a new version of LabVIEW).  The amount and types of testing done for a particular product are done by that particular group, and unfortunately the database testing did not include reading/writing variant columns to a database.  This is how we missed it, and again, please understand that we sincerely regret any problems that this has caused you and anyone else who has encountered this problem.  The toolkit developers for that product are looking at ways to resolve this problem as we speak, and hopefully we can give you an update on that sometime soon.

There were a couple of other things in your last post to address.  One of them is runtime engine compatibility.  LabVIEW code is compiled to both machine code and code that is executed in our runtime. Because the runtime engines are different between versions (new features, bug fixes, etc) and the LabVIEW compiler changes each version, LabVIEW must compile your code for the version you intend to run your code on.  This is no different than many common programming environments where you must compile the code in that version to run it in that version.  The difference with LabVIEW code, is we must have a block diagram in order to compile, and the application builder does not keep those block diagrams around.  Furthermore, to recompile the VI would involve having to modify the VI since the source code for the VI is saved in the file.  Because of these things we do not have a runtime engine that is fully backward compatible (meaning a runtime engine that can run code in the current and all previous versions).  Your runtime engine can, however, run code from the same minor version (i.e. your 7.1 runtime can run code from 7.1.1 and vice-versa).

The final point to discuss, is the minor bug you found in OO.  I am glad to hear that you are using the new OO features, and hopefully the many bug fixes in 8.2.1 to OO have further improved your experiences with this.  We had actually seen the grid bug you are talking about, and CAR 49MA4FU1 has been filed.

Thanks again for the feedback, and hopefully this has all been helpful.  Have a great afternoon-

[_S_G]

I had the same problem with the "Get waveform subset.vi" where it would return the wrong subset.  The VI works fine if you specify the subset as "samples" instead of "relative time".

Message Edited by Sudhir Gopinath on 06-07-2007 04:22 PM

[TroyK]

I just tried to repeat the error from scratch before trying your suggestion Sudhir. The problem didn't show up!
Apon further investigation I discovered that when I mass compiled from LV7.1 to LV 8.2 the
"WDT Get Waveform Subset.vi"                        from LV7.1 was replaced with
"WDT Get Waveform Subset DBL (LV80).vi".

When I built a new vi to repeat the error, the vi placed from the palette was "WDT Get Waveform Subset DBL.vi" (NOT the version with (LV80) in the name).
"WDT Get Waveform Subset DBL.vi" doesn't have the error!!!

So the problem is only with the "WDT Get Waveform Subset DBL (LV80).vi" which is substituted for the LV7.1 "WDT Get Waveform Subset.vi" when you convert it from LV7.1 to LV8.2.

[billings11]

One major point about the runtime engines backwards compatibilty.  I understand why the 8.2 runtime is not backwards compatible with 7.1 or any other previous version.  But that means it is not realistic in practice to run an executable from any version of labview prior to 7.1.1 on a machine at the same time as any application created before 7.1.1. 

If I have a machine running some software I created in 7.1.1 or later, and I intsall some other executable created in 7.1 or earlier, the labview 7.1 runtime corrupts the labview 7.1.1 runtime and you cannot the vi's anymore.  You may say that one could get around this by making sure to install 7.1 before 7.1.1, but that is just not practical.  I have to build installations that can be installed on any machine by someone in IT.  And a 7.1 installation cannot kill anything already on a machine that requires a 7.1.1 runtime.  A real IT department will just reject that installation because it breaks other applications.

This is even more critical because any version of DAQmx later than 7.4 installs and uses the 7.1.1 runtime.  So in the real world you cannot have anything you wrote in labview 7.1 or earlier running on a machine with daqmx 7.5 or later.

That means I am actually forced to go to labview 8.2 on every application if I am going to do it on one.