Strip chart labels go crazy

[sth]

Any one seen this kind of behavior when the strip chart labels suddenly get hundreds of digits.  The labels are autoscaling and set to integers with two digits of accuracy.  This in general is fine, but when it gets corrupted data over a TCP/IP stream it suddenly looks like this.

Note that the middle plot is missing entirely as covered up by labels, it is normally the same size and format as the top and bottom plots.   I have tried to duplicate this issue by sending occasionally 10^300 values into the data stream but even the same front panel plot just changes the labels to dashes when it gets data that absurd.  This is in a built application on Mac OS X.  LabVIEW 16.

My solution is a complete re-write of the data server to ensure non-corrupted data.  BUT, this still shouldn't happen IMHO.

[NoHeart43]

Hi sth,

That certainly is strange behavior that I have never seen before. I have not yet found any other instances of it in my research either. You said this happens when data gets corrupted over TCP/IP. Are you also sending the strip chart label over TCP/IP?

[Ben]

No never saw that.

Advanced >>> Autoadjust scales

Try to disable it.

Try the same chart off the tab control (if you can repeat the failing test)

No other ideas come to mind.

Ben

[sth]

Here is an example.  It certainly shows the issue in LV 16 (and 15) on Mac OS X.

Do not change the original window size.

Run the strip charts, then when they are full and scrolling, push the bad data button.

Both chars will go nuts.

Then clear the bad data button and the charts will return to normal (top one first)

BUT NOW THE CHARTS ARE OFF THE WINDOW!!

The change in label has changed the size of the front panel indicator.

This does not work if the exponent is set to 300 where the labels become dashes, but certainly shows up if it is 150.  Around 100 it shows a shrunken chart.  But when the bad data clears the plot area, the chart should look like the original indicator.  It does not.

Yes, very strange.

[RavensFan]

LV16 on Win7.

When the bad data does clear the chart., it snaps back to where it was.  But it takes 17 times longer on the bottom chart because your history is about 17,000 elements.

And it is caused by the display format for the Y axis being 2 digits of precision on floating point.  So you are telling it to show all those digits when it goes to large data.

The only thing I can't tell you is whether the Mac version of LV is having problems that go beyond what the Windows version is doing.

I think if you can't fix the source of the data, what you'll have to do is detect when you have bad data coming in, and elect not to plot it.

[sth]

No the chart does not snap back to where it was.  The left edge and the labels snap back but the chart has the right hand side off the edge of the window. 

The indicator is permanently larger and different area on the FP than it was.  This ruins the UI as laid out and cannot be corrected by the user.  (especially in a built app environment).

I just checked in my LV 16 VM I spun up and even on Windows the indicator does not go back to the original size after the labels clear.

Also there is some limit since if you use a 10^300 scaling LV is smart enough not to try that many digits.  So whatever decides that it is an absurd number of digits is being a bit too lenient.  If the digits are greater than the length of the plot area or even half the plot area they they should not be displayed.

[RavensFan]

I'm telling you my experience with your VI.  For me, it does snap back.

See the pictures.

The point where it seems to go from loaded numbers to dashes, is going from 250 to 251 on that numeric control.

 

[sth]

But it did not snap back.  Look at the pictures, check the size of the bottom plot indicator in the top picture and the bottom picture.  It has fundamentally changed the position and size of UI elements.

The difference is the window and font sizes on Windows and Mac but the same basic error is there.  There is a weird interaction between label size, indicator size and the FP window size.  For my settings on windows (where I decreased the FP window) to fit the original indicators there was a dramatic shift outside of the window.

If you try making the number 240 or so, I bet that the difference will even change the top indicator size as well.  I think I get different numbers since I have an enlarged font running on a retina iMac which makes the normal size of windows way too small for my rheumy old eyes.

[RavensFan]

Okay, you're right.  There is a difference.

The heart of the graph snapped back and that's why I didn't notice any severe oddities in the graph.  But yes, now that you pointed it out, I see that the width of the overall graph has changed.  It wasn't obvious to see while it was running.  But looking at the different screenshots lined up like that, I can see it.

I think graphs have always had issues with their many moving parts to try to maintain all of the proportions of their parts.  I wouldn't expect this to be fixed anytime soon.  I'll go back to what I said earlier and you will just have to make sure that if you receive bad data that would cause this problem, you'll have to condition it out so it doesn't make it to the graph.

[sth]

Agreed, I plan on two approaches:

1. Reengineer the client/server protocol to avoid corrupted data.  I know how they get out of sync and just have to scrap the current implementation and re-do it.

2. I can also put a 'sanity' filter on the plot

As I understand it, there is a sanity filter built in and that is why there is a difference at 10^250 vs 10^251 as you determined.  I am just thinking that filter is allowing a bit more insanity than is sane.

But even the plot area on the bottom plot (the heart) doesn't return to the original size.  To have FP indicators suddenly start reshaping themselves is a bit problematic.  But it may or may not get fixed.