Jump to content

Graph Cursor XY Position Bug


Recommended Posts

I discoverd this bug after a few hours of checking and rechecking a peak detection algo - using cursors to display the 'found' peaks in a graph. However, my algo was find points just before or after the peaks... :headbang:

Well my algo was correct - I was chasing a bug in the graph cursor XY position property. As bewildering as the properties are there is a property under cursors a cluster called "Cursor.Position" who's elements are X,Y. I was wiring the data to that property only to find that although I input the X value of 0.0476 (in units of time - it's a waveform graph) LabVIEW was putting the cursor on the 0.477 index !?!?!. It can't be a rounding issue the number I input is much closer to the proper value then the one the graph choose on its own...

Even reading back the Cursor properties immediately after setting it - showed it simply ignored my input value and choose the next X axis point over. :lightbulb:

However, there is ANOTHER property called "Index" expressed as integer for the X axis - wiring the index there - DOES cause the cursor to actually locate to the desired point.

This is one of those times where a stupidly simple 'cute' features burns time like an x-wife on her spouses VISA card. Sheeze!!!

Jack Hamilton

Link to comment
  • 2 weeks later...

Mike

I would, but I burned so much time on that project 5+ hours on the cursors. I just can't bring myself to go there again!

I did learn that the problem really is with wfm datatypes passed to the graph and the X axis being in time. As we all know X-axis time plotting has always been whacky :wacko:

You have can't pass the X position value as an integer, you have to take the index and / dt value to get the 'time' position on the x axis.

If I run into it again I'll holler.

PS: They made some changes to this in LabVIEW 8

Regards

Jack Hamilton

Link to comment
  • 2 years later...

QUOTE(JackHamilton @ Apr 15 2005, 07:34 AM)

I discoverd this bug after a few hours of checking and rechecking a peak detection algo - using cursors to display the 'found' peaks in a graph. However, my algo was find points just before or after the peaks...

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.

Fraser

Link to comment
  • 5 months later...

QUOTE (fjharris @ Jan 23 2008, 05:36 PM)

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.

Fraser

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

Link to comment
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.