First off, a big thank you to Ryan for the awesome design! Super impressive, fun, and addictive to work with.
I’m working with a Burly MPCNC build, everything bought from V1 (except the rails). Control board is a Rambo 1.4. I’ve spent the last couple months working out kinks with leveling and squaring and developing a workflow that works for me. Now I’m moving on to more advanced stuff and am having an issue where my jobs are taking 3 - 4x longer than predicted by ESTLCAM and Repetier.
Do people generally see the ESTLCAM predictions being accurate for cut times?
Trying to think through this, and here is where I am at: calculating the cut time based on feed rates should be relatively simple in software, so the predicted time should be accurate (based on theoretical feed rate). So that makes me think it is a hardware issue.
If the problem is hardware, I would think the source would be either drivers, motors, or wiring. My thought is that I have to be losing current somewhere.
The Rambo uses A4982 drivers. The MPCNC uses 1 driver to drive two motors (for both the X and Y axes). Is that possibly splitting the current and leading to the feed rates being lower than my input in ESTLCAM?
I didn’t trim the cables that came with the kit, so I have a lot of extra wiring coiled up in a box with the control board. Has anyone had problems with current loss through excess wiring, or coiling the excess wiring up? (my background is engineering but definitely not electrical)
Any thoughts or tips for troubleshooting are appreciated!
Steppers don’t work that way. The drivers send current through one coil, and then the next a little later. So the microcontroller has complete control over the speed. If any of your worries were happening, you might skip steps, but not slow down.
More probable reasons would be:
Estlcam doesn’t know about the acceleration limits imposed by the firmware. So the time it takes to get up to speed isn’t accounted for.
Estlcam doesn’t know about the speed limits in the firmware. If you send down 1000mm/s, the firmware will only move at 50mm/s, or whatever max speed you have set.
If you have steps/mm right, and you were doing something else to compensate, then that could affect the timing.
The Z is especially susceptible to max acceleration and speed. So gcode with lots of little moves will take longer.
You can adjust these with gcode. But the faster you go, the more likely you are to skip steps.
Good points about acceleration. I’m operating well under max feed rates set by the firmware. Usually 18mm/s, with limit at 50mm/s.
I’ve been doing some intricate jobs that have lots of small cuts, and I bet acceleration plays a big factor there. ESTLCAM estimates it around 45min and it ends up taking close to 2hr.
I’ll have to time it on a simpler cut and see how it compares.
We all drive cars, so it makes sense to think of current as the throttle or something, but steppers are weird. The speed comes from the speed the driver changes which coil it sends current through, not hos much current. More current means it will hold that spot with more torque.
If you thought about climbing stairs (and you are taking them one at a time). The speed you climb the stairs is related to how fast you step. Left, right, left, right. If you are weak or strong (current), you still go up the stairs at the same speed as long as you are stepping at the same speed. If you are stronger (more torque), you can carry more stuff. If you try to carry too much, and you are not strong, you will fall down the stairs (skipping steps). You are using strength by just standing still on the stairs.
Steppers are very strange. Unless you have learned about them, I wouldn’t expect anyone to understand them intuitively.
Motors in general are weird. More voltage = more (potential) speed, more current = more torque, which seems backwards if you think of it as force and displacement (technically rate of displacement) like a water hose analogy.