Busy:Processing after subsequent extruder motor activation
Hey guys, got a weird thing that started happening with printer. Everything was working fine the day before until i rebooted my pc sooooo nothing changed as far as i'm concerned.
Problem:
After all homing and preheating procedures, I can click on manual extrution for 1, 10, 50mm. I notice that the extruder motor rotates and then there is a pause, then it rotates again and then just stops. When this happens, all other commands get delayed (ie i click home, or jog and the printer takes 2-30s before executing the move). Further attempts to manually jog causes message "Busy:Processing".
What I already tried and same behavior occured:
Any idea what may be causing this?
I've attached my config.json file and RH host logs in the file named configfiles.zip
Thanks ahead for your help.
Problem:
After all homing and preheating procedures, I can click on manual extrution for 1, 10, 50mm. I notice that the extruder motor rotates and then there is a pause, then it rotates again and then just stops. When this happens, all other commands get delayed (ie i click home, or jog and the printer takes 2-30s before executing the move). Further attempts to manually jog causes message "Busy:Processing".
What I already tried and same behavior occured:
- Reduce BAUD rate to lower values
- Increase extruder motors driver current
- Decreased receive cache size to 63 in RH
- Enabled send OK and WAIT in RH firmware configurator
- Re-installed and regenerated RH firmware and Host
- Changed USB ports
- Changed computers
- Changed Arduino DUE board for a new one
- Grabbed a cup of coffee hoping for magic
- Custom built running on Arduino DUE with RADDS shield
- Firmware: Repetier Firmware generated using Repetier-Firmware configuration tool for version 1.0.2
- Host: Repetier Host 2.0.5
- OS: Win 10 x64
- Baud rate: 115200 ANSI
Any idea what may be causing this?
I've attached my config.json file and RH host logs in the file named configfiles.zip
Thanks ahead for your help.
Comments
The question here is which command does cause the busy state and why. So in host log window enable command, ack etc and run commands one by one. Wait until it is executed, not only queued. Then you see the commands send an can exactly say when it happens. One possible thing could be a integer overflow causing very long delays. In radds the delay can be 4 minutes I think it was if a timer was missed. The problem can happen on deltas as there are submoves with reduced precision, especially if extruder has a high steps per mm setting or segments per second is low. But I do not have these infos, so if you post I could say more. Attaching files does not work in this forum.
Thanks for the feedback. Please see annotated logs bellow, I'll try to make a video.
https://www.youtube.com/watch?v=AszB6nnVheM
"ok" is send when command is received, not executed. This reduces latency and increases througput. "wait" appears if buffer is empty for at least 1 second to indicate firmware it could do something.
When you start connection, what does it report as free memory. Should be at least 900 byte. If stack overflows such strange things can happen, otherwise I do not expect such unlogical behaviour. Looking back I see you have RADDS so ram should not really be an issue. The extruder could maybe be explained with overheating stepper driver for overcurrent/bad cooling. Especially a short pause indicates a pause to cool down and after that it continues and then it gets too hot for any more moves. Just a possible explaination for this, but it would not effect firmware starting to block busy at some point as far as I can say.
When moves do not take place any more you can still send M114/M199 to see if commands get executed as these send back some data. M114 is interesting as it shows current position so you see if the moves were executed (even if they do not move). That would mean something prevents physical moves - drivers not working, no main power, ...