Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue
-
I wasn't guessing - I know what is going on.
You may not like the way it is currently done - but it is what it is.
Put in a request to have it done differently.
Frederick
-
@fcwilt said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
I wasn't guessing - I know what is going on.
And yet your description doesn't at all match the situation described, does it? Let's examine your "I know what's going on" that clearly shows you didn't read my post:
You are seeing the destination of the current move.
The "current move" at the time that the Z value changes doesn't change the Z value. In fact, the change of the Z value is TWO MOVES LATER.
Starting at X=0 if you execute G90 G1 X100 F100 the DWC reports X=100 at the start of the move even though it takes a good while for the move to complete.
That's great. What does it have to do with what I'm reporting? Not much. If I try to fit your statement into my report, what's happening isn't that the firmware is reporting "X=100" in the situation. It's reporting X=-210. The only time X goes to -210 is two moves IN THE FUTURE.
Please, spend the time to actually read things before replying.
From my further research, it appears that the "userPosition" object model variable is reporting the result of a buffered gcode command that isn't currently being executed, and even isn't the next command to be executed, but something buffered to be executed 2 moves later.
-
@garyd9 said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
From my further research, it appears that the "userPosition" object model variable is reporting the result of a buffered gcode command that isn't currently being executed, and even isn't the next command to be executed, but something buffered to be executed 2 moves later.
That is a generally correct analysis.
You and I are using "current" to refer to different things. So if we reserve "current" for the command currently being executed we need a term to refer to the command that was last parsed.
Frederick
-
@fcwilt said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
You and I are using "current" to refer to different things. So if we reserve "current" for the command currently being executed we need a term to refer to the command that was last parsed.
I believe I used the term "current reality" in my original post. I've edited since, so I can't be sure, but I'm pretty sure I explicitly used the term "reality." Most people accept "reality" to be that which they can touch, see and feel.
What is being buffered is usually a virtual concept. It doesn't yet exist, and outside of attaching a debugger, there's no way to actually know what might be being buffered/parsed by the firmware at any instant in time. (I used the term "usually" here because I'm referring to normal and typical usage and not unusual cases like running M122 to see the buffer or inserting M400 after each and every movement command.)
All that being defined in simple terms, the problem is that a USER interface claims to display the "Tool Position", but the reported "Tool Position" doesn't match the current physical reality. What may or may not be in some virtual buffer or might happen in the future is irrelevant. The user, for example, might see DWC/PanelDue claiming Z=50 when they can also see the tool is actually at Z=0. (And what might be worse is that the user sees DWC claiming Z=50, and then taking some action as a result of the erroneous report.)
It is also possible that if the "Tool Position" USER interface is actually showing some position that is predicted 2 moves in advance, that the reported "Tool Position" never occurs because of the firmware detecting an error and aborting.
-
I think you should enter a request in the firmware wish list section to have the DWC and PanelDue be able to display the command that is currently being executed. I don't think that information is now available for display.
It also might be possible to have the firmware feed the DWC/PanelDue the actual current position rather than the target position as specified in the command - would that be of beneifit?
Frederick
-
@fcwilt said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
I think you should enter a request in the firmware wish list section to have the DWC and PanelDue be able to display the command that is currently being executed. I don't think that information is now available for display.
This thread has nothing whatsoever to do with displaying "the command that is currently being executed." It's only about what is displayed as the "tool position."
It also might be possible to have the firmware feed the DWC/PanelDue the actual current position rather than the target position as specified in the command - would that be of beneifit?
Your statement erroneously implies that DWC/PanelDue is displaying the target position of the currently executing command. It IS NOT. That's what this bug report is about.
@fcwilt So far, your involvement in this thread has been more harmful than helpful. Instead of contributing to the report or showing that there is no bug, all you've done is to dilute the thread with false statements and wild geese. Please go away.
-
@garyd9 said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
@fcwilt So far, your involvement in this thread has been more harmful than helpful. Instead of contributing to the report or showing that there is no bug, all you've done is to dilute the thread with false statements and wild geese. Please go away.
You are wrong so I will let you carry on believing things that are not true.
Frederick
-
@fcwilt said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
@garyd9 said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
@fcwilt So far, your involvement in this thread has been more harmful than helpful. Instead of contributing to the report or showing that there is no bug, all you've done is to dilute the thread with false statements and wild geese. Please go away.
You are wrong so I will let you carry on believing things that are not true.
Frederick
So says the person who trolls a thread without even bothering to repeat the issue reported.
-
@garyd9 said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
So says the person who trolls a thread without even bothering to repeat the issue reported.
I know why the DWC/PanelDue shows what it shows.
You don't like it and I agree there is a better way.
You just need to post your request to the firmware wish list.
It's as simple as that.
Frederick
-
@garyd9 The reason why the positions are slightly off is because the OM reports the user/machine positions of the last processed move, which are usually needed in macro files when using conditional G-code and expressions. But I understand this may be a bit counter-intuitive and we may replace it with actual "live" values at some point, but @dc42 and I have not yet decided when and how in detail.
Btw you can click on "Tool Position" on the web interface to change to the machine positions.
-
@chrishamm said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
@garyd9 The reason why the positions are slightly off is because the OM reports the user/machine positions of the last processed move, which are usually needed in macro files when using conditional G-code and expressions. But I understand this may be a bit counter-intuitive and we may replace it with actual "live" values at some point, but @dc42 and I have not yet decided when and how in detail.
Btw you can click on "Tool Position" on the web interface to change to the machine positions.
I can completely understand why the userPosition is desired for running macro's. I'm not sure how that relates to what is displayed by DWC as "Tool Position."
Compare it to medical equipment and take it to an extreme: If you were are on a device that monitors your heart beat, you might expect to see a number such as 75bpm. What if the monitor instead displayed 0? Would you be happy with the explanation of "well, it's showing what your heartbeat WILL be... and we all die eventually."
Perhaps a bit less of an extreme, the altimeter of an airplane: It would make flying the plane much harder if the plane's instruments reflected the planes projected state instead of it's actual physical state.
Of course, now that you've told me switching to machinePosition is as trivial as a click, I might not care.
I wonder if @wilriker would be willing to add a similar toggle to PanelDue."I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
Sorry, I hope I am not too unpolite by jumping in at that place (but after all it is a public forum...) If you have a similiar idea, please post it, I could imagine something like this:
@wilriker
-
@LB
I don't understand what you are posting/suggesting. -
@garyd9 said in Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue:
Of course, now that you've told me switching to machinePosition is as trivial as a click, I might not care.
I wonder if @wilriker would be willing to add a similar toggle to PanelDue.I intend to provide this possibility but due to the limited screen estate I have to carefully work out where I can make space for a button or similar.
