Maslow4 keeps failing in the midle of a job

I’ve had lots of issues trying to get my first successful cut. The first one is that the machine hits a >15mm alarm and stops moving. I have to pull the router down retracts the belts and then undo them put it back up and take the slack back before I can even try again.

Next is that the bottom left motor seems to unspool much faster that the other motors when moving the router towards the top of the board.

1 Like

Not sure about your first problem, but that bottom left motor unspooling too fast makes me wonder if there is an error in your calibration or perhaps a bug in the firmware. It is supposed to use your calibration to determine how much to spool out those belts that need to spool out. How good was your calibration? Have you upgraded your firmware and the other files since your calibration?

2 Likes

After doing some more research I came to the same conclusion so I redid the calibration and that seemed to help but there is still more give then I would have thought. I also noticed that when I move the z-axis it loosens the bottom right anchor belt

2 Likes

Are you running 0.73? I was seeing that same issue and 0.73 has a couple changes to fix exactly that.

Yes I am, I recalibrated again and that helped quite a bit

1 Like

@bar, I debated about starting a new topic but thought I’d post here based on the title. I too am again having a job fail in the middle but when it does the machine seems to loose all concept of where it is going and tries to travel outside of the workspace (and very far from the piece).

Here is what I know: I recalibrated last night with 0.73. I initially calibrated with a 1200x1000, 9x9 grid and succeeded. I think attempted a larger 1600x1400 calibration grid, but that failed with fitness too low, so I calibrated a 3rd time with a 1200x1000 grid again and that succeeded with about 0.54 fitness.

Today I set up the machine to cut a relatively simple and small job in MDF. I set the machine up and started the job and things appeared to be running fine. Then less than half way through the job, the machine just seemed to lose all knowledge of where it needed to go and drove itself all the way to the extreme edge of the workspace. It only stopped because the TR and BR belts were almost straight but I believe the machine was still attempted to take up more tension. When I pulled the pins on the 4 belts, the machine very slowly (a slow creep) proceeded to pull in all 4 belts (without me providing any commands). The longest extended belt probably took 5-7 minutes to retract all the way in.

I captured the logs but don’t see anything there except the job appeared to be running, then No Heartbeat errors started.

I’m attaching the logs, my calibration results from last night, and the code file I was attempting and some photos of the aftermath in case you are able to glean any information from them. One photo shows the workpiece and what it was doing just as it started moving to the wrong place, the second photo (while not too helpful) shows that the machine ended up about 5 feet to the right of the job and stretching the right belts.

It is curious to me that you can see the machine did some circles before veering off course entirely. I haven’t looked at the gcode but from past experience I believe it was routing the pocket around the rectangular edge.

maslow-ending-location Small
tablet-holder-fail Small

Tablet Holder.nc (333.9 KB)
tablet-holder-joblogs-fail.txt (10.6 KB)
05-19-calibration-result.txt (20.2 KB)

1 Like

This sounds to me like the motors weren’t getting any commands at all and were simply continuing to rotate at the same speed that they were before it crashed.

I’m not 100% sure if this is the same issue as the emergency stop, machine position error greater than 15mm issue that we were seeing, but it seems like there is some general robustness while cutting issue that needs to be addressed and it’s top of my todo list.

Could all these odd behaviors be related to proximity to the router? I started to think about that last night when I was reading that others have successfully done test runs but then have issues as soon as starting to cut. I may run some experiments myself to see if dry runs ever encounter the same problems.

How easy would it be to source some 12" extensions for the motors to experiment with running with the controller removed from the router to see if that affects behavior?

2 Likes

The only other thing I can think of is that the resistance from cutting causes issues after some threshold, of either a single instance or from things adding up during the cut.

Issues with the router running during a cut could be ruled out by running the jobs with a z home that keeps the bit out of the material (or without a bit at all) and the router turned on. If that’s somehow causing interference, it should still do so even if a bit is not making chips/dust or creating resistance from pushing against material while cutting.

1 Like

I just took another look at my machine after the failure last night. One of the problems I missed last night is as the machine hit the limit to move off the side of the board, it continued to spool out the trailing belts, which eventually hit the end of the spool and as the motors continue to attempt to spool out more it actually started to wrap the belts in reverse. (I don’t believe the belts were damaged though.)

Now the question is how can I get the machine to unwind those two spools so I can then get them wound properly when I do a Retract All? If I do a Retract All first, I am worried it will cause more problems.

If you have a DC voltage supply you can just drive 24v into the motor connector. reverse polarity to make it turn the other way

Once I thought for a minute I realized if I made sure to adjust the belts constantly then Retract would extend until hitting the bottom of the spool and then fully retract the belts again - which it did. I’m fixed.

4 Likes