Revert "Over Speed Warning"

[BarbourSmith]

Reverts MaslowCNC/Firmware#410

I'm getting warnings pretty much all the time and I think they are somehow leading to buffer overflows. I'm going to take these back out for now and re-open the original pull request which I think I was too hasty to close

[krkeegan]

Interesting, if I leave the max feed at 1000 I see them a lot in the corners, with 700 I rarely if ever see them.

[davidelang]

Bar, what are your machine dimensions (especially y-offset)

[krkeegan]

I wonder if we lost speed when we changed how the pwm pins are setup. This would kind of explain why I predominantly see over speed warnings with only one of the motors

[blurfl]

Not much has changed in motor.cpp besides that, you might be able to swap that file out to test...

[blurfl]

Which motor gives the most warnings?

[BarbourSmith]

@davidelang I'm using the first version of the default frame that I built which has the low y-offset (about 12"), but I was getting warnings even in the middle of the sheet.

@krkeegan I think the idea that we may have lost some power in re-configuring the motor control pins is a reasonable hypothesis. The reason I lowered the max feed rate is that I was running into issues during the calibration process where the machine hadn't finished moving before starting to cut the indicator lines which wasn't behavior I'd seen before which is why I think something changed.

It seems like maybe we aren't loosing speed when running under limited load, but when the motors are under strain we have less power?

[krkeegan]

My left motor, I think I am on the beta board? I can't remember, but that motor used to sound different.

In my case I see a lower speed when the sled is at the bottom right and I attempt to move directly right. It almost looks like there isn't enough weight on the left motor at that point.

[blurfl]

The change in sound for the left motor would be due to that motor no longer running off the TimerOne PWM. I've been reading your excellent wiki article about PID tuning. Is this something that the B13 command would help test? I've also been reading about (big) calculation slowdown issues in stdlib math functions when a transcendental function approaches zero. No idea whether that has any bearing on our environment, though.

[krkeegan]

I have no idea about anything transcendental and math.

Wasn't the change in sound accomplished by pwm'ing one of the direction pins? I thought one of the concerns with that was that during the "off phase" of the pwm, the motor may be actively braking rather than coasting?

I don't think B13 would be much help, I think all you are going to see is that a higher voltage is required to achieve the same speed. I think B16 the voltage test may be more of what we want. Something like

B16 L1 S220 F255

Would test the left motor at specific voltages starting at 220 and going up by 1 every 200 ms until it hits 255. At each step, the serial log will report the resulting rpms of the left motor. If you placed the sled in about the same position and tested this with and without the PWM pin swap, this may identify a discrepancy.

[blurfl]

The trig functions were the focus of the issue with stdlib math. The dynamic braking could occur any time both motor leads are at the same voltage, so that shouldn’t be different when the PEM signal is applied to one of the motor leads. The B16 test sounds a good one, another would be to start from 0,0 and apply a ‘go to xx’ ( one of the B codes like the “extend chains “ code uses , can’t look it up from here) and measure the time it took to travel that distance.

[blurfl]

I've tested the current firmware against v1.04 which was the last before the PWM change. I used: G91 G21 F1000 B09 L1000 G90 This moves the left motor a distance of 1000mm at system top speed, in this case governed within the B09 code to 800mm/min. Both firmware versions take 75 seconds to complete this, within a tenth of a second or so. The PWM is running at ~34% (1.7V) due to the governor in the B09 code. With the governor in B09 removed, the run lasts 27 seconds in both cases, the PWM approaching 100%. From this, it looks to me like the left motor runs at the same rate with the current PWM pin approach. Admitted, this was run unloaded, with no weight on the chain. I don't think that matters in this case. A side note, it reminded me of the rattling that the left motor did when controlled by the TimerOne PWM...

[krkeegan]

Didn't 1.04 introduce the swap in the pins so that it avoided TimerOne? Or am I reading our release notes wrong?

[blurfl]

You're right. V1.03 was the last before the changes. I just ran the same tests against that, the timings remain the same as above, though, bot governed and ungoverned.

[BarbourSmith]

Excellent test!

I think we should run the test with a loaded with weight on the chains, and if we see the same results lets put it to bed

[krkeegan]

I honestly don't know where our speed went then. Maybe the motors are ageing? Is that a thing?

[blurfl]

where our speed went then. Maybe the motors are ageing? Is that a thing?

Damage to the h-bridge is a thing...

[blurfl]

I think the sequence I described might show a damaged h-bridge by a difference in runtime between the two motors, the damaged one taking longer to complete.

[blurfl]

I've repeated the tests with a 26 pound sled attached. The timings are the same as in the unweighted tests.

[BarbourSmith]

I think we're save to say that I just stated upping the max feed rate too much. I feel good about the current system where we have a probably pretty conservative setting as the default, but then if we want to go faster we can change the setting.