Annotation Label Offset Explanation

[minnellac]

This represents the problem beautifully.

Open the example as is, and run. This is the trivial example I described. Everything appears to work correctly (or at least as you'd expect). Now, change the formatting on the y-scale so that there is a scale multiplier of 10 (instead of 1). For entertainment purposes, you should also turn off y scale autoscaling and set the scale range to -100..100. Now run.

Not what you'd expect, is it? Also, you can set the offsets to 0,0, and you will see the same behavior.

I hadn't tried this on cursors before, but apparently they are exactly the same as annotations.

Thanks for looking into this.
Chris

[MeghanK]

Hey Chris, thanks for pointing that out to me.  This behavior with the cursor label moving all over the graph and not responding to the label offset values is very unusual.  I created a Corrective Action Request for this issue, filed as CAR4GIEK3TP.  Hopefully we can have this fixed soon, thanks again!  Please let me know if you have anymore concerns.

[Kjell-E]

Here is a stripped (no functions or sub-vi's left, only a property node read/write and a graph) vi that also illustrates the problem, only for me, the y-offset seems to work, but the x-offset is mirrored (or negated) around the y-axis. Instead of apearing at relative X-position of 0, it goes to absolute x-position of (-1)*X-cursor position.

I too find it is related to the scaling of the x-axis, in my case the scale is 2E-5 to bring my 50k samples into the time domain.

The VI is some 35kB, written in 8.5 Pro and running on Windows XP. We are currently closing in on a delivery to a customer, and the only acceptable fix we have found is to turn the lables off for now.

(We generate the cursors and the lables based on peaks as data comes in, using a for-loop which iterates over the peak-X locations).

[minnellac]

Kjell-Edmund, I see the problem you mentioned. I thought I had sorted all that stuff out before, but I don't have time to dig into it right now. Definitely a bug. Anyway, I'd suggest using a waveform datatype instead of dbl's to pass into the graph. That way the dt can be specified in the datatype and you don't have to scale the x axis. Hopefully that will help you avoid the problem.

good luck!
Chris

[Kjell-E]

[edit] I have not tried to build it to a waveform fix that was suggested yet. [\edit]
Update:

There might be more to this bug than first meets the eye.

During the day, I've run my app' on and off probably a couple of hundred times, modifying and changing things. During one(!) of the runs, 2 of the 3 labels were displayed at the correct location, while the rest were not.

(Note that I generated a bunch of invalid markers due to a threshold level that was set to low.)

When I re-ran, (after changing the incorrect threshold), it was back to the way it used to be, i.e. labels are all in incorrect positions.

Figured I'd let whoever reads here know that the bug is non-constant and has some odd behavior.

Message Edited by Kjell-Edmund on 04-11-2008 05:26 PM

Message Edited by Kjell-Edmund on 04-11-2008 05:26 PM

[MeghanK]

Thank you for bringing this to our attention.  I will add your notes to the existing CAR.  Please let us know if you notice any other unusual behavior or potential bugs when using LabVIEW.  We are working hard to resolve these issues for future versions of LabVIEW.  Have a great day!

[ASTDan]

Was this bug fixed in the new version of LabVIEW?

I couldn't find it in the bug list.

Thanks

Dan

[Kameralina]

Hello,

I am glad to inform you that the issue related to Corrective Action Request (CAR) 4GIEK3TP has in fact been fixed in LabVIEW 8.6.

Have a great day!

[beuvink]

Is it sure the issue is solved in 8.6? I am using 8.6 but I still cannot control the label position correctly when scale offset and multiplier are used. I made a debug vi to play with offsets and multipliers. I tried to find a relation between offset, multiplier and label offsets but this was harder then expected....

Anyone has experience with this?

Kind regards,

Mark

[beuvink]

Couldn't resist to investigate further... seems like a bug but with a very strange formula there is a work around. See attachment. Please confirm that this is a bug, I will then start a bug report.