Just upgraded to meticulous z-axis and finished some calibration only to get an error that my sled can’t keep up. Attached are the messages I’m receiving with regards to my g-code. My g-code is exported from fusion 360 and it was running fine before I upgraded my z-axis. I relaxed the tolerance in the advanced settings for the alarm (from 2 to 10), but it still wouldn’t budge an inch. The sled refuses to move currently, but the calibration process went perfectly.
I’m wondering if weight would be an issue with regards to sled…
That is a nice looking meticulous. I like your clamps. Where did you get them?
if your sled is too heavy, the motor current sensors will say too much current and not enough movement = not keeping up. I’ve never seen one with bricks up that high. What does it weight? is the vacuum sucking the sled down on the work piece?
Thanks @Orob, I took the clamps from @theHipNerd 's youtube video. Just some lag bolts, nuts, washers and some hose clamps from home depot.
With regards to weight, I’d say it feels around 20 lbs. I don’t think the vacuum is sucking the sled down on the work piece. I’ve tried it without the vacuum and spindle on as well to see if there any distinct noises it was making.
I’ll look into that video. recheck your motor connections and that your power cord is plugged in and connected to your shield and not arduino. Odd it worked and now doesn’t. A 20# sled sounds reasonable. I think mine is 28-30 and I’ve got 2 bricks on each side and a bit smaller meticulous back plate with a very heavy router and the vacuum holds the sled a bit.
Everything is plugged in and motors work fine, but i’m still getting error messages. I even tried removing weight to see if that was the issue. I’m seeing info in the forums about posting through Maslow. I usually post through easel, but it sounds like there may have been some updates that necessitates me posting through Malsow now. I downloaded the file, posted the g-code through Maslow, tried to open the g-code through ground control and GC cannot find it.
Upon further inspection, it appears the file is NOT a .NC file type. It is a 0 file type…That sounds like something went wrong. Am I missing something here?
I am not a coder, but do I now need to learn to read the text file of g-code to properly identify lines of code for future issues? If so, any good resources to understanding the commands?
this whole thing is a lot to swallow all at once. I found a writeup on wikipedia about gcode that was interesting, though complicated. There is a NIST paper on RS427 and there is some information on GRBL. I would probably say look at GRBL as a reference because that is the code base the Maslow is working towards.
Try opening your gcode file in notepad and see if you can read it. It will likely have some M##, some G##, some X##, Y##, I##, J##, Z##, and F## where ## is a number. Oversimplifying: it is just lines of numeric coordinates or speeds. Lines in () are comments and are ignored.
Sometimes if you use a non maslow post processor, it may not set your file extension (must be .nc .ngc .text or .gcode - according to webcontrol file filter) and i may include commands that are not compatible with maslow.
If opening and the text looks reasonable, change the file extension to .nc or .gcode and try again.
‘sled can’t keep up’ is a good idea in theory that doesn’t work well with the
current firmware. At this point I regret that my suggestion was implemented.
currently the default is that if the sled is not within 2mm of where it thinks
it should be (following the gcode), it aborts with this error.
the probelm is that it takes time to get the sled moving, a combination of the
PID loops taking time to move and the physical inertia of the mechanism.
if your feed rate it too high, the sled just doesn’t get moving fast enough to
satisfy the alarm.
we really need to change the default on this, just disable the alarm, or
change the alarm to something that’s more meaningful (such as a motor at full
power and the PID loop calling for an increase in power to keep up)
I go into settings and change the alarm value from the default of 2 to something
much higher (say 20) or lower the max feed rate until the alarm stops sounding.
I’ve relaxed the tolerance to 30mm and have raised, reduced, etc. of the max feedrate. The primary errors I’m receiving are command lines not being supported and ignored. Once I resume cut, then I get the ‘sled cannot keep up’ error message. This is with the G-code attached, which I have posted from fusion 360 through the easel filter thingy.
The next step will be trying to post from fusion 360 using the Malsow filter thingy (idk the terminology) to get a proper .NC file or something that Ground Control recognizes. The last time I did that it gave me a .0 file type (see attached).
I know for fusion 360, there’s a specific gcode post-processor available (have to search the forum here for it)… If you aren’t using that, it might solve the problem.
How far along in the gcode do you get before you run into the sled not keeping up error?
I thought I found it, but I guess I’ll have to double check and triple check if it’s the correct one or if there’s a newer version.
If you look at the original photos in the post, you can see I get errors immediately with regards to unsupported command lines. Once I “resume cut” it gives me the sled error. The whole time the motors don’t move and the sled doesn’t budge.
That being said, motors work fine during calibration.
I’m not so sure its the gcode itself. I can run it in “fake servo” mode (i.e., simulated) and it doesn’t give the sled not keeping up error (but also I’m using webcontrol).
Perhaps post your groundcontrol.ini file so we can maybe see if something is amiss. Otherwise, sounds like its just too heavy?
What is the setting called to change from 2-20. I am getting the same error after I exported from fusion 360. I figured that is the first thing I would try.
That did it!! lol. Saved with the .NC at the end and it fixed my issues. It DID complain at first about “command G17 unsupported and ignored”, but one I hit ‘resume cut’ it started making things happen.
It would have been an overall successful cut, but I forgot about letting my computer go into sleep mode. oops.
What’s interesting is I posted from fusion 360 months ago for grbl (whatever is for easel software) and it was able to run just fine on the maslow (minus my z-axis dragging from cut to cut). Thanks for the help! I think I can finally get my first successful cut in now.
Above is my first test cut since I upgraded the z-axis (It’s the logo of my makerspace). I need to tinker with the hardware on the sled a bit more, but overall I’m happy with the result.
New Issues: z-axis not quite right.
I calibrated the z-axis right before the cut and even checked my fusion 360 file, but the depth of the cutting around the pelican profile was supposed to be 1/2" and clearly went past that point. Even accounting for a slight bow in the 3/4" plywood, 1/4" off is terrible.
Added some better weight to the sled and secured the ring supports to keep them from flexing.
I attempted to cut the pvc sled base this evening, but got the old “sled cannot keep up” error again. After checking the file multiple times, I attempted to calibrate; no motor response. Tested motors; they all failed.
I’m assuming the sled cannot keep up THIS time due to the motors failing. Any ideas?
When they all fail it’s almost always an issue with the board not getting power. Is the green power light on on the board illuminated and the blue light on the power supply also illuminated?
your sled looks good. I’m curious why you placed your belt gears the way they are. You could have a z-axis pitch of 24 if you swapped the pulleys places with the 60 on the motor and the 20 on the lead screw. This will dramatically increase your z axis speed an justify the whole upgrade (in my opinion). As you have it, you have a pitch of 8 with a 3:1 reduction = 2.6666. The axis will actually run slower than the rigid z axis set up (3.17) like you have it. Perhaps trying it like this might be a a speed improvement:
The motors have more than enough resolution to support this z axis setup. As far as the not keeping up error, double check your vacuum tube isn’t binding and pinning the sled. The only legit sled not keeping up error I had was when the z axis motor wire got caught on a cut section of the work piece and the sled couldn’t move.
A second option is to make sure the “sled not keeping up” error setting is higher than the default of 2. In webcontrol, look for it under one of the settings menus. Change it from 2 to 20 and retry.
It was indeed a power issue! connections were a bit loose for the power block.
I will now look into reversing the heads of the pulleys for better z axis speed and to recalibrate the z-axis. Hopefully this will solve all my z-axis issues.
