Estlcam z movement problem

New Home Forum Software Development Estlcam z movement problem

This topic contains 10 replies, has 6 voices, and was last updated by Profile photo of Ryan Ryan 1 year ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #9503
    Profile photo of Erol
    Erol
    Participant

    I understand the reason of the problem that Jeremy mentioned, topic “Estlcam cutting deeper and deeper”, because I lived the same problem during cutting a 3mm mdf. Estcam produces G00 gcode command in gcode, this is a quick move and mpcnc can not give response to this command on time (or marlin we can say) and z tries to move so quickly and possibly miss some steps of motor. I find the solution by editing gcode, replace all G00 to G01 and separate x y and z and write correct speeds in F value mm/min for each z movement like this :
    from :
    G00 X2.000 Y2.000 Z1
    to :
    G01 X2.000 Y2.000 F700
    G01 Z1 F250

    then it works correctly. If you look into the gcode produced by easel.inventables.com, there is no G00 command, that is the reason. Easel has disadvantages, Estlcam is much more flexible. I wrote an email to author of Estlcam to correct this but he did not answer.

    #9538
    Profile photo of Ryan
    Ryan
    Keymaster

    I was messing with that the last 2 days. G00 rapids work well for the x and y axis but yup it is easy to overdrive the z. I will try and get a hold of Chistian in the next few days and see if there is an easy solution.

    #9646
    Profile photo of Christian Knuell
    Christian Knuell
    Participant

    Hi,

    you can automatically replace G00 with G01 in the Setup -> CNC program generation -> Commands tab:
    Just change “Rapid positioning” from G00 to G01.

    In this case you also may want to add a “F” word for initialisation in the program header – because rapid positioning will not output F and each program begins with a rapid.

    Christian

    Attachments:
    #9654
    Profile photo of Ryan
    Ryan
    Keymaster

    Awesome!

    #10116
    Profile photo of Marco
    Marco
    Participant

    I’m having some issues for milling holes in the bed of MPCNC for the captive nuts, to screw the bed-clamps. I’ve started with a matrix of 4 x 4 holes but after some trouble now I’m trying with a single hole. The spinde drills a hole of 6 mm diameter and 22mm of deep and then mills a concentric shape of 11 mm of diameter and 5 mm of deep for the nut. While drilling, the burr goes down and then lifts (1 mm of depth every pass), after reached 22mm of depth it should rise up at level z=0 and mill the housing for the nut. However, sometimes after completing the 6mmx22mm hole, the spindle doesn’t rise up entirely and mills (with some alarming noise) the 11 mm diameter hole with a deep of 19-20 mm.
    The gcode should be OK because sometimes the job goes fine and in simulation all works. I’ve changed G0 code with G1 in the setup of Estlcam (I’ve bought it) as suggested by Christian, I’ve slow down z movement in Estlcam (2 mm/sec during milling) and Marlin (MAx feedrate 6, Max acceleration 25). There’s some setting for “rapid” Z that I’ve not considered?

    #10117
    Profile photo of Marco
    Marco
    Participant

    This is GCODE:

    ;Project Cerchio_5e2
    ;Created by Estlcam version 8 build 8,214
    ;Machining time about 00:03:04 hours

    G90
    M03 S15000
    G01 X0.0000 Y0.0000 Z0.0000
    G01 Z2.0000

    ;No. 1: Drill 1
    G01 Z0.5000
    G01 Z-1.0000 F180 S15000
    G01 Z0.5000
    G01 Z-0.5000
    G01 Z-2.0000
    G01 Z0.5000
    G01 Z-1.5000
    G01 Z-3.0000
    G01 Z0.5000
    G01 Z-2.5000
    G01 Z-4.0000
    G01 Z0.5000
    G01 Z-3.5000
    G01 Z-5.0000
    G01 Z0.5000
    G01 Z-4.5000
    G01 Z-6.0000
    G01 Z0.5000
    G01 Z-5.5000
    G01 Z-7.0000
    G01 Z0.5000
    G01 Z-6.5000
    G01 Z-8.0000
    G01 Z0.5000
    G01 Z-7.5000
    G01 Z-9.0000
    G01 Z0.5000
    G01 Z-8.5000
    G01 Z-10.0000
    G01 Z0.5000
    G01 Z-9.5000
    G01 Z-11.0000
    G01 Z0.5000
    G01 Z-10.5000
    G01 Z-12.0000
    G01 Z0.5000
    G01 Z-11.5000
    G01 Z-13.0000
    G01 Z0.5000
    G01 Z-12.5000
    G01 Z-14.0000
    G01 Z0.5000
    G01 Z-13.5000
    G01 Z-15.0000
    G01 Z0.5000
    G01 Z-14.5000
    G01 Z-16.0000
    G01 Z0.5000
    G01 Z-15.5000
    G01 Z-17.0000
    G01 Z0.5000
    G01 Z-16.5000
    G01 Z-18.0000
    G01 Z0.5000
    G01 Z-17.5000
    G01 Z-19.0000
    G01 Z0.5000
    G01 Z-18.5000
    G01 Z-20.0000
    G01 Z0.5000
    G01 Z-19.5000
    G01 Z-21.0000
    G01 Z0.5000
    G01 Z-20.5000
    G01 Z-22.0000 // Here z pos change from -22mm to +2mm
    G01 Z2.0000 // What is the speed of this movement? It should be F180 as the others…

    ;No. 2: Cutout 1
    G01 X0.0009 Y-2.2011 Z2.0000
    G01 Z0.5000
    G01 Z-1.0000 F180
    G02 X-2.1994 Y-0.0008 I0.0000 J2.2003 F900
    G02 X0.0009 Y2.1996 I2.2003 J0.0000
    G02 X2.2013 Y-0.0008 I0.0000 J-2.2003
    G02 X0.0009 Y-2.2011 I-2.2003 J0.0000
    G01 Z-2.0000 F180
    G02 X-2.1994 Y-0.0008 I0.0000 J2.2003 F900
    G02 X0.0009 Y2.1996 I2.2003 J0.0000
    G02 X2.2013 Y-0.0008 I0.0000 J-2.2003
    G02 X0.0009 Y-2.2011 I-2.2003 J0.0000
    G01 Z-3.0000 F180
    G02 X-2.1994 Y-0.0008 I0.0000 J2.2003 F900
    G02 X0.0009 Y2.1996 I2.2003 J0.0000
    G02 X2.2013 Y-0.0008 I0.0000 J-2.2003
    G02 X0.0009 Y-2.2011 I-2.2003 J0.0000
    G01 Z-4.0000 F180
    G02 X-2.1994 Y-0.0008 I0.0000 J2.2003 F900
    G02 X0.0009 Y2.1996 I2.2003 J0.0000
    G02 X2.2013 Y-0.0008 I0.0000 J-2.2003
    G02 X0.0009 Y-2.2011 I-2.2003 J0.0000
    G01 Z-5.0000 F180
    G02 X-2.1994 Y-0.0008 I0.0000 J2.2003 F900
    G02 X0.0009 Y2.1996 I2.2003 J0.0000
    G02 X2.2013 Y-0.0008 I0.0000 J-2.2003
    G02 X0.0009 Y-2.2011 I-2.2003 J0.0000
    G01 Z2.0000
    G01 X0.0000 Y0.0000

    M05

    #10121
    Profile photo of Marco
    Marco
    Participant

    I’ve modified previous gcode sketch putting “cutout” before “drill” but there’s the same issue. It’s NOT caused by gcode or MPCNC, I’m pretty sure that the fault is in the tool. When it is all inside the hole an impredictable vibration can trigger a flutter that ruins the work. I think to buy a more accurate spindle and better tools.
    Do you think that a 400W chinese spindle (in the photo) is better than my old manual economic 400W spindle? It’s advisable to change Universal Mount with a dedicated, more rigid mount?

    Attachments:
    #10127
    Profile photo of Dave Gun
    Dave Gun
    Participant

    I just read a few other posts here on this spindle, you might want to look around a bit for more information. Here is a link you might find interesting:

    #10179
    Profile photo of Marco
    Marco
    Participant

    Uhm… thank you!

    #14710
    Profile photo of Jakob
    jakob
    Participant

    With this z-axis “dive” or skipping problem being discussed in a couple of different threads, I’d add my observations here after spending the better part of the weekend getting to a predictable behavior…

    What I had collected from the threads was:

    1) Feed rate isn’t controlled specifically for Z-axis movement.
    2) G00 would pick up the previously used feed rate whether it was specified for Z-axis or any other axis.
    3) Estlcam allows using G01 instead of G00 for rapid movements.

    After reading the threads about G00 vs G01, I optimistically set out to get this behind me. Issued a few rapid moves and regular moves, specifying various feed rates and it failed as much with G01 as with G00! Diving into the source of Marlin, it turns out that G00 is automatically interpreted as a G01. So no reason to worry about whether it’s a rapid move or not. This means that (3) is a moot point as my experiments also showed. Marlin is oblivious to the rapid move command. This is the responsible code snippet from Marlin for those who speak code (if a G0 is given it is interpreted exactly as a G1 would be):

    if(code_seen(‘G’))
    {
    switch((int)code_value())
    {
    case 0: // G0 -> G1
    case 1: // G1
    if(Stopped == false) {

    I did conclude that every now and then the skipping would happen more frequently at higher feed rates, so controlling feed rate seemed like a plausible fix, though I also had skips at lower feed rates. So there had to be more…

    I then put power on the stepper using the manual controls in Repetier, then grabbed the Z-axis adjustment nut and turned it. Boom! I pushed over the stepper way easier than I expected, indicating that the hold of the stepper wasn’t as strong as I anticipated. I’ve use the strong motors recommended, but was running the Z-axis on the cooler side (tuned the controller to 600mV => 1.2A). My motors spec’d at 2A for max hold, so I turned up the holding current by adjusting the controller to 800mV. Much better. More testing showed that I still had the skips, but way less. Then upped the controller to 900mV (1.8A for the stepper) and now I could hardly turn over the stepper. The test has now completed a 1h run with 10 layers, returning to the exact starting point, so no skips! The stepper does get hotter now (~90F after the hour long job) but well within the 80C temperature raise the stepper is rated for in an ambient temp range of 20-50C.

    So in the end for me this was not simply about overdriving the axis with feed rate out of control. It will take F2400 just fine now. It was about the lack of torque of the Z-axis motor as a result of running it too cool. Could say that’s the same thing – but the cure was to drive the stepper hotter as I couldn’t go low enough (within reason) on the feed rate.

    In the process I also found an option in Estlcam that allows issuing federate for all the move commands (checking on the “repeat” option for the “F” setting). While this gives explicit feed rate on every command and thus should eliminate (or at least limit) risk of inheriting “wrong” feed rate, I am not sure that it’s really helping now considering the other changes I’ve done.

    Hope this helps others in their chase.

    PS: In the process, I also concluded that the lack of specifying feed rate is the cause of the occasional glacially slow move to the _first_ point of a job. Including a “G01 F1600” in the header of the job ensures that feed rate starts out right before being specified the first time. This might be what Christian hints at above with the “add a ‘F’ word for initialisation” – it just took me a while to internalize that 🙂

    #14736
    Profile photo of Ryan
    Ryan
    Keymaster

    Thanks, that is some good info. I have been milling a lot lately and I haven’t had a missed z step in a while. I think It was a combination of new center, slower accel, “f” repeated on every line, and a bump on the drivers as well to .7 for the Z. So I agree with everything you said.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.