I’m at my wits end. I’ve tried to identify where the error is an i’m at a loss. I haven’t had this problem before. I’m running v.84
The Problem : Maslow has incomplete lettering on this V pocket “S” and makes these pecks way below the “W” when running a Vpocket generated through KrabzCam.
Observations: I understand these pecks to be the V pocket doing its thing to result in accuracy however they are WAY off the mark (see picture). Yet when pecking the UI shows them right on the money in maslow. Moreover the “S” is not complete even maslows and the code the bit begining and begining and ending in th same location.
It’s almost like Maslow gets thrown of when it lifts itself up and has to find that same location again? But then how would the other test letters be that uniform to eachother?
At first I thought it would have to do with the KrabzCam not understanding my 30 degree bit or depth, but this is way too far off for that.
Any ideas? Here is what i put in KrabzCam and photos, as well as gcode etc.
Hmmm that’s a weird one. Maybe a magnet could be slipping?
If you start with the belts fully retracted, extend them out, and then press retract all the machine should print some values in the console with numbers like TL offset 0.3 or something like that. What numbers do you see printed there?
) When retracted the belts and then asked it to go down on the z axis it started spooling out belt! Yikes!
) When i would jog it left or right, up or down, I would always see it stop at the location and then relax the belts more, moving the machine down bit. I posted a video on this before, but now seems more pronunced. I think you said this had something to do withe motors and the jogging mode, and wouldn’t expect it to happen in the cut.
Yeah this is what i thought at first, but it seemed to be off more than that error seems to account for. I was just eyeballing it with the picture and it seems like the ‘peck’ below the W and H are both wayyy out there.
I just found that bug too! Luckily it was fixed in last weeks firmware update.
I also saw this after the changes in 0.85. I was able to fix it by lowering the tension threshold during the calibration process. The default in 0.86 is now 1200 instead of 1500, but you have to update the Maslow.yaml file or change it in settings for it to have an impact.
This actually looks pretty OK to me. It’s the lines further up that would indicate something funny with magnets. “Pulled tight with offset…etc”
Ok. It sounds like an update to v86 would be the way to go and run a complete re-calibration. The only trouble there was I ran into the critical stop during calibration that it seemed like others were running into as well.
I’ll give it another shot next weekend.
Maybe, but it sounds like folks might be having an issue with 0.86 not having enough space to store things in the .yaml file so the quickest solution will be change the calibration tension from 1500 to 1200 in the config settings
@bar , I loaded and then calibrated with v87. I assumed that updated would include your fixes you mentioned above.
Though it didn’t fix my issue with the pecking and lack of complete lettering (see photos), it did seem much more accurate and smooth with it’s movements. Calibration seemed to go faster too.
I’m wondering if the gcode is the issue here and not the calibration. I have uploaded the gcode file if anyone is capable of reading/running it to see if the error is there.
That said after calibration (yes at absolute zero), and then a retract and extend & tension these are the numbers i am getting since you asked last time.
MSG:INFO: Set to comply]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Right pulled tight with offset 0.032]
[MSG:INFO: Bottom Right pulled tight with offset 0.021]
[MSG:INFO: Top Left pulled tight with offset 0.097]
[MSG:INFO: Bottom Left pulled tight with offset 0.032]
[MSG:INFO: Retracting all belts]
[MSG:INFO: Top Left pulled tight with offset -0.064]
[MSG:INFO: Bottom Right pulled tight with offset 0.000]
[MSG:INFO: Bottom Left pulled tight with offset -0.043]
[MSG:INFO: Top Right pulled tight with offset -0.032]
[MSG:INFO: Extending all belts]
[MSG:INFO: All belts extended to center position]
[MSG:INFO: Measured waypoint 0]
[MSG:INFO: Center point deviation: TL: 0.414 TR: 0.326 BL: 1.276 BR: 2.454]
[MSG:INFO: Center point deviation: TL: 0.414 TR: 0.326 BL: 1.276 BR: 2.454]
[MSG:INFO: Center point deviation within 12.000mm, your coordinate system is accurate]
Any ideas, whether on gcode or these BL and BR numbers per this issue?
I tried to run it on my router (grbl-based) just in case, and it came out fine without any of those peck-marks…
Couldn’t see any unexpected movements during processing either.
@HobbyBody I ran your gcode on a grbl/stepper/ballscrew-based router.
Just a few thoughts:
Hysteresis/backlash problem maybe…or calibration related?
Have you tried running it on different locations on your work-area…to see if that makes any difference?
Is there any chance a z-movement can somehow affect the xy-position?
Any loose screws?
Would of course be nice if someone else could run it on another Maslow…
@HobbyBody did you try cutting with just a contour cut rather than v-carve or v-pocket. I have had issues with v-pocket gcode on my classic maslow (gcode was created by a different program as well)
@TimS - Yeah. I did. That seems to work okay, but it doesn’t use the v-bit as desired or its properties. Namely the ability to sweep up with a variable side.
The problem is just weird because the ‘pecks’ are where it is supposed to ramp down and get that detail but it is like the actual route never fully completes (incomplete “o” and such.
Sounds like when you contour it cuts fine and finishes each letter? But gives you the issues only with v-pocket.
Try downloading the free V6 (not V7 it won’t work) version of Carbide Create and create new v-pocket gcode. If you have the same problems than it may be how the M4 handles that specific type of cut paths.
