My Machine is a late 2021 Metal Maslow with ring, and Arduino on rasp pi running Makerverse 1.1.2
my Z axis is set to 18, Z axis steps set to 5400. These are the only sub standard settings, i believe Thanks to Mike Garza.
What is happening is continuous alarm 3, sled is not keeping up, every couple hundred lines of code it seems to stop. it seems to be related to z axis movement, but i cant prove that.
What i have done.
tried both ground control and web control - the problem seemed worse on ground control, hard to say.
replaced one dying motor - didnt fix any problem except itself.
swapped motor cables around - tried to see if the problem moved with the cable, it does not appear to change anything.
swapped out USB cables on rasp pi - no change
upgraded to makerverse, tried both usb cable to laptop on makerverse 1.1.3 and rasp pi on 1.1.2 no change.
ran simulation in easel without problem.
In makerverse if it stops i just hit pause and play and it kicks back in, but over 1500 lines of gcode so far i have had to reset 9-10 times. I am doing so with router attached but backed off and unplugged so its at full weight but not lagging due to cutting
What else could i do to eliminate or isolate the problem?
I’m still new and haven’t experienced this problem. What are your feed rates for both x/y and z. How big is your full gcode file? How old is the laptop/comp you are using? I started with an older Windows10 laptop (that should have never been upgraded to 10) it was sluggish so I switched over to my just as old Linux and it runs the maslow like a champ.
slowing the feed rate can help avoid this. If your power supply is unable to
provide full power it can help trigger this.
But the fundamental problem is that our firmware does not account for the fact
that the sled (especially when moved via pid loops) does not move from a dead
stop to full speed instantly, so if the position that the firmware thinks the
sled should be is more than 2mm from where it actually is, it triggers this
alarm.
Without the acceleration being accounted for, this is just too sensitive.
Slowing the feed rate and/or tweaking pid parameters may make it less likely to
happen, but it’s still fundamentally broken. So the better answer is to go into
the settings and change the alarm from triggering with 2mm of error to something
like 20mm of error
I was the one who suggested that we add this alarm to the maslow, but we have
found out that without acceleration planning, it causes more grief than it
solves, so just disable it (by setting the allowed error to be large)
my sled is 25 pounds, my counterweights are roughly 25 pounds combined. my angle is right at 16 degrees. I can try to slow the feedrate and see what happens, this makes a lot of sense since it happens so sporadically. I have been running at 25-30 in/min
I did change that setting from 2mm to 20mm in ground and web control, I do not believe you can change it in makerverse, but it did not improve my situation, as it would end up cutting through the middle of a letter as the sled tries to catch up to where its supposed to be.
25 pounds seems a bit heavy, I thought 20 pounds was standard (I know 30 pounds
is too heavy)
having your counterweights at 25 pounds is an issue as well. You don’t want the
pull on the slack side to exceed the pull of the sled on the othe side of the
gear (otherwise the backlash of the gears in the motor comes into play and the
maslow thinks it’s moving the sled while it’s really only moving gears for a
small distance)
you can put your system dimensions into the online spreadsheet to check your
configuration, but a stock system has < 4 pounds of tension on the chain when
the sled is in the far bottom corner, and since the chain is doubled you have a
2:1 mechanical advantage, so you don’t want more than 5-7 pounds on the slack
side. (if you go with a 12’ top beam, you end up a little over 7 pounds tension
in the bottom corner, so you can go to 10-12 pounds of counterweight.
if the sled is more than 20mm from where it thinks it’s supposed to be, you have
rather serious problems. Does this happen in one area of the workpiece? The top
center is where the tension is the highest (And so the motors have to apply the
most power), if you are struggling there, you may find that your power supply
voltage is dipping a bit.
My sled is the weight that it arrived with provided metal bars instead of bricks from Metal Maslow, I don’t even have a dust collection system added yet, which i expect to add a few pounds.
I assumed the counter weight needed to cancel the weight of the sled. but you are saying that i doubled it. The struggle has never seemed anything but random, top bottom, middle, most of the time it appears to happen right after z movement, but not always. right now I am running a 14"x10" project in the center of the wasteboard, speed cut in half to 15 in/mm and every few hundred lines of code it stops.
I am running the 12 foot top bar, I cut my counter weights in half, and ran a couple dry runs router attached but turned off and out of reach. I ran it 3 times, and received an average of 700 lines of code before the first stop, never in the same spot. running it slower has improved this number from an average of 300 lines of code. I have to say that the counterweight chains seem really sloppy on the lesser weight, I’m not sure how this adds up physically. Seems that the motors are now working extra hard either direction
I will look into it being a power supply issue, I have the 3 pronged PS that metal maslow supplied plugged only into my RAMPS board, but I have an extra for my 3d printer which is really beefy due to powering a heated bed and nozzle, as long as the voltages match it should be fine. I will try that next.
as far as the counterweight goes, you aren’t directly countering the weight of
the sled, you are countering the weight of the sled that’s not being supported
by the other chain.
so when the sled is in the far bottom corner, most of the weight is being
supported by the chain that’s close to vertical, only a tiny bit of the weight
is upported by the other chain.
but that would not cause the ‘cannot keep up’ error.
does the software you are using allow you to send arbitrary gcode to the maslow
so that you could check the firmware settings?
my sled, with weights, is only 25 pounds, i have counter weights, instead of springs like the M2, on the other end to offset the weight of the sled, and they currently weight about 25 pounds as well.
I have changed the weight of my counter weights several times now with inconclusive evidence, the problem as always is random, i just got 2300 lines of code out of the same cut at 30in/min before failure, and only 600 lines at 20 in/min a moment before, ran it again both ways and got different results again. i have changed my counter weights repeatedly from 6 pounds to 25 and it doesnt make a discernable difference.
my power supply is 24v 8 amp (192W) so i am not certain it is the culprit, but not sure it isnt. that should be plenty of power. Same PS Metal Maslow shipped to everyone i talked to who has one,
Each counter weight should be around 5 pounds or a little less. I use an gallon milk jug little over half full of water (a gallon of water weighs around 8.3 pounds)
Shooting in the dark here.
Is your screensaver turned off?
Is your computer too old and getting bogged down?
Thank you Tim, I normally use my raspberry pi to run my maslow, but when I do run it from my laptop it acts the same, and no, I’m IT by trade so my laptop is running at top speed all the time.
I misunderstood your weight situation. My read was the sled was 25 and you added 25 to it. My sleds have been 25-35 lbs and those work just fine. Typically a metal sled will need no additional weight. The only time I triggered the same alarm you mention was when the sled caught the router power cord just right and bound up and refused to move, so that alarm did its job and shut everything down. Out of curiousity, what Feed speed are you using in your gcode and is it in inches or mm?
If your counter weights are good (5 lbs), then, Maybe its a issue with how easel is creating the gcode (settings off?) Possibly try a different gcode creator like carbide create, it’s free and easy. I am using carbide create in inches for design and creating grbl gcode in mm output to cut. I have ran 40in/min and never had your problem.
yes, that would make the sled take longer to get up to speed while the firmware
thinks that it’s moving at full speed, and this error is triggered when the
actual sled position and the position the firmware thinks it should be differ
too much.
