Annotation Label Offset Explanation

[Rob_Calhoun]

This bug was resolved in LabView 2009 (at least for my use case) but has returned in LabView 2010. 😞

We use waveform graphs with an absolute time axis (e.g. X-axis min = "2010-10-08 11:45:00" and X-axis max = "2010-10-08 11:45:30") and denote various important points on the graph with annotations. We plot multiple waveforms on the same plot, using a custom Y scale for each so that we can offset the waveforms without offsetting the data.

In LabView 8.5, we had to apply various goofy offsets (- xScaleOffset if I remember correctly) to the label positions in order to get them to appear with an effective offset of 0. In LabView 2009 we didn't need to do this: simply setting the index for the annotation correctly and setting Label Offset to (0,0) was sufficient. After upgrading to LabView 2010, the annotations labels are all floating far off the right side of the graph again. My old workaround didn't work.

Thanks to Chris Minella's diligent efforts at documenting this, I can apply his LabView 8.6 workaround, which is:

set Label Offset.X = (Position.X - XScale.Offset) / XScale.Multiplier - Position.X

Notice that the first term computes the index of the annotation itself in samples (like "11025") while the second is a real world value (i.e. "seconds from 1904-01-01", which is 3-billion-something seconds.) The units don't make any sense.

Note that annotations appear correctly if you right-click, Add Annotation, but if you pull them out of the graph with the Annotation List property, clear the graph, and then put exactly the same Annotation data back on the graph using Annotation List, it doesn't work.

When I have time I'll post a an example, but Chris' examples above still document the bug as well as any I can make.

And Chris, thanks for your efforts on this.

-Rob

[minnellac]

Here's hoping that somewhere within the bowels of NI, right hand meets left hand.

[Walter_Rebsch]

I have code that ran fine in LV 2009, and now that upgraded to LV 2010, the annotations are completely crazy (except when scale multiplier = 1).  So I would like to confirm, something got goofed up in LV 2010.  I am going to try the previous ver 8.6 workout and see if that fixes it.

Special thanks to 'C Minnella' for researching this.  It was driving me nuts trying to figure this out.  I thought it was something I did since I was working on code near this code when I upgraded labview versions and I couldn't figure out what I did to break it.

I also can report that SOME of the screen refresh issues for the annotations that abounded in 2009 are fixed, but moving annotations around tends to leave parts and pieces of labels in random spots.  Also, some of the arrows have weird discontinuities occasionally.  The problems only seem to occur when the xscale multiplier is not equal to 1.  So probably the code that invalidates rectangles for the graphics driver to redraw has a similiar bug in it to the part that places the text.

It also seems to snap to the wrong point sometimes.  I can confirm I am writing the proper values to the annotation point location in a probe, but it seems to snap strangly.  For example, if I slowly move an annotation along a graph trace that has a large spike in it, as I 'walk' the point along the trace and up the spike, it sometimes snaps to the opposite side of the spike suddenly, then I keep going up, and it snaps back after a few more steps.  Anyway, the snap algorithm has some flakiness in it too, fyi ... this problem has remained identical from 2009 to 2010.

[Kristoff2]

Hello,

Thank you for bringing this to our attention.  I have tested and confirmed that this issue has reappeared in LabVIEW 2010 and have reopened the corresponding CAR.

Regards,

Sam K

Appications Engineer

National Instruments

www.ni.com/support

[WalterR]

I finally fixed my code.  I'll attach below screen shots of the fix.

The first pic is where I create my annotations.  Here, all the input units of X,Y, X Scale Max, Y Scale Max are in SCALED units.  After I define them properly in scaled units, I "unscale" them with a divide (but only for the offsets!).  This piece of code places the labels in a proportionally nice place on the screen.  Thus if the annotation is greater than 70% of the way to the right side of the graph, it offsets 20% negative instead of 20% positive.  Likewise, if the annotation is close to the top of the screen, it offsets below the trace instead of above it (which would clip offscreen).  All my graphs start at 0, so I don't need to check X and Y minimums since they are always 0.  And depending of if the label is long or short, I offset it slightly different in each case.

Then after I create all my annotations by calling the above VI several times.  Then I run the whole list through the following "corrector" to fix it.  This code is based on the previously posted 8.6 fix from 'C Minnella'.  (Thanks again!!)

Now the annotations land where they are supposed to be, regardless of if the X Scale Multiplier is greater, less or equal to 1.  Of course none of this is necessary if the X Scale Mult is always equal to 1.

I still don't have any workarounds for the screen redrawing bug that leaves parts and pieces of the annotation labels on the graph when they are moved around.  My current workaround for the snap problem is to not use snapping.  I do my own linear interpolation of the data and place both X and Y coordinate in a free cursor, then detect for changes in X by the user and manually snap the Y myself.

[josborne]

Hi folks,

This appears to be an old thread about LV2010.  I was wondering if someone could comment here (or in this thread) about annotation label offsets in the latest version (LV2011). 

I would expect by now, NI has worked out these issues.  But I am still having trouble getting my label offsets to function correctly.

A simple explaination of the units of LABEL OFFSET would help, too.

[KyleP]

I see that you also posted in this thread and it appears that Josh has answered your question. Please refrain from posting the same question in multiple threads in the future. Hopefully this solves your issue.