Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[Marlin] CNC.js Axis widget instantly stops displaying machine coordinates when I switch to G54 #514
A Marlin bug was fixed a few days ago that will positively affect CNC.js:
A request for enhancement that will positively affect CNC.js is being looked at:
There is a last issue I could use some help with:
When I switch from machine coordinates (G53) to work offset coordinates (G54) in Marlin by simply entering "G54", the Axis widget shows work coordinates of X,Y,Z 0,0,0 which is correct. However, the machine coordinates instantly change to X,Y,Z 0,0,0 as well. This behavior is incorrect - the machine coordinate system digital read-out (DRO) should ALWAYS display machine coordinates. When I enter "G53" to switch back to machine coordinates, the machine coordinates are instantly displayed correctly. It appears Marlin does not provide data for both machine coordinates and work coordinates to CNC.js simultaneously, or perhaps CNC.js does not interpret the data correctly, not sure.
Any suggestions would be appreciated.
You surmise correctly that Marlin only reports one set of coordinates. Historically, Marlin only had machine coordinates, so in order to retain UI consistency across different controllers, CNCjs just displays whatever Marlin reports in both the machine and work DROs. Now that Marlin supports coordinate systems that may need to be rethought. It will not be easy since, unless Marlin changes its reports to make both sets available, CNCjs would have to snoop on the GCode and infer the coordinate offset. That has its own set of problems; suppose, for example, that Marlin rejects a coordinate-offset change command for whatever reason. That would greatly complicate the logic for maintaining the correct offset. It is one of those kinds of problems that makes programmers grind their teeth - very difficult to get it right in all cases, and users are guaranteed to trip over all the corner cases.
That is why I am somewhat skeptical of your claim that the proposed change will "positively" affect CNCjs. To my way of thinking, it will make it even harder to make Marlin support work well. Marlin's serial protocol feels like an afterthought. Marlin works really well in the 3d printing use case especially when driven from a controller-attached LCD. Driving it from a serial line via CNCjs is fraught with difficulty mostly arising from timing issues around status reports and interference between status reports and GCode transmission. I think it is unfortunate that MPCNC chose Marlin. I understand why they did so - coming from the 3D printing world, the designers were presumably very familiar with Marlin and RAMPS boards, so that was the path of least resistance. But as I see it, Marlin is just not that good for milling. It might get better over time, but the road will be rocky and will cause a great deal of work for CNCjs developers to track the developments.
The other problem is that the coordinate support is optional, so many or most Marlin users will not enable it. That compounds the support problem, since you have to cope with both possibilities in order to handle a capability that, for a long time, will only have a very few users. And with few people using it, bugs will take longer to surface and be fixed.
I would also point out that Marlin's handling of G53 is idiosyncratic. On other machines, G53 is non-modal, affecting only the current line. The next line is supposed to automatically revert to the previous WCS (G54..G59 ). That further complicates Marlin support because you would need a GCode recognizer that understands Marlin quirks (of which there are many).
Thank you very much for your detailed response - most insightful.
My apologies for causing alarm. You have provided very useful insights that are new to me. After having carefully read your response I hope I can ease at least one of the concerns:
"Positively affect CNC.js"
CNC.js shows the same coordinates in both DROs at all times. This is because Marlin only outputs one set of coordinates as you state.
I feel your concerns are mainly centered around Marlin quirks i.e. not outputting 2 sets of coordinates and not so much Marlin bugfix #14743. I understand your concerns and would have to agree not outputting 2 sets of coordinates -whilst acceptable for 3D printer use- makes it somewhat challenging for CNC machine use.
Marlin's serial protocol feels like
I would also point out
G10 L20 P1 X0 Y0
The negative effect is that the expectation that CNCjs should support this new Marlin feature that does not yet work very well creates extra work for the already-overworked main developer. The fact that the Marlin serial protocol has design problems makes it hard to even estimate the difficulty of supporting it correctly.