Bug in 3.2.2: X/Y/Z positioning wrong in DWC and PanelDue
-
RRF 3.2.2 (same versions of DSF, DWC, etc.) SBC mode on a Duet3
(Note: I'm editing this first post the clarify the problem, give examples, etc, that I posted in later replies. The hope is that a moderator can clean the false answers and arguing from the rest of the thread and just leave this first post with the bug report.)
The tool position indicators for both DWC and Paneldue are reporting values that are actually ahead of reality by at least two moves. A good example is the Z axis. When RRF is nearly done with a layer (but isn't quite done), both DWC and PanelDue report the Z height of the NEXT layer.
My guess on this is that the object model is reporting (and DWC/Paneldue is reading) the Z (and other axis values) for the mostly recently cached gcode command, and NOT the axis value for the most recently executed gcode command.
Here's an example taken from real gcode generated by prusaslicer using a 100mm cube with 1 wall, no infill (and the z-seam in the middle of the front face.) Comments with "***" were added by me after copying the gcode to clarify what is going on.
;HEIGHT:0.2 ; 0.2mm layer, 8 bands 5mm each, total height 40mm M572 D0 S0.0 ; ****************************** Z IS ABOUT TO MOVE TO 0.4mm *** G1 Z0.400 F7800.000 G1 X-6.450 Y-49.775 ;WIDTH:0.45 G1 F1800.000 G1 X49.775 Y-49.775 E27.55238 G1 X49.775 Y49.775 E30.92203 G1 X-49.775 Y49.775 E34.29168 ; ****************************** SOMEWHERE AROUND HERE DWC SHOWS Z AT 0.6mm *** G1 X-49.775 Y-49.775 E37.66133 G1 X-6.510 Y-49.775 E39.12579 ;LAYER_CHANGE ;Z:0.6 ;HEIGHT:0.2 ; 0.2mm layer, 8 bands 5mm each, total height 40mm ; ****************************** HERE IS WHERE Z ACTUALLY CHANGES TO 0.6mm **** G1 Z0.600 F7800.000When the above gcode executes, I notice DWC and PanelDue showing a Z of 0.6 some time during the movement of "G1 X-49.775 Y-49.775 E37.66133" (which is two moves before Z goes from 0.4 to 0.6.) As both DWC and the PanelDue tool positions are somewhat delayed (due to polling), I can't know exactly when RRF is representing the Z axis as being at 0.6mm - only that it's obviously happening earlier than the position really is at 0.6mm
This is most noticeable when printing shapes that have long single moves immediately before a layer change.
The easy way to reproduce this is to slice a 100mm cube with no infill, no top or bottom, and only a single wall. Set the print speed to something slow like 10mm/sec. When printing that object, after a z move, watch DWC/Paneldue during the full layer and note when DWC/Paneldue shows that Z changes compared to when Z actually physically changes.
I'm wondering if this is related to the fact that Paneldue (and perhaps DWC) are reporting the tool position from move.axes[n].userPosition in the object model. That value APPEARS to be the culprit. In the above example, it's showing my Z at 0.6mm before the Z movement actually happens (the same as DWC/PanelDue does.) Interestingly, move.axes[n].machinePosition seems to be showing the correct value at the correct time.
-
You are seeing the destination of the current move.
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.
I don't believe the firmware issues a stream of data reporting the current position of the tool.
Frederick
-
@fcwilt said in 3.2.2: X/Y/Z positioning wrong in DWC and Panel (object model?):
You are seeing the destination of the current move.
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.
I don't believe the firmware issues a stream of data reporting the current position of the tool.
Frederick
No, I'm NOT seeing the destination of the current move. Please spend the time to read my message. It very clearly states "Around this time, PanelDue and DWC both show Z is at 0.4, but RRF is still executing two moves at Z 0.2." If it's showing 2 moves before the movement of Z, it kind of negates your idea.
(If my reply is hostile, please pardon me. I'm just very sick of people replying to issue reports when they either don't bother to read the problem, they're replying with something that has nothing to do with the report, or they are obviously just clueless.)
I'll spell it out even more clearly to HOPEFULLY prevent more people from replying with wild guesses that don't apply.
Here is real gcode created from prusaslicer using the example I provided in the original post (with a Z seam forced near the middle of the front face.) Comments with "***" were added by me after copying the gcode to clarify what is going on.
;HEIGHT:0.2 ; 0.2mm layer, 8 bands 5mm each, total height 40mm M572 D0 S0.0 ; *** Z IS ABOUT TO MOVE TO 0.4mm *** G1 Z0.400 F7800.000 G1 X-6.450 Y-49.775 ;WIDTH:0.45 G1 F1800.000 G1 X49.775 Y-49.775 E27.55238 G1 X49.775 Y49.775 E30.92203 G1 X-49.775 Y49.775 E34.29168 ; *** SOMEWHERE AROUND HERE DWC SHOWS Z AT 0.6mm *** G1 X-49.775 Y-49.775 E37.66133 G1 X-6.510 Y-49.775 E39.12579 ;LAYER_CHANGE ;Z:0.6 ;HEIGHT:0.2 ; 0.2mm layer, 8 bands 5mm each, total height 40mm ; *** HERE IS WHERE Z ACTUALLY CHANGES TO 0.6mm **** G1 Z0.600 F7800.000First of all, notice that all the Z movements are independent of any other movement. If your (incorrect) guess was accurate, then the problem wouldn't occur with this gcode, because the only time Z moves is when there is no other movement in X and Y.
When the above gcode executes, I notice DWC and PanelDue showing a Z of 0.6 some time during the movement of "G1 X-49.775 Y-49.775 E37.66133" (which is two moves before Z goes from 0.4 to 0.6.) As both DWC and the PanelDue tool positions are somewhat delayed (due to polling), I can't know exactly when RRF is representing the Z axis as being at 0.6mm - only that it's obviously happening earlier than the position really is at 0.6mm
"I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."
-
To clarify even more, PanelDue is reporting "move.axes[2].userPosition" (2 is my Z axis) for the tool position.
From examining the object model, I think the CORRECT value that accurately reflects the machine state would be move.axes[2].machinePosition (not userPosition)
@chrishamm , I don't know what DWC is going, but it's likely doing the same thing. At least the "tool position" values appear to be wrong in the same manner as the PanelDue (however, I'm not brave enough to jump into the DWC code. I've never bothered to become fluent with web-based languages.)
Unless, of course, it's intended that the two tools show a tool position that hasn't happened yet.
-
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.
