Since this week I also started having this 15mm error every once in a while.
I noticed that on my setup it occurs when I set up the machine Retract All > Extend all > Apply Tension and then start setting my Z-height to eventually define Z-Home … the Bottom Right belt immediately gives slack from the moment I touch the Z-up or Z-down button.
From then on I have the feeling the Bottom Right belt gets more and more slack every time the Z-axis moves up or down during the execution of the G-code, eventually resulting in a 15mm error somewhere along the code.
I tested with 4 cuts in a row, altered the code slightly every cut.
When I set a Z-safety height of 5mm when travelling without cutting, it takes more time for the error to occur. When I set a Z-safety height of 20mm the error comes faster.
On a slower speed (2400mm/s) it also takes more time for the error to pop up.
The fastest the error occured was with a faster cutting speed (3200mm/s on a 3mm stepdown with a 6mm two flute straight bit) and with a Z-safety height of 20mm.
I’m cutting phenolic plywood with a waxed sled, so least friction possible I would assume.
Hardly any static build up as far as I can tell when coming close to the vacuum hose and not a lot of dust in the air.
I was wondering what the conclusion is for now on this error and how to best try and solve it?
Oh this is interesting! Thank you for reporting your observations. I’ve seen that error before, but I always use a safety height of 10 in every cut so I didnt realize it may be related. Ill run some tests too and let you know how it goes.
That would explain why my 15mm errors have always seemed to occur in the same area of work piece - I’ve never altered the speeds and it was running the same z-home and z gcode movements each time.
Oh this is interesting! Thank you for reporting your observations. I’ve seen
that error before, but I always use a safety height of 10 in every cut so I
didnt realize it may be related. Ill run some tests too and let you know how
it goes.
The maslow 4 doesn’t have the insanely slow Z axis that the earlier version did,
but because of that, I always set the safety height really low, 1-2mm (depending
on how much I trust the zeroing of the bit)
Had some more time to go at it in the workshop.
All my cuts keep failing … even after grounding the vac hose, grounding the sled, hot-glueing the CAT cables in place and re-calibrating endless times.
Here is the serial log and the g-code file from the last fail, the belts feel tight after the forced stop but the system gives 15mm error on 3 of the 4 belts. Maslow-serial.log (7.3 KB) SD_inside - normal F2100.nc (9.0 KB)
When I do a “Set Z-stop” it goes all the way to -134mm, but in reality it is 10mm above the surface … so I have the feeling it has something to do with the Z-value parameter in code going off track somewhere during cutting.
What more can I do about this, so I can cut at least 1 file entirely?
We’re working on a hardware fix that we’re hoping should take care of this, but the company making the new cables is running a little behind schedule. We should get the new cables for testing this week.
This does seem wrong. When are you using the “Set Z-Stop” button?
I saw Anna reset her Z-stop before a job in one of the videos. So I thought I would also try it.
I do it whenever the tension in the belts becomes to saggy. And then after it the displayed Z distance below the jogging interface is always very much off.
For example, i’ve reset the Z-stop earlier today and 4 cutting attempts of about 1 hour total cutting time later the Z seems to be off by 42mm if I set my XY home and read the coordinates in the log screen.
So i’m thinking of doing a Z reset before every cut from now on, because I notice the belts having a much better tension after doing so.
The week link seems to be the connectors so I planning to swap them for JST-XH connectors which are better with dust and vibration and lower the value of the pull up resistors on the SPI lines from 2.7k to 1k. It’s not a major change, but I’m hoping that it should make things more robust.
I sincerely hope that is it. But many of us are having the same problems after all he remediation steps (hot glue, grounding the DIR pin, grounding everything else) - for me I still get 15mm errors almost immediately when trying to run a job even though calibration seems to always work fine. I’m struggling to think it is a connector issue when the problem is SO frequent and consistent.
Now that I read this, I have had a couple errors when setting the Z home height. The machine errors out and then I have to extend all the cables and then retract them again and power unit off and on before it will act right.
Rather than wait for the next batch I’m considering making a direct link between encoder and main pcb, replacing the ethernet connectors and connecting midway.
Rather than me buzzing out connections is there a wiring diagram showing the corresponding links?
Rather than wait for the next batch I’m considering making a direct link between encoder and main pcb, replacing the ethernet connectors and connecting midway.
Rather than me buzzing out connections is there a wiring diagram showing the corresponding links?
You can find all the schematics here: Source — Maslow, but @dlang is right that it’s probably easier to just know that the connector will be identical on both sides since the cable is reversible.
I am having the identical problem that Dennis is having. Since gluing in new super-flexible RJ45 jumpers, I no longer get encoder errors, but I am plagued with 15mm errors that now effectively prevent me from using the Maslow. I also concur that Z movements are triggering xy movements that inevitably lead to this error, killing the job. When I reset, retract, extend, send it home and try to restart the cut, I usually get the 15mm error during the 4th pocketing operation of the same job. It happens with or without the vacuum attached. Added evidence that Z moves are triggering xy moves is that if I reset/retract/extend and I try to manually move my Z, the xy belts move.
So while I am sure that the JST connectors absolutely solve the encoder disconnection problem, this is a different problem altogether. Z movement is, without question, causing xy movement somehow. While it seems possible that this is a hardware problem, it seems far more likely that it is a software issue.
I am having the identical problem that Dennis is having. Since gluing in new
super-flexible RJ45 jumpers, I no longer get encoder errors, but I am plagued
with 15mm errors that now effectively prevent me from using the Maslow.
did you try grounding the encoder pin?
I
also concur that Z movements are triggering xy movements that inevitably lead
to this error, killing the job. When I reset, retract, extend, send it home
and try to restart the cut, I usually get the 15mm error during the 4th
pocketing operation of the same job. It happens with or without the vacuum
attached. Added evidence that Z moves are triggering xy moves is that if I
reset/retract/extend and I try to manually move my Z, the xy belts move.
As the Z axis moves away from the workpiece, the distance from the anchors to
the arms increases (the triangle of the x/y and Z is getting bigger), so the
motors spool out some belt to allow for this.
If the belts remain tight all the time, this should not result in any movement
of the sled, but if you have a bad calibration and your belts are at all lose,
this could result in sled movement.
No. I don’t know how to do that. Are there any instructions you can point me to?
The xy movement that I witnessed when I manually told it to move z by 1mm was far too great to have been compensation for a change of 1mm to the XYZ triangle. Is there a setting somewhere that would allow me to adjust the level of compensation that xy makes to a z movement?
I have not been able to complete a calibration in a long time. It takes a long while but inevitably ends with WARNING FITNESS TOO LOW. DO NOT USE THESE CALIBRATION VALUES!
This issue is usually caused by one of the magnets rotating in the roller or less commonly by frame flex.
The way to check for magnet slipping is to do Retract All → Extend All ->Retract All again and look at the values that are printed out. Ideally all the numbers will be close to zero