07-01-2011 02:15 AM
Hi Ceties,
I've consulted with my colleagues on the status of this issues and learned that the fix of this chart bug was deferred for later Labview version (other than LV 2011), as the workarounds you've provided show that there is a good way to avoid the issue, even though it may not be the most elegant implementation. Regardless of that we intend to fix the problem, but the timeframe for the fix is determined in a manner that may not seem straightforward. Usually we try to fix the most impedimentary and widespread bugs first. This particular bug, while frustrating, does not completely hinder the users progress. As such, it may be prioritized behind other issues which are more difficult for a user to fix themselves. Until that we've flagged the bug for inclusion in the known issues list. The next time the list is updated, the new entry should appear.
Sorry for not being able to give you better news and please keep providing us feedback on ways to improve Labview.
Thank you for understanding.
Regards,
Barna D.
National Instruments
Applications Engineer
07-01-2011 02:36 AM - edited 07-01-2011 02:37 AM
Hmm this doesn't make me very happy. It really is a problem for me. See the attached VI.
1] first run it with the Digital displays hidden (both the property nodes = false). Observe and see how fast it updates. Observe CPU Load.
2] now run the same VI while changing the 2nd property node to True. This way the bug of the graph not updating is overcome while the DigitalDisplay is shown but the Chart starts to update VERY slowly!!! It gets worse with higher amount of date being written into it. Observe the CPU Load.
The reason is the Digital display being placed ON the chart. And I really need to have it this way. All the comercial measurement apps have it this way. You see progress as a chart plus the actual value. So far I solved it with high decimation so less data was written into the chart and the CPU load was kept on reasonable leve but now if somebody needs to zoom...it doesn't show valid data after the decimation.
This problem appears if I place ANYTHING over the chart - just try simple string control. I really need some usefull workaround for this. Something where I can have the Digital display ON the chart and not having such an unreasonable CPU load. (btw don't bother to advice that I could use my own implementation of digital display. I've been there. Whatever is placen on the chart causes the unreasonable CPU load. Any other object)
07-06-2011 01:29 AM
Dear Cetties,
Do you really need to use waveform chartor you can also use waveform graph?
Does your graphical indicator of the waveform show a continously acquired wave, or finite acquisition?
Please give us some more details on your app.
Mircea
07-07-2011 04:46 PM
In about last year I coded quite sophisticated application for measuring using any NIDAQmx compatible device. The app lists devices, the user selects the device he wants to use, selects the channels that wants to use, selects if he wants to filter, decimate data, selects what sort of measurement he wants to perform...ect. As many channels he selects there has to be plots visible. There is set of plots for preview (short preview of the signal - depending on the rate 1sec to 30sec) and then another set of plots to show the total measured data (highly decimated using the Max/Min algorithm)...
Anyway using graph is not really an option. Yes I could code my own circular buffer for storing some history, but first of all in all the cases I need STACKED plots which is something that the graph doesn't offer (WHY?!!!). Yes I could create multiple graphs and position them, yes I could create my own digital displayes for them, I could change the way I write the data into the chart to write it into multiple graphs instead. But this altogether is really LOTS of work not mentioning the other depending routines that I have for handling the data, resizing....this is something that will take me a week and I still am not able to think of all the consequences that this major change would bring. For this we paid NI to deliver their product. We kindly overlooked the bugs in hope that it will be changed in next release and gave you one year. And after this I see that nothing happened.
Take this as my official complain. There are many bugs of charts that nobody have fixed yet. Another I discovered and nobody fixed see here
08-12-2011 03:08 AM
Can somebody from NI tell me when this is planned to be fixed? Will it be in some of the patches or will I have to wait for 2011 SP1?
Thanks
08-12-2011 01:04 PM
http://forums.ni.com/t5/LabVIEW/Waveform-chart-digital-display-blinks-zero/m-p/554868
This might be related to the previous problem. I have had problems with the digital displays and charts where the valves display keep flashing zero. Users can't understand this is a bug. It makes the application look like it is not working correctly.
ceties:
I have been working on a application like you mention and would like to see if you could offer more detail or even a sample vi.
(In about last year I coded quite sophisticated application for measuring using any NIDAQmx compatible device. The app lists devices, the user selects the device he wants to use, selects the channels that wants to use, selects if he wants to filter, decimate data, selects what sort of measurement he wants to perform...ect. As many channels he selects there has to be plots visible. There is set of plots for preview (short preview of the signal - depending on the rate 1sec to 30sec) and then another set of plots to show the total measured data (highly decimated using the Max/Min algorithm)...
08-12-2011 02:28 PM
Here is how the app looks and works. It is the older version. I can't release the new one (LVOOP) until this bug is fixed. I won't post the Vi's of the app since I don't think that it is related so much to the problem. This is just a bug that has to be fixed. Forcing significant changes of the app design just to overcome one bug is not an option especially if the design is good and as soon as the bug would be fixed I would change it back anyway.
08-12-2011 02:51 PM
Very nice! I can tell you put a lot of work into making that look good and work well.
08-15-2011 06:47 AM
Agree! Very nicely done!
10-06-2011 05:29 AM
Will this display bug be fixed in the 2011SP1?