I agree, this doesn’t seem like a chain skip, otherwise we would be seeing similar issues across the entire bed. It could be a kinematics problem, but then I wouldn’t expect it to ride up to the proper level at the end of the cut. My first guess would be a motor stall/power issue, especially if it’s at the top of the board, but didn’t see any messages about it. Very strange indeed.
Since I’ll not be able to test, lets agree that before 24 hours a new test was done with less weight. That should narrow things down. Thanks for the heads up guys. Same place, same time tomorrow
Could your linkage kit be sticking, causing the sled to be at maximum rotation before breaking free again to let the router bit get back on track?
Good point! Let me dig in my GF videos, if she caught that part I would be able to see it.
Now that a thought about it more, I think, no.
Part 2 has 3 passes, first is the top cut, second the lowest and third in the middle. Sticking and releasing would be an explanation for that.
Part 3 does all 3 passes at the same cut and error. I would expect a sticking kit to be more random.
Edit: The parts are symmetrical to the middle of the sheet. So I would expect a mirroring rather then a copy.
Definitely something going on in software.
To help diagnose the problem, run it again without a router bit and the router turned off (that way the bit is not in play). I’d wiggle the sled a bit as it progresses from right to left to see if that changes anything. Just a thought as it would help eliminate linkage kit as the source of the problem… and would be safer as the router is off.
I ran it twice yesterday, similar to what you wrote.
Weird thing is, the velocity is around 30 then drops to 14-15 when the arc begins.
if the feed rate is reduced, does it still arc?
Not sure…set feed rate in makercam at 30 for all
I like the theory that this could be a federate issue. A heavy sled near the top could be slowing the motor down to the point that it can’t keep up with it’s target position which would result in the type of general downwards slope we are seeing…then when it gets to the end of the cut it could catch up suddenly and go back to where it should be giving us the jump up we’re seeing there.
I guess the test would be to try at a lower feed rate? We should be seeing that position error showing up in GC, right?
I would have thought that having an encoder and positive positional feedback would keep it from getting very far off the desired track - or at least giving an error. Would it be hard to automatically slow down based on position error?
We should always be able to see the error, and you are right that we could slow down or at the very least display a warning to the user. I’m pretty sure we don’t do anything like that right now, but this might be the reason to add it.
The feedrate in the file that @gero posted was 1000 mm/sec (~40 in/sec). Would be interesting to see if same thing occurred at feedrate of around 20 ipm… at least see if there is a difference.
The sagging line might be caused by a motor controller failing to full power to a motor due to heat.
@gero, you asked about the thermal effect of different PWM settings in a different thread - were these cuts made with a changed PWM value? I wouldn’t think PWM should have a thermal effect, but that’s another variable to be considered.
Feed rate vs accuracy over different areas of the work surface is another set of test that would be good to do, especially across the upper regions.
I had the same issue and I think it was do to the left motor not being able to keep up with right motor. I ended up just slowing the feed rate down and things improved.
I wonder if it has to do with the different PWM clock which should be fixed in latest version.
Very interesting. I don’t know much about the motors, so I’m taking a stab in the dark here, but it seems that we know the motor’s stall torque, as well as their maximum speed (presumably with no load). The maximum speed versus torque is likely some non-flat curve. I wonder if this is a case of exceeding the speed/torque curve.
This is at the top of the workarea, so changes of chain slack shouldn’t be a concern.
The bit is wandering in the direction that it would pull if the feed rate is too high, and there’s primarily only chain tension to counteract it. Lower on the board with the chain angles different they can better resist that pull. I think that if the cut were moving clockwise at this high position, the weight of the sled would help resist the bit’s pull and the line would be straight.
Wow, so much valuable input to narrow it in. Thank you all!
I could convince my boss that I’m not productive on the job and got off till next Sunday, Maslow holidays!
Tests in the making:
- Same weight and half feed-rate counter clockwise
- Same weight and feed-rate clockwise
- Reduced weight (1 brick less) at same direction and feed
and perhaps a combination of some, if those 3 not already show what is going on.
Results in 4 -5 hours from this post.
The log from line 317810 to 318113 shows Idle,MPos: (x moving left), y at 503.00 where it should be the entire cut. The ‘sag’ seems not to be caught.
No, I only played with the setting driving the sled around without a bit. I love how ‘silent’ it was at 31000Hz but am scared it will fry my chips. The cut was done with 490Hz.
Additional info: I went with a slightly aggressive 4.2mm stepdown on a 6mm 2 flute with ~10000 rpm
Thanks again, Regards, Gero