I am using the SKR Pro 1.2 with attached TFT35 on my MPCNC Primo and also control the firmware externally with repetier-host. GCode is processed by Fusion 360 (flyfisher604’s postüprocessor).
Usually I use local (TFT35) jogging to move the router to the starting postion after homing XY and initiate the script for my Z touch plate (5mm block) at this position from within repetier-host. Back at the machine I remove the touch plate and jog Z to zero.
I run the job with a single tool.
If I have to switch tools I do it at the XY home postion and repeat my steps to home Z at the starting postion (e.g. the corner of the stock).
Here I frequently run into problems where my commands at the smart-TFT have an unwanted effect.
A single Z-step drives the bit into the stock. Or X movement toggles between -1 and +1.
I guess there is plenty room for improvements but what causes these effects. Is it a battle between both control-methods or an sync-error of the position. What is a safe way to switch between repetier-host and and the smart-display?
I don’t have a TFT to test, so I may have the exact scenario wrong, but I’m pretty sure that:
The TFT and/or Repetier-Host are “dumb” in that they send g-code and assume position, but don’t query the current position from the control board.
The TFT and/or Repetier-Host use absolute positioning.
So, imagine that you raise your Z axis using the TFT from 0.0 to -10.0, then you go to Repetier-Host and ask it to raise by an additional -1.0mm. RH thinks it is at 0.0, so it sends it to -1.0 (absolutely), but -1.0 is really -9.0 down from the current position, so instead of going up by -1.0, it descends 9mm.
The only way I can think of to fix this problem is to make sure that the control board, TFT and Repetier-Host all consider the machine at 0 before making the switch. Note there is a special command in Repetier-Host for setting home that does not go to the control board: @isathome. See this page. G92 will set the position for both control board and whatever is sending the code.
This totally makes sense. I thought during jogging there would be relative postioning, but if there is a comparison between the internal state and the reported postion from the firmware this explains perfectly what is happening.
I have to think about it and also have a look at the gcode i am sending during jogging.
Issuing a M114 should sync the position also, won’t it?
Jogging in Repetier-Host does send a relative G1 move but also updates the position on the smart-controller. Strange, unless it is polling?
Please look at the following sequence:
I send an M114 from repetier host after jogging with the smart display to random position
→ The position between both controllers is now identical
I jog X +50 from RH
→ The MPCNC suddely does a huge movement (>50) to +x (possibly the absolute X position?). This already could habe crashed the gantry.
I jog X -50 from RH to return to a safe postion
→ The MPCNC does move 50 (extimated) in the positive X-direction again and crash almost in the mechanical endstop
How does this make any sense?
There was no change in the coordinate system through homing. Only relative positioning.
Until I understand what is going on I will avoid any jogging from RH at all cost.
How do I debug that?
Again, I don’t have a TTF display, and I only rarely use Repetier-Host, but I don’t believe this to be the case. The M114 does report the current position, but I believe that Repetier-Host does not make use of that position to reset where it thinks it is. It is only being output for you to read. Note you can program the optional buttons in Repetier-Host, and you can program them for relative movement…kind of an ugly hack.
The exact same command is interpreted differently depending on whether the machine is set for absolute or relative positioning. This can be changed on the fly.
G90 sets the machine to “absolute positioning.” In this mode the command G01 X10 is telling the machine to “Move to 10 units positive of the machine zero position.”
G91 sets the machine to “relative positioning.” In this mode, that same command - G01 X10 - now means “Move to 10 units positive of the machine’s current position.”
I don’t believe that the output of M114 gives any indication whether you’re in absolute or relative mode. I think M503 will tell you without making any changes.
Also, I agree with @robertbu - I don’t believe that Repetier Host “listens” to the M114 to update it’s understanding of where the tool is within the machine space. There is a RH command - @istathome- that you can use to “sync things up” but I think it only works when you’re really at 0,0,0.
My suggestion is to use one interface or the other to jog the machine, but don’t mix inputs.
(edit - corrected the RH command based on @jeffeb3 response below)
The @isathome is a command just for RH. I believe it gobbles it up and doesn’t send it on to Marlin. I am not sure if M114 is treated the same way. I would prefer forcing RH to know where I was, but if you can’t (or don’t want to) send it to 0,0,0, then I am not sure if it will work.