MPCNC skipping steps?

This topic contains 17 replies, has 4 voices, and was last updated by  Spint 4 months ago.

Viewing 18 posts - 1 through 18 (of 18 total)
  • Author
    Posts
  • #53031

    Spint
    Participant

    Dear readers,

    First post after reading quietly along during construction of my MPCNC, had plenty of time while waiting for all the parts coming out the printer. Thank you all for sharing your knowledge.

    I will try to state my troubles as clear as possible:

    I am running Marlin 1.1.0-1 and run the gcode from the SD card on the RAMPS. I started doing test runs using the pen attachment, as seen on the pictures below, before I want to mount the router for the real thing. I have tested the MPCNC using the ‘crown’ gcode from ESTLcam, which works fine on the first plunge. As you can see in the picture it seems to skip/add a few steps on the X or Y axis after starting the second pass.

    To test the machine further I have used Easel to generate gcode from a basic design. In the picture below you see one of the attempts to draw my favourite Sith lord, just because the path is a bit more complex than the average testsquare/circle. The Z axis movements work fine when I run this but as you can see it sometimes fumbles up the positioning when performing a G-Zero command, or at least I think that’s where the problem lies, please correct me if that’s wrong. I then added F values to each G0 line in the gcode but it still doesn’t stay on the path.

    I am kind of lost as to pinpoint the problem here. Has this to do with using Easel to generate the gcode? I have also attached the gcode file to this topic. DVtestF500F1000

    Thank you for reading.




    #53038

    Hubert
    Participant

    Does the problem occur only if you try to print twice, or does it happen during a single print?

    If it happens between two successive prints, it might be that the steppers are turned off between the prints. Your gcode does not explicitly do that at the end, but I think there is a timeout.

    If it happens during a print, it is probably skipping steps.

    1 user thanked author for this post.
    #53039

    Spint
    Participant

    Hello Hubert,

    Thank you for the reply.

    The skips occur in a single run. The ‘vader’ pen path is a single layer. I haven’t yet let the MPCNC run twice in a row since it fumbles the path on the first time round.

    #53040

    Ryan
    Keymaster

    Lets see your gcode. What your are saying in the description doens’t really match up with what should happen automatically with the CAM, or at least any we have a post processor for. Easel is not a good choice I am afraid.

    The bottom z mount looks like something is wrong can you put another picture of it.

    Why make the machine so tall just to but a 3″ block under it? A 3″ machine is more than twice as rigid as a 3″ cut on a 6″ machine. You might have a valid reason but you will have more fun with a shorter machine.

     

    #53042

    Hubert
    Participant

    It looks like you are drawing multiple times at different heights (-0.412, -0.7, -1.4, -2.0). Does your pen holder have a spring action built in? I would change the gcode to plot at a single depth, 1mm has worked well for me with Ryan’s pen holder.

    Did you have this problem during a single print with the crown gcode from the website as well?

    1 user thanked author for this post.
    #53043

    Mike
    Participant

    The highlighted area is where the actual print departed from the gcode. The gcode looks good to me (it is line 730) and there isn’t anything abnormal there, just moving along a series of G1 commands.

    Are you actually watching it when it happens? If so what does it do exactly? Any noises, jerks or other odd behaviour?

    Maybe need some more info about your machine also. What board, drivers, voltages, etc? Do all the axis’ move smoothly by hand?

    Perhaps try running it from Repetier via USB to rule out SD card or reader problems?

    1 user thanked author for this post.
    #53046

    Hubert
    Participant

    Just to clarify, I meant -1mm for the drawing depth. That is also what the crown gcode from the website uses. It only does a single pass, though, so I assume you generated your own gcode in Estlcam. Did you use the engrave function or something else? What depth did you use for the path? I think 2mm depth is a lot, particularly if there is not a lot of compliance in the pen holder.

    1 user thanked author for this post.
    #53049

    Ryan
    Keymaster

    I agree with Hubert, your gcode looks okay other than you have it going down 3 times. With a pen or cutter once is enough.

    I have never seen the pen holder you have but if it does not allow that much movement down that could very easily cause skipped steps by jabbing the pen into the wood. On that same note how is the pen guided, are you sure the pen didn’t just move?

    1 user thanked author for this post.
    #53050

    Spint
    Participant

    Thanks for all the replies guys. I can answer most of the questions. The ‘Vader’ code was generated straight out of Easel without a post processor, this could be the culprit. It shows the same errors when run from SD as well as from Repetier.

    @Ryan: Looking at the code I uploaded what would a post processor for MPCNC have changed?

    In the pictures in my first post the action was cut off as soon as it seemed to run of course so in the vader session the second and third layer were never really drawn.

    The code I uploaded was intended for a router action this is why I have made three layers with a Z axis drop of only .7 mm each pass. The penholder I use has at least a centimeter of movement straight up, this cannot be the problem of the X/Y shambles during these runs.

    I have attached a picture of the penholder and the addition I have made on the router mount. It is just a clamp that holds a mechanical endstop. These endstop are not yet defined in the RAMPS so don’t hold a function yet.

    When choosing the length of the legs I went for a higher construction so that the MPCNC can later be converted to printer. I have constructed a wooden flatbed for cnc action so that the router mount is as close to the gantry as possible, for stability. And it also gave me a chance to make a plate with bolts glued in underneath for clamping workpieces.

    The penholder is printed so that the entire pen can move up and down in the tube. In the picture I have lifted it up a few mms. There is no spring built in, pressure downwards is done by a few washers and a capped M12 nut. The pen is able to move when there are curved actions but not more than a millimeter at most.

    Attachments:
    #53069

    Hubert
    Participant

    It looks like the paper is attached directly to your platform. Is there any chance the pen could get hung up on the mounting holes in the plywood? Or is there an extra sheet of smooth MDF under the paper?

    I would energize the steppers (move all axes with the LCD) and then try to twist and push on the pen holder and see if there is any give at all. There will be some flex, but the pen should go back to its original position when you let go of it (unless you apply unreasonably excessive force).

    1 user thanked author for this post.
    #53076

    Mike
    Participant

    Just a side note. I found this online gcode viewer awhile back and I have found it quite useful in visualizing what is going on with my gcode. It is nice that it runs the lines of code on the side as the graphics move. CAMotics is good too for a local program.

    https://ncviewer.com/

    Other things to check. Belts too tight? Loose grub screw on one of the steppers?

    1 user thanked author for this post.
    #53082

    Ryan
    Keymaster

    This is hard to say what is going on you need to watch it until it messes up and tell us what happens. If it is missing a step this would be a very rare thing. The MPCNC can rip itself  apart before skipping a step I sell them at less that full power for this reason.

    It could be as simple as you have the belts like 3x’s too tight and they are stopping the steppers or you could have electrical interference on the circuit making it skip. Both have happened. If you can observe the problem once it is so much easier than guessing the numerous things that could cause that.

    As for the height, adding a box helps but the legs are still super tall and the weight of the Z motor is still super high over the gantry. I am not saying it can’t be done but wider is easier to deal with than it being that tall. I have a few pages about this and the FAQ’s as well.

    1 user thanked author for this post.
    #53083

    Ryan
    Keymaster

    What driver is your ramps running, what step rate and voltage, what do your steppers require and are they 1.8 degree or .9 degree, 16T pulleys?

    1 user thanked author for this post.
    #53098

    Spint
    Participant

    Thank you replying guys. I will answer each post quickly. Sorry my first was so incomplete.

    I am using NC viewer already to check the gcodes I run. The ‘Vader’ looks just fine in NC as well as in Repetier.

    When drawing I use an MDF plate to stick the paper to so I have a smooth surface to run the pen on.

    I have checked the belts and pulleys and they are all fine.

    I am using a RAMPS 1.4. NEMA 17 2.5A 1.8d motors and 16T pulleys. The drivers are 2A 8825 and an 2560 mega Arduino. All seems pretty standard.

    My guess it might be interference from the end-stops that are connected in a circuit that signals when the loop is interrupted resulting in a constant current. Perhaps I should shut the off entirely or reverse their connection so that they are null and only run a current when the loop is shut. Today I will use the oscilloscope to test the motors if there are any out of order interference.

    It is however still strange that the crown gcode run smooth and the vader doesn’t. It seems the errors only occur after a safe travel toolpath when the Z has again plunged for another section.

    After testing today I will post my findings. Thank you for all the efforts of reading and replying guys.

    #53106

    Spint
    Participant

    Dear readers,

    After a few hours of testing working without endstops it indeed turned out to be interference coming from the permanent current running these stops. Good call Ryan. =)

    Solution: Reduce pull up resistors ( Atmega 2560 internal pull-ups are 50K ) use external resistors  ( 4k ohms or less to lower the impedance and sensitivity of interference). Use NC switches instead of NO. And finally define the changes in Marlin software.

    Below I posted the readings from the oscilloscope attached to the X end sensor, one with the motor running(you can see the graph lashing out downwards with the upper line being 5V) and one without(Nice and steady). The threshold being 2.5V on the sensor its obvious that was the culprit. And of course a ‘Vader’-drawing and after that a final test with the router attached. Results are astonishing.

    Thank you guys for thinking along with me.




    #53112

    Ryan
    Keymaster

    AWESOME! I knew this was an odd one.

    1 user thanked author for this post.
    #53120

    Mike
    Participant

    Glad to see you got it sorted. Ain’t it cool what this thing can do!?!

    1 user thanked author for this post.
    #53121

    Spint
    Participant

    Yep the possibilities seem endless. In for a whole batch of experiments these coming weeks =)

    Thx again gents

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

You must be logged in to reply to this topic.