Z slip over large topographical map

New Home Forum Mostly Printed CNC – MPCNC Troubleshooting – MPCNC Z slip over large topographical map

This topic contains 45 replies, has 4 voices, and was last updated by  Svein Inge Kallevik 5 months, 3 weeks ago.

Viewing 30 posts - 1 through 30 (of 46 total)
  • Author
    Posts
  • #51107

    Jesse
    Participant

    1) Did you buy everything from here?
    Everything but the conduit and 3d printed parts were purchased from the shop on 3/17

    2) Are you using end stops?
    Nope

    3) Mac or PC (windows xp, 7, 8, 10?)?
    Windows 10

    Hey all,

    I am halfway through carving a large (6’x4′) topographical map of the Great Lakes out of rigid foam insulation for an ecology class at my school. (I’m the librarian.)

    The map is divided into 2’x2′ sections to fit inside my machine, and I’ve been able to cut three sections nicely:


    However, the last few attempts have severe z-height issues:

    There is a gradual slope bedward with each new cut, highlighted when the machine skips and later returns to a section.

    After digging in these forums over the past few days, I am almost certain this has something to do with the max Z speed. Because Estlcam cannot turn a high-res raster into gcode, I am using Vectric’s Aspire 8.505 to render it. I used John’s post-processor here for a while, then when this issue cropped up I switched to Klaus’s here yesterday. That increased the xy travel speed, but did not solve the problem completely.

    Am I right in thinking the error must be bad gcode? The issue pops up in a similar way regardless of where the cut is made on the machine:

    The gcode for this particular section is too large to upload (~8MB), but I am happy to clip it down if someone tells me what to look for.

    …and my Repetier settings, if that helps.

    Thanks for your time!

    #51114

    Ryan
    Keymaster

    Depending on your Z axis screw the max rapid would be 8.4mm/s 5/16″ or 30mm/s for a T8. What did you set them to? Plunge rate? Look at your gcode it should ideally have a “F” command on every line, you can dive by 60 to get the mm/s. It probably doesn’t have them every line thinking G0 or G1 will set it, it will not.

    Normally you would convert that to an STL and then let estlcam do it, if aspire does it natively that is pretty cool.

     

    Those are super sweet though I can not wait to see it complete. I want to do the SF bay area on a full sheet on my Lowrider with the Z axis (height) exaggerated by 2-4X. Are you going to coat it or leave it as is? Awesome project , we can get you working.

    1 user thanked author for this post.
    #51121

    Jesse
    Participant

    I have the 5/16″. The issue is that I don’t have a place to set the max rapid (or I am a fool). Attached is the first chunk of the gcode, and here are the settings available to me in Aspire:

    I’m still just getting my feet wet with gcode, but I’m clearly missing the F command after line 20-21. Does that mean it is defaulting to the previous command (1080, given by Klaus’s PP), or to the max rate set by the Marlin firmware?

    My big question at this point, then, is: does the F command at the end of the line control the XY and Z movements together? That is, does G1 X422.708 Y13.448 Z-0.014 F240.0 have each axis running at 4mm/s, is it some function of the power running from the board (divided somehow?), or is it just the Z axis running at 4mm/s?

    If it is just the Z speed, could I change the PP to write the feed move on each line like this, since it can’t rely on G1 or G0?

    begin FEED_MOVE
    "G1 [X] [Y] [Z] F84"

    The STL solution is a good one, and I might just do that if this doesn’t work out.

    Thanks! Your work on this project has been really inspiring to my students and me. (I’m moving on to the low rider as soon as I save enough–the library needs some new furniture!) I have a half-hearted writeup here on my website if you’re interested in how I built the original images, or want to see it done in wood.

    Coating is another can of worms. I will paint it white, then let the students label it as they will. Most recommend coating insulation in wood glue to protect before spray painting, but that left streaks when I tried, even thinning with water. I’m actually having good progress with really thin coats of Bulls Eye shellac, which I’ll then spray with high-gloss enamel. None of this will protect it, though, so I’m still looking for a flexible sealant or something stronger.

    #51125

    Ryan
    Keymaster

    That post processor is not good, it is missing the first Z speed command, that generally crashes the board before it even start cutting and yup it should have some more F commands in there. It does not need to have them on every line. It will use the last F command given, so technically you do not have to repeat them. The max rates set by the firmware are notoriously finicky and not always obeyed.

    I have no experience with that software or PP but it needs some work from what you have shown me.

    If all commands are on one line with a speed it moves to the next point and divides the speeds evenly to obey the firmware max not moving any axis faster than it’s given max but making the full motion in one even shot, Should is the key here.

    You can try my beta Marlin 2.0 firmware on github (linked on the firmware page), the limits might have been fixed in the firmware. They originally worked, then we lost them for many many versions. Hopefully with 2.0 they have been fixed. I need to get the rest of the printer stuff out before I dive into the firmware again to do testing. The Estlcam and fusion PP work perfectly though.

    #51126

    Jeffeb3
    Participant

    This is a cool project. Here are some ideas I have:

    1) Switch to 1/16th microstepping on the Z driver. Then you’d have to change your z steps/mm by 1/2. That should give you some overhead on the CPU. That wouldn’t fix it if the issue is torque, but with the 5/16″, that should be a pretty good amount of torque.
    2) Post process the gcode with something that adds the F<>. This project is cool enough, if you post the gcode, I might do that once for you… :). Any G00, G01, G02, or G03 that has Z in it, and not F should add F<speed>. That seems like a 15 minute python script, or bash script or any language script. If you post the entire gcode, and the speed you want, I can do that.
    3) Can you change the max Z speed in Marlin? I thought Ryan had tried that, but I’m not sure why that wouldn’t work. That might have failed more in earlier versions of Marlin.

    #51127

    Jeffeb3
    Participant

    Have you tried water based poly (Polycrylic)? It isn’t oil based, so it might work. I’m pretty sure you can paint it once it dries. It’s a very durable finish.

    #51128

    Jeffeb3
    Participant

    They originally worked, then we lost them for many many versions

    Oh, so they aren’t respected?

    I guess the script may not work perfect either, because the Z moves aren’t independent.

    #51129

    Ryan
    Keymaster

    No, for some reason they aren’t. I never dug any deeper but I think multi axis commands respect the limit but single axis might not. I know a lot of that was reworked in 2.0 so Fingers crossed it works now.

    We had used it for a year with no issues then all the sudden even my original crown test code crashed on the first line, the Z rapid to clearance. It was easier to make the 3 PP than fix marlin at the time. Now with your tutoring I am not scared to dive in deeper if the problem still exists.  I finally got time just now to try and finish up the printer release stuff so that is my priority though.

    #51131

    Jesse
    Participant

    I know a lot of that was reworked in 2.0 so Fingers crossed it works now.

    How much do I need to change if I’m flashing the github version instead of this one? MPCNC813_GLCD I’m willing to act as guinea pig, but don’t want to throw something off b/c I don’t know what I’m doing.

    I changed the PP to yield the attached, but I’m looking at 44 hours estimated print time in Repetier. Without the X and Y F commands it is over 120.

    Attachments:
    1. Cropped-gcode.txt
    #51134

    Ryan
    Keymaster

    The firmware should work as is, if not just flash back to the other one.

    #51138

    Jesse
    Participant

    Just an update before I quit for the evening:

    The Marlin 2.0 flashed just fine. There might be some xy jitters I hadn’t noticed before, but I’m not sure. Unfortunately, the issue remains. I used the old gcode (maybe wrongly) thinking that the firmware would throttle it, but that doesn’t seem to be the case.

    I had to spend a bit of time moving the configuration settings over, since it rejected a copy/paste of the old file. I’ve attached it below in case that helps anyone. The screen settings were giving me trouble, so I commented out

    #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

    Attachments:
    1. Configuration-1.h
    #51140

    Ryan
    Keymaster

    Why did you change the config file?

    My files didn’t work as is?

    https://github.com/Allted/Marlin Linked from the firmware page right?

    #51141

    Jesse
    Participant

    Switch to 1/16th microstepping on the Z driver. Then you’d have to change your z steps/mm by 1/2. That should give you some overhead on the CPU.

    Do you think it could be the size of the file (8MB, 275k lines)? Now that I’m thinking about it, I tried running it through Repetier on a very old laptop, and the quality was significantly worse, but the problem was similar: irregular shifts in z height.

    Old laptop:

    Faster laptop:

    Am I grasping at straws here?

    I will say that I’ve never heard any of the grinding/pausing others have described, but the Dewalt is loud enough that I might just be missing it.

    Have you tried water based poly (Polycrylic)?

    I haven’t, but I will. I’ll have plenty of test pieces at this rate!

    #51145

    Jesse
    Participant

    Why did you change the config file?

    Gah! I must have misunderstood. I thought we were looking at Marlin 2.0? The bleeding edge version?

    #51147

    Ryan
    Keymaster

    Not sure about the laptop, hard to believe it can’t keep up with usb, unless it is really old.

    My firmware through that link is only a few days to a few weeks behind. I update it all the time. Probably going to be doing it again tomorrow.

    You can’t find any other post processor for the CAM you are using, that is the main issue here?

    #51152

    Jesse
    Participant

    Not sure about the laptop, hard to believe it can’t keep up with usb, unless it is really old.

    >10. I thought it was interesting because it seemed to make the same issue worse. It is probably not pertinent.

    My firmware through that link is only a few days to a few weeks behind. I update it all the time. Probably going to be doing it again tomorrow.

    I’ll flash again tomorrow.

    You can’t find any other post processor for the CAM you are using, that is the main issue here?

    I believe so, but that search depends on the firmware being able to read it as we’d expect. In a perfect world, each

    I think the real issue is Marlin’s limitation. I didn’t realize that it defaults to the lowest DEFAULT_MAX_ACCELERATION of the three axes on any given move. Looking over previous gcode, I had been unknowingly running it at 1080 (18 mm/s), way over what the machine can handle on the z axis, but fine for x & y. Since this project has a z height change at nearly every step, the ultimate solution might be that I leave the thing running for two days to make the cut.

    Am I seeing this correctly? If I pick up an LCD screen I should be able to set some of these defaults from there with the EEPROM, right? Would that make the lack of F commands in the gcode less of an issue?

     

    #51156

    Ryan
    Keymaster

    It defaults to the lowest axis max speed over the entire move, so Z generally only moves a tiny bit where XY moves a lot. When combined the Z might be the limiting factor but the XY are not limited to the Z speed.

    For example from 0,0,0 to 100,100,1 Z will actually be moving much slower than its max, it will not move up fast and wait for the XY to catch up. It spreads its move equally over the entire diagonal distance. There is a name for this but I am drawing a blank.

    The LCD will not change anything other than your old laptop issue. The post processor you are using is the problem. Marlin works but telling it to move super fast and relying on the firmware isn’t a good solution. You want to have full control of every aspect of it’s movements. Your standard gcode isn’t even correct. The issue we had in the past was lack of rapids predefined in the firmware, you also have that problem.

    I made edits but have no way to test them can you see if it works or attach some output code.

    #51158

    Jeffeb3
    Participant

    I didn’t realize that it defaults to the lowest DEFAULT_MAX_ACCELERATION of the three axes on any given move.

    I’d have to look at the code, but there are two ways to interpret that. If you are moving 100mm in X and 1mm in Z, it’s my understanding that the x Accel and speed will be the limit. Maybe it’s taking a shortcut in the computation, but it should be choosing a trapezoid for overall speed that doesn’t exceed the speed or acceleration in any single axis.

    Also, the CPU, I was referring to is the Marlin CPU. If you go too many mm/s and the steps/mm is 4500, then the processor can’t flip the bit fast enough. Switching to 1/16th steps would mean your steps/mm would be closer to 2250, which would give you more headroom in the processor timing. (Embedded CPUs without an OS don’t benefit from spare cycles like your laptop would, so changing this only benefits you if it can’t step fast enough).

    Another note, you shouldn’t be leaving the machine running without supervision. The bit can embed in the spoil board and cause a fire. The z issues you’re seeing are exactly the kind of mistakes that can cause that. The library wouldn’t be much fun after that.

    #51159

    Ryan
    Keymaster

    Sorry we posted on top of each other. Had to wait for atom to update to save the file.

    #51169

    Jesse
    Participant

    For example from 0,0,0 to 100,100,1 Z will actually be moving much slower than its max, it will not move up fast and wait for the XY to catch up.

    That makes sense. I guess my issue is that I have z movements frequently close to the other axes:

    G1 X130.080 Y14.718 Z-0.631 
    G1 X130.826 Y14.718 Z-1.414

    Yielding an x move of .826 and a z move of .783.

    I’ve attached part of the file using your PP.

    Good to know about the screen. I’ll get one eventually, but it is nice to cross that off the list of variables.

    Attachments:
    1. Test-gcode.txt
    #51176

    Jesse
    Participant

    If you go too many mm/s and the steps/mm is 4500, then the processor can’t flip the bit fast enough. Switching to 1/16th steps would mean your steps/mm would be closer to 2250, which would give you more headroom in the processor timing.

    Very good. I thought this was a step up in precision, which confused me for a bit. Is this a change in the Marlin config file? Will there be a noticeable change in resolution?

    you shouldn’t be leaving the machine running without supervision

    Good looking out. The kids and I built it, and we design projects for it, but it is not something we should have on campus as-is. Right now it lives in my laundry room.

    #51177

    Ryan
    Keymaster

    Hmmm, changed the Feedrate and Cutrate variables, but it is missing plunge speeds and arcs. Once you get through this project you really need to get to Estlcam or Fusion the PP’s are much more mature. Kinda surprised this works, there were multiple rates on the same line that I had warned them about, they left them in. I just took them out.

    Not sure why the Feedrate isn’t repeating but maybe this will work.

    You do not have the option to set the feed rate, cut rate, plunge, or rapid?

    #51179

    Jeffeb3
    Participant

    Is this a change in the Marlin config file? Will there be a noticeable change in resolution?

    I’m assuming your using ramps?

    http://www.geeetech.com/wiki/index.php/Ramps1.4#Jumper_Instruction

    So remove two jumpers. Just under the Z axis. Then change the steps_per_mm for Z to be half what it was. You can change it in the config (it’s an obvious name STEPS_PER_SOMETHING), or using gcode:

    http://marlinfw.org/docs/gcode/M092.html

    If you screw it up, you’ll be off by a factor of 2, 4, 8 so it will be a quick test to see if it’s working.

    There’s been some debate about which microstepping to use. The tile of thumb I use is just to use 1/32 on an MPCNC, unless you have a reason not to. They are practically identical, but the common assumption on the forums is that you’ve got it in 1/32. You won’t actually lose any resolution because the steppers can’t really do a 1/32 step.

    1 user thanked author for this post.
    #51181

    Jesse
    Participant

    Attached is clip with new PP.

    I’ve also attached Vectric’s PP guide, which might be helpful. I’m not sure what I’m looking for.

    I can only set feed and plunge rates. They allow me to set the rapid z height, but I assume they rely on the machine’s max for the actual rate.

    #51185

    Ryan
    Keymaster

    Getting there. Need to add the “f”

    I am digging through there guide….It is huge. I found the Z axis at a different rate stuff but I am not sure if I have it correct yet.

    #51186

    Jesse
    Participant

    I’m assuming your using ramps?

    Yep, ramps.

    I’ll make the switch tomorrow. Seems straightforward.

    #51188

    Jesse
    Participant

    It is huge

    Ha! Yeah, I was in over my head quickly with that one.

    Digging a bit deeper, this software is bundled with nearly 500(!) post-processors of every flavor. I picked one (X-carve) and copied a chunk below. Not a lot there. If you know a machine that might operate in a similar way, I could send that PP to copy from.

    Attachments:
    1. xcarve-gcode.txt
    #51190

    Ryan
    Keymaster

    If this works I can add Arcs as well.

    I hope this asks for

    feedrate, What we call rapids

    Cut rate, What we call feedrate

    Plunge Rate, Feedrate for Z axis

    I feel like I am still missing something though

     

    #51192

    Ryan
    Keymaster

    If there is a reprap one in there we would be in business I’m sure.

    #51193

    Ryan
    Keymaster

    With arcs and more correct Z moves? “test 5”

    If that fails test4 corrects my command error from test 3.

Viewing 30 posts - 1 through 30 (of 46 total)

You must be logged in to reply to this topic.