I spent most of yesterday and today trying to understand exactly how Marlin and RepetierHost play together - and my conclusion is that Repetier is quite “buggy”… I put that in quotes because the repetier dev’s seem perfectly happy with the way it works, lots of quotes from them along the lines of “why would you ever want to go negative in Z?”— sigh…
Anyway - one of the things I’ve found is that Repetier will refuse to issue Gcode that moves Z below zero (through the manual controls) - if the Z-axis has been homed. It’s perfectly happy to do so if it doesn’t believe the Z-axis has been homed (if the coordinates are in black on the manual control screen it believes the axis has been homed, red otherwise). For our setups (assuming Z0 is top of workpiece and Z+ is above the workpiece) this effectively means you should never plan on homing Z if you want to use the manual controls.
One of the other quite annoying problems is that Repetier does not “believe” the coordinates reports from Marlin, so it just flat out ignores them. This is claimed to be because G92 can cause marlin to report incorrect coordinates. Apparently it’s been brought up as an issue, but the repetier devs don’t see it as a problem.
I’ve seen mention of putting Repetier in CNC mode, and there is even a printer-type under the printer config that is “CNC Router” – but (at least on my install, which is fairly recent) it doesn’t seem to have any affect on the problems I’ve been trying to work around.
no, but the .gcode file from estlcam seems to behave exactly the same as when i try to do manual movement. It was easier to test with the controls than to start a print when changing marlin settings.
I don’t think that is true – unless you have some way of homing Z that uses the end of the bit as the reference (as if you were probing) AND you have zero-height probe thickness. Otherwise your homed position will be above the material (or table surface, depending on where you placed the probe). It would seem that in both cases you still need to move down (negative) to get to the “true” zero.
You can ‘fake’ this by using G92 Z<ProbeThickness> – but this is exactly what causes Marlin and Repetier to report conflicting coordinates. The only way around the out-of-sync coordinate condition that I’ve found is to have marlin at (0,0,0) then issue the @isathome command to Repetier, which will reset repetier’s coordinates to whatever you’ve defined as the “home position” in the printer config (0,0,0).
FWIW - the reason I feel like repetier and marlin need to ‘agree’ on the coordinates is that all manual controls in repetier issue absolute moves, so if the coords are off and you tell it to jog up/left/forward/etc 1mm - it can result in a much larger move (even in a different direction) than you planned. And I’m not comfortable with that behavior.
I have not observed this behavior. My testing leads me to believe that repetier will simply send the gcode to marlin and (unless you have software endstops enabled) it will try to move to that position.
I don’t fake it, I measure it. I use the same plate and DO use the end of the endmill. Have you seen the milling basics page and my start and tool change gcode. G28 Z, g92 ZXXX.
Maybe you’d both like to use cnc.js better? I use pronterface to set up my machines, but it will refuse to run a gcode file if there are no extrusions. Pronsole works fine, but the command line is not for everyone.
I’m pretty sure Pronterface works even with no extrusions. That’s what I always used before I set up OctoPi/V1Pi to do the sending. I’ve never used Repetier Host.
I was referring to “faking” a probe with zero thickness - by using G92 to introduce offsets into the marlin’s coordinate system (to account for the non-zero probe thickness). This is a perfectly valid/correct way of accounting for this offset. However, G92 is one of the reasons given by the repetier devs for why they no longer ‘trust’ the coordinate reports coming out of marlin (and therefor do not adjust their (repetier’s) coordinates to match). Instead they (I believe) try to track the coordinate offsets by looking for, and reacting to G92s. Unfortunately, in testing this, I have had several instances where repetier seems to ‘miss’ (or ignore?) the G92 commands, and not update it’s internal coordinates to account for the G92 offsets. Once again this leaves repetier and marlin out-of-sync. The only way I have found to get repetier and marlin coordinates back in sync is to move to a position (I am choosing to use the project origin - which requires going -Z in repetier), have this position configured in repetier as the Home coordinates (using (0,0,0) in this example), use G92 X0 Y0 Z0 to tell marlin this is the new origin, then issue the “@isathome” command to repetier, which causes it to update it coordinates to (0,0,0) also.
It’s an extra set of ‘hoops’ that wouldn’t need to be jumped if repetier allowed two things:
A flag to say ‘trust’ the coordinate reports you get back from the Gcode interpreter (Marlin)
A flag to allow movement in -Z, even if the Z-axis has already been homed
Just a note on that second point – they seem to allow this for both the X and Y axis.
Well at least we know why the g92 doesn’t work, and that they do not plan of implementing it. I guess I will start looking for another easy to use interface for beginners to avoid this kind of confusion. Bummer. I wish they would at least use it in the CNC “enabled” section.
Not sure if this helps but I will often home my system, press the ‘disconnect’ button in repetier, and then press the ‘connect’ button. The repetier software no longer considers the system homed once reconnected to the ramps board… I’m guessing you’d be able to drill down at that point?
My guess (and this is just a guess) would be no. I think you are merely disconnecting/reconnecting the virtual com port but I have never used a logic analyzer to sniff the communication that occurs (if any) when you reestablish the connection.
This was what I was doing prior to installing endstops - and yes, Marlin does reset. Also, the motors release so you may have movement in the ‘relaxed’ state (on mine when Z isn’t powered it has a tendency to drop). You are left with both marlin and repetier thinking the current coordinate is (0,0,0) (or whatever you have configured as home in marlin) and since you haven’t homed repetier will allow Z movement below zero.
I’m pretty sure the reason it resets is that the Mega automatically does a reset on one of the comm pins (DTR I think?) going active.
