Closed Wallacoloo closed 10 years ago
It's possible this has to do with RC thermistor reading; The gcode stream is only checked on CpuIntervalWide, and when the thermistor is being read, it keeps the onIdleCpu function looping at CpuIntervalShort.
The proper fix for this may actually be to translate every, say, 1000th CpuIntervalShort into a CpuIntervalWide, as this would ensure DMA syncronization (another thing done only on wide intervals) is also done regularly.
Edit: indeed, disabling the thermistor & hotend eliminates the stalling.
Making every 2048th OnIdleCpuIntervalShort a Wide interval, or even making EVERY interval a wide interval, does not solve the problem. Scheduler::yield() forces Scheduler::isRoomInBuffer() to return false, so it's possible that a full second is being spent in 1 call to Scheduler::yield(), which forces the state to not add any more events. I doubt it, but it is a possibility.
The other possibility is that there's actually a loop somewhere that causes control to never be returned to the scheduler while the RC thermistor is being read.
Fixed in devel. It turned out that State::onIdleCpu is called from Scheduler::eventLoop() as well, which didn't implement the above logic fix.
Occasionally, the printer will stall for a half second or so at path joints after coming to a full stop. The desired behavior is for acceleration to activate immediately after it fully decelerates (no pause).
This behavior occurs even when using NoAcceleration as the AccelerationProfileType.