XY graph cursor position bug

[fjharris]

I have reproduced the bug mentioned here:

http://forums.lavag.org/Graph-Cursor-XY-Position-Bug-t1366.html&gopid=40859#entry40859

I've reproduced this bug (?) in Labview 8.5, with an XY graph doing much the same as Jack. The attached zip file contains a stripped down version of my program (originally written by my coworker, Andrew MacDonald). Run "RENA3 Data Viewer.vi" and follow the instructions.

As Jack said, changing Cursor.PosX to Cursor.Index solves the problem.

I did not find this bug mentioned anywhere other than the above link.

Fraser

[CarlaU]

Hi Fraser,

I have been looking at the VI from your earlier post and I am having trouble seeing what the bug is that you are talking about. I followed the steps of the VI, but can you specifically tell me what I am seeing and what I should be seeing (if there was no bug)? I would really appreciate the help so I can make sure that this gets documented. Have a great evening!

Carla

[fjharris]

Hi Karla,

Sorry if that wasn't as obvious as I thought! 🙂  Hopefully the attached image makes it clear.  On the front panel, 'Cursor Channel' is inputted.  This is directly wired to Histogram.Cursor.PosX.  Immediately following, Histogram.Cursor.PosX is read and wired to the front panel indicator 'Cursor.Cursor Position:Cursor X'.  There is always a difference of 15 or 16 between the two values.  If there was no bug, these two values should be identical!  I can only conclude that Labview is doing something funny...

As I mentioned before, changing Cursor.PosX to Cursor.Index fixes the problem.

A bit of background:  my FWHM function outputs the peak channel, and the cursor is supposed to go through the peak so you can have a visual check that it is analyzing the right peak.  I noticed that the line would never go through the peak; the line would always have an offset.  After wasting a couple of hours, it became clear that I was wiring the correct value into 'Cursor.PosX', but something was going wrong beyond that.

Cheers,

Fraser


Message Edited by fjharris on 01-25-2008 11:34 AM

Message Edited by fjharris on 01-25-2008 11:36 AM

[RavensFan]

I notice one thing about your screenshot.  And this may be the intended operation, or maybe not.  You set the cursor positions for the histogram in a sequence frame that occurs before you write the data to the histogram.  What happens if the X position doesn't exist in the new histogram?  Or it did not exist in the previous histogram because that indicator would still hold the old data because it doesn't get the new data until the next sequence frame?

[fjharris]

The short answer is, I have not checked.  The x-cursor position is supposed to come from the peak finding algorithm, which would restrict its value to within the dataset.  The user inputted cursor position was to focus on what appears to be a bug.  The sequence frames were put there to force order of operations while I was trying to find the source of the 'bug'.  I thought it might be possible that the histogram was only being updated every time new data was loaded, however unlikely that was.  It is clear upon testing that the cursor position is strongly correlated to the inputted value, but is always less by an amount of 15 - 16.

[CarlaU]

Hi Fraser,

Thanks for your reply. I definitely see what you are talking about now. I am going to do a bit more research but I do think it is a bug. I will keep you updated on my findings! Have a great day!

Carla

[fjharris]

CarlaU, how about that promised update?

Cheers,

Fraser

[Rio C.]

I have run into this issue when trying to set the cursor position in a waveform graph of an FFT.   I was always getting a result that was just under the value I was trying to move the cursor to programmatically.  I found that if I made the graph very large ~2000 pixels on the horizontal I would get the correct result.  Another thing is the graph has 131072 points.  I didn't want to keep my graph that large so I resorted to using index, which worked.  However, that means I have to throw in some extra calculations because the indices are not the same as the x-axis values.

Rio Christensen

[CarlaU]

Hi Fraser,

Thanks for the reply. I have looked at the issue a bit further and I agree with you that it is a bug. I have filed a Corrective Action Request so that our teams can look at it for future versions of LabVIEW. The Corrective Action Request ID is 119407 in case you want to track the progress in the future months. Like you mentioned in an earlier post, the best method to workaround this would be to use Cursor.Index instead of Cursor.PosX. Thanks again for pointing this out!

Warm regards,

Carla

[altenbach]

Seems probably related to: http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=338747#M338747