Z slip over large topographical map

  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:

[attachment file=51109]
[attachment file=51108]

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

[attachment file=51110]

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:

[attachment file=51111]

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.

[attachment file=51112]

Thanks for your time!

2 Likes

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 Like

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:

[attachment file=51123]

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.

cropped-gcode.txt (668 Bytes)

aspireRates.png

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.

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.

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.

Oh, so they aren’t respected?

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

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.

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.

Cropped-gcode.txt (805 Bytes)

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

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

Configuration-1.h (65.8 KB)

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?

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:

[attachment file=51142]

Faster laptop:

[attachment file=51143]

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.

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

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

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?

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

I’ll flash again tomorrow.

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?

 

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.

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.

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

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.

Test-gcode.txt (1.8 KB)

1 Like