Chart digital display bug

[_Bryan]

Very nice program.

I would not hold my breath waiting for a fix.  It just seems like part of the joy of NI bringing out a new version every year.  It seems like they finally fix something in one version just to break it in the next version.  And if it gets fixed in a later version and your service contract runs out you will never get it fixed without upgrading, they just leave you behind in the dust to deal with it.  It is a horrible cycle for me.

Sorry for the rant

[ceties]

Could somebody from NI tell me when the CAR#252270 which is this chart update bug will be fixed? LV 2011SP1 or later?

Thank you!

[Verne_D]

Hello Ceties,

I'm familiar with your problem and want to share a little explanation. To answer your direct question, the problem described in CAR#252270 is not fixed in 2011 SP1. This doesn't mean that we haven't considered it or we don't care. Quite the opposite, we realize this is aggravating and the CAR is still active. As of today, we don't have a good fix ready that we could put into any version. If we did, I'd be happy to share it with you for testing.

While the behavior is easy to demonstrate and observe, it is not nearly as easy to fix. The workaround which you mentioned (moving the digital display off of the graph's drawn portion) is the easiest way to avoid the problem. Additonal CPU/memory resources seem to help also, but that's not always a practical option if you're distributing to systems where you won't control the equipment. It bears mentioning that the example provided (DisplayLoad.vi) keeps about 1.8GB of information in memory (all the data the graph is displaying), if we need to go to disk for paging some lag will appear in the UI in many cases. As you've also mentioned, decimation is how we recommend handling problems like this typically. Storing the bulk of information on disk and creating a summary view for the user makes the UI load much lighter. For cases where the user is selecting a more specific selection, you can populate the graph dynamically by fetching data from file. It's not an easy change, but it's economical with system resources.

I was playing around with different UI options that might make moving the digital display off the graph more aesthetically pleasing, but your app demonstrates that you probably don't need my help to make high quality UI. The version I liked best involved placing the digital display over a black decoration along the right side of the graph.

I'm sorry I don't have better news about the specific bug you're intersted in. In the interest of you getting to deploy your application, I'd suggest that it would be worth your effort to be creative with your displays to get around the overlapping or create a UI that only consumes a subset of the data. It's not perfect, but it will let you move past the roadblock.

[ceties]

Hi Verne and thank you very much for your insight. I understand that what is very often easy to observe can be difficult to fix. I have no problem with that. I can also understand that bugs can happen. Even my programs aren't bugless 🙂 What is/was my main problem was that I reported the bug 1.5 year ago which according to my opinion is enough of time to fix even very complicated bugs. The bug was even identified by a NI engineer and after 1.5 year there was no sign of any upcoming fix, not even a clue about a version. What was the problem?

The problem was that I reported it through the forum and it got low priority (if any). Two months ago I started yelling at NI engineers and things started moving and I hope the fix will apear in LV2012. If not, I will start yelling again. I always prefered the forum since more people can read about the progress but in cases like this one... Anyway the truth is that NI is not that flexible in fixing bugs as they could be and it then brings me frustration when I am starting new projects. I worry that I will encounter one of those "unsolveable" bugs. It is then difficult to take LabVIEW seriously as a professsional tool if you spend 30% of the project time finding workarounds of not fixed problems.

If anyone is interested in the measurement application there is new version here and tutorial to it here.

[Verne_D]

ceties,

We don't promise fixed version as a general rule because we don't want to fail to fulfill a promise.

Like any codebase, fixing one LabVIEW bug can introduce another. User Interface components are more sensitive to these tradeoffs because people are very discerning about what they are looking at. We try very hard not to introduce new problems by fixing old ones. We think upgrading code should not introduce unintended behavior, and prioritize that for every release. In general, we also prioritize customer reported bugs highly.

We try to encourage our users to engineer around roadblocks, even though we know it can be frustrating. We would love to fix every bug, but there will always be some that don't make it in to the next release. Bugs that cause crashes, hangs or have no workarounds whatsoever get priorized highest, and how safely we can implement a fix factors in also. I'd encourage you to stay in contact with your local sales representatives and support staff. We can often make suggestions that will help you save time dealing with reported bugs. I hope this has been helpful for you, we're always happy to see applications with the attention to detail you've invested in the marketplace.

[jozisoftware]

For people who have problems with displaying zeros or issues with executables, please see my solution I use in our facility 🙂

It is a workaround for bug 3747644H8J3ZP, 451334I0976O4, 252270.

[ceties]

Sorry, but this is no sollution. Whatever you put on the graph (on the plots) it will cause the artefacts described in this thread.

[jozisoftware]

I see that problem is indeed a bit different then. My zero's and not resizing of the digital display in an executable however are solved with this.