Just got everything up and running, and so far so good on all fronts… Homing works good, and good test print of the Crown… However, I have randomly had all motion slow down to sloth speed for no understandable reason. This has happened while simply moving the gantry around with the Move Icon on the screen, and while printing of the crown… having seen the speed of motion that should occur during printing of the crown on this rig prior, and during 10mm movements per increment of the knob on the LCD screen, I would estimate that all motion slows down by a factor of 10 or so… insanely slow. The only solution I’ve found is to power cycle the SKR Pro and this instantly fixes it- printing the same file, or moving the gantry…
Any ideas??
I am running Marlin_V1CNC_SkrPro_Dual_2209_2.0.7.2_510 with the BIGTREE_TFT35_V3.0_E3.26.x.bin from this site customized to CNC only use.
The move commands may not include speed. Maybe one of the other commands (Z, perhaps), slowed it down. Try sending G1 F600 in the terminal and then see if that speeds it up.
This is probably not the solution but I had a Rambo board do something similar at one point the problem turned out to be the stepper driver chips getting to hot. If fixed it by adding a fan to the controller box.
So, I seem to have the same issue.@aventinus did you manage to find a solution?
When I boot LR2, and start moving the Y axis using the knob 10mm at each rotation, its starts moving as expected for like 50cm. Then suddenly it starts to slow down up until it barely moves.
When hitting the reset button, it immediatly runs just fine again. I can even start up a job and it runs at normal speed.
But when going back for a long distance, it starts to slow down again, and milling jobs are slow too, until… I hit reset again.
Hey Olivier, Jeffeb3 was correct- It turned out to be due to not having a speed parameter on every single movement line of either my current or previously executed GCODE file. This resulted in unexplained changes in speed like you are describing. Since making this change I haven’t had the issue since.
Thanks @Aventinus I am going to try this.
It sounds a bit strange though because I do have it on a cold boot too, but imagine it can´t hurt to change my behavior
Can I ask what speed you use for general purposes?
On a cold boot, after 3 days without power, the machine slows down when traveling 100cm on the Y axis. A reset gives back full speed, however, an additional travel slows the machine down again.
If I would start a job, when slowed down, everything remains slow.
If I would reset, and start a job, everything runs normal.
In this case, the only movement made, was by using the touchscreen or turning the knob. So I had no option to set any speed.
It can´t be overheating of the driver, because after reset everything works, and when starting a long job, it keeps running normal. When the driver would be overheated, the issue would be there during the job too.
This is rather frustrating, as my workpiece is mounted the other side from my parking spot. So I need to make the movement to my 0 point in multiple steps.
Hope someone knows another potential reason for this issue.
Hmm… As this hasn’t occurred again for me, I can’t be certain of your issue- hopefully @jeffeb3 or another more seasoned user may have some ideas. I do note that all of your comments about this issues center on ONLY the Y axis… can you confirm that this issue can’t be replicated on the X-axis? If the issue is isolated to the Y axis, then I would try plugging a spare and unconnected motor into the Y axis port and confirm it happens on that motor, then plug that unconnected motor into X axis port on the board and try a 100+ cm move and see if it happens there too, etc. to isolate the source of the issue. Two thoughts: 1. I would suspect a firmware issue since it is very repeatable, happens on manual moves after a cold boot, and without having run any gcode. 2. 100cm or over 40 inches is far larger of a move than I make on my mpcnc and probably most people do (compared to the lowrider), so the fact you aren’t seeing the issue until making such a large move is also another observation that may help isolate the issue. Welcome thoughts from the community- I know these types of issues are painful after all the work building your new system.
Everything just works fine, as long as I do not make long travels over 1 axis. And when I do, a reset solves it immediately. (frustrating thing on a reset is that my Z is no longer square). I´ve had a job now running 1,5 hours, without issue. How strange is that?
You can hear and see it slowing down, up until it barely moves like a millimeter per second or slower. Will see if I can capture it on my phone and post a video.
The only thing I can imagine as a quick fix, is try to make a script so it runs towards my expected zero point, so I need to move as little as possible. But that´s a challenge
I see I mentioned this previously, But I figured I would add some details. I had a Rambo Board do something similar a while back. Not exactly the same but similar. In that case it turned out to be the control board/driver chips getting too hot. After a few minutes of work they decreased power (Current) to the stepper drivers in order to prevent damage. Reboot would reset. I started by increasing current to dangerous levels. I eventually solved it by adding a big cooling fan to the control board. Then I was able to lower the current back to reasonable levels.
I was considering the same potential cause at first. But, strange thing is, that when this happens, and I reset, and start a job of 1 hour - it runs fine. So because of that experience I would eliminate the heating issue (it should have the same issue during the milling)
Ofcourse I can add a fan, maybe I should try this, but the behavior is not as expected (plus the workshop is now only 14°C - so should take sometime to overheat)
A shot in the dark, but perhaps this is a communication problem. If the sending/reading of g-code becomes an issue after some time, then movement would slow as the board waits for new g-code commands. If this is a possibility, look to your SD card, SD card reader, USB cable, or tethered computer (whatever you use to send the g-code).
Do you have the ability to send gcode commands through a terminal or command line interface, or are you limited to the menus on the LCD display? Is there any way to log or mirror the commands the board is reponding to?
I’d be interested to see if the issue arises when sending a specifically crafted gcode command, and what commands the display was sending to the machine. I agree with @jeffeb3 that it sounds like the max feed rate is getting changed somehow.
No, I’ve kept all settings in stock settings as I am still trying to get familiar with all those options.
At the moment most I get the feeling one has when (s)he enters a flight cockpit:) so many switches and options
Thing is, I have the issue without running any Gcode. When I do run code, I only experience issues when the machine is already functioning awkward. So I quickly learned to reset before starting the code.
Maybe you’re on to it:
When I power on it says “no printer connected“ for like 10 seconds. Then it goes away.
In those 10 seconds axes don’t move. When the message is gone they do.
I once noticed, when traveling Y turning the knob, there was again a brief message of “no printer connected”.
Yes! This I can do, Marlin has a Terminal window. I once wanted to Ryan and enter a move code including feed rate, but the letter for this seems to be missing
I am going to see if there’s somewhere a log been kept!
You should know that the menu commands are sending gcode, and there are gcode for changing some of the Marlin settings so it is possible that the menu option got changed somehow to slow things down. You can also check to see what the settings are with an M503code. Try displaying the current settings, then the long Y move, then display the settings again and see if anything changed. Check the Marlin command reference page for the commands to put any changes back the way they were to see if performance goes back to how it was.
