Re: Control Panel v2.1 Build 25f Virtual Zero
Posted: Thu Apr 06, 2017 2:22 pm
Tim:
Thanks for the video; my comments here are to try and see if there's a way around it for you, in case it continues to take time for them to get you running. These are the steps and thinking I would use to debug this situation.
I can confidently assert that the root of the positioning problem is the same problem that causes the displayed coordinates to be wrong. Okay, written like that it sounds obvious, doesn't it :-O.
Just for completion, can you also get the controller firmware versions? It says that in the lower-right of the control panel splash screen, IIRC. Are they the same? Are they correct for what's required for the control panel software version?
There's a setting in the ^G 787 dialog for setting the percentage for rapids/jogging. Check that value, but I suspect it's probably fine. 60-70% is typical; you don't often want to jog at the machine's maximum speed...crashes can happen way too fast .
I suspect, based on what you've shown, that the calculation and accumulation of the ordinate (x and y AND z...remember how it was up in the air?) distance values (the ones displayed by the control panel) are being calculated at a different "effective step-per-mm" than the actual steps being sent out, and that that step size is being (inadvertently?) affected by the jog feedrate settings. The actual number of steps sent to the motor appear to be individually sent out as JOG commands, which as you saw, proceed at the speed set in the jog panel. I say "effectively" because there are several places where a calculation error could appear like it was that type of error, even if the actual numeric error was not in steps-per-mm.
I conjecture that the value shown in the display is the "desired" location, however the number of steps being sent to the steppers is being calculated improperly.
You can test this theory by allowing the incorrect movement to occur, and cancelling the virtual-Z without allowing the router to move back. Then, take the X or Y value from the location display; type that into the "step" increment value, and jog ONCE in the appropriate direction. I conjecture that the head will in fact NOT move back to your zero, because the number in the display is actually NOT how the virtual-Z system moved the motors. Why? Because the virtual-Z command issued "jog at whatever I told you last time" commands instead of "jog this specific amount" commands. If you move the jog setting to (by sheer luck) the proper step increment, I conjecture it might effectively get around the miscalculation. Watch carefully, however, in case the displayed values CHANGE when you cancel the virtual-Z (again, don't allow the system to move it back). If they change, then the problem is proven, and you don't need to run that test .
(Please prove me wrong, Joseph, like you always so excellently do, what with it being your software, and all I have are conjectures )
I believe you might be able to get around this using the following, until they fix the problem:
1) Set the 25f offset/margin value to be -1.0 (yes, negative 1.0)
2) Change the jog settings to 0.001", and set to use step, not Fast, Not Medium, not Slow. Step. (I believe that will force the individual jog movements to accumulate the same amount as the separately-calculated displayed values.)
3) Run the virtual-Z again.
If the router then moves to what we believe is the appropriate location, then my conjectures are correct. If not, then it's something else, and we'll think harder .
You might find that step 1 above isn't really needed, if the properly-calculated (displayed) value correctly incorporates the offset value you put in.
looking back over the numbers you posted earlier, it's possible that which display/steps is "right" could be reversed from my conjecture; One of them is wrong; that's for sure .
Thanks for the video, Tim. Even at that level of "quality", there was plenty to see, and very few things I felt were not there that I needed to see the whole picture. Bravo! I encourage other members with complicated problems to be this thorough in documenting your Shark issues . Not only does it make figuring it out easier, but it makes it tons faster for NWA to understand where the problems might be coming from.
And finally, there is always the distinct possibility that the "margin" might have changed from meaning "distance in from edge of material" to meaning "distance out from edge of design", but they didn't make it clear in the display. Maybe they're not reading the radio-button settings right? Could be anything .
I hope at least some of that helps.
Regards,
Thom
Thanks for the video; my comments here are to try and see if there's a way around it for you, in case it continues to take time for them to get you running. These are the steps and thinking I would use to debug this situation.
I can confidently assert that the root of the positioning problem is the same problem that causes the displayed coordinates to be wrong. Okay, written like that it sounds obvious, doesn't it :-O.
Just for completion, can you also get the controller firmware versions? It says that in the lower-right of the control panel splash screen, IIRC. Are they the same? Are they correct for what's required for the control panel software version?
There's a setting in the ^G 787 dialog for setting the percentage for rapids/jogging. Check that value, but I suspect it's probably fine. 60-70% is typical; you don't often want to jog at the machine's maximum speed...crashes can happen way too fast .
I suspect, based on what you've shown, that the calculation and accumulation of the ordinate (x and y AND z...remember how it was up in the air?) distance values (the ones displayed by the control panel) are being calculated at a different "effective step-per-mm" than the actual steps being sent out, and that that step size is being (inadvertently?) affected by the jog feedrate settings. The actual number of steps sent to the motor appear to be individually sent out as JOG commands, which as you saw, proceed at the speed set in the jog panel. I say "effectively" because there are several places where a calculation error could appear like it was that type of error, even if the actual numeric error was not in steps-per-mm.
I conjecture that the value shown in the display is the "desired" location, however the number of steps being sent to the steppers is being calculated improperly.
You can test this theory by allowing the incorrect movement to occur, and cancelling the virtual-Z without allowing the router to move back. Then, take the X or Y value from the location display; type that into the "step" increment value, and jog ONCE in the appropriate direction. I conjecture that the head will in fact NOT move back to your zero, because the number in the display is actually NOT how the virtual-Z system moved the motors. Why? Because the virtual-Z command issued "jog at whatever I told you last time" commands instead of "jog this specific amount" commands. If you move the jog setting to (by sheer luck) the proper step increment, I conjecture it might effectively get around the miscalculation. Watch carefully, however, in case the displayed values CHANGE when you cancel the virtual-Z (again, don't allow the system to move it back). If they change, then the problem is proven, and you don't need to run that test .
(Please prove me wrong, Joseph, like you always so excellently do, what with it being your software, and all I have are conjectures )
I believe you might be able to get around this using the following, until they fix the problem:
1) Set the 25f offset/margin value to be -1.0 (yes, negative 1.0)
2) Change the jog settings to 0.001", and set to use step, not Fast, Not Medium, not Slow. Step. (I believe that will force the individual jog movements to accumulate the same amount as the separately-calculated displayed values.)
3) Run the virtual-Z again.
If the router then moves to what we believe is the appropriate location, then my conjectures are correct. If not, then it's something else, and we'll think harder .
You might find that step 1 above isn't really needed, if the properly-calculated (displayed) value correctly incorporates the offset value you put in.
looking back over the numbers you posted earlier, it's possible that which display/steps is "right" could be reversed from my conjecture; One of them is wrong; that's for sure .
Thanks for the video, Tim. Even at that level of "quality", there was plenty to see, and very few things I felt were not there that I needed to see the whole picture. Bravo! I encourage other members with complicated problems to be this thorough in documenting your Shark issues . Not only does it make figuring it out easier, but it makes it tons faster for NWA to understand where the problems might be coming from.
And finally, there is always the distinct possibility that the "margin" might have changed from meaning "distance in from edge of material" to meaning "distance out from edge of design", but they didn't make it clear in the display. Maybe they're not reading the radio-button settings right? Could be anything .
I hope at least some of that helps.
Regards,
Thom