V-E-R-Y S-L-O-W motor movement

Software / Firmware SKR Boards
1

I’m hoping that someone can rescue me from what is apparently my failing memory…

This relates to (non-dual endstop) Primo build that was completed nearly a year ago. It uses the SKR1.3 board, the TFT 35 display and TMC2008 stepper drivers. I used the V1 version of Marlin, and according to the downloaded file, it was “Marlin_V1CNC_Skr1p3_2209_2.0.6.1_505-src”, downloaded in September of 2020. I was able to get it running with few complications, and eventually printed out the crown and did a preliminary job to set up a spoilboard, that was flattened and had some holes cut for threaded inserts. I use ESTLCAM for all this and it worked. (This is actually the second MPCNC, the first one being a Burley, and the third one being an “in-progress” LR.)

After that preliminary work, I had to put the project aside for a while, so, it has not been touched since January 2021.

This week, I went to get it fired back up and work on a new project, and ran into a problem that I have a memory of from January, but cannot find any reference to a solution. The motion of the steppers when under gcode control is EXTREMELY slow. I mean, at least 10X slower than it should be. In fact, I tried to run a gcode file on the Primo after running the same file on the Burley, where it ran at normal speed. It would have taken hours to complete, instead of the 50 minutes on the burley.

It should be noted that this occurs ONLY when it’s under gcode control. Manually moving the motors results smooth movement at normal speeds, so the steps per mm must be OK. (As far as I can tell by inspection of the old PlatformIO file, it is just the default values.) And, since the same exact ESTLCAM-generated gcode file runs slow on the PRIMO and normal on the BURLEY, it doesn’t seem that this could be the issue.

I have a sort of vague memory that I briefly suffered from this same problem back in late 2020 when I was first getting it going, but it was obviously solved since I believe that both the crown and spoilboard were normal speed. However, I have been unable to find any reference to a solution.

I also have some vague idea that it MIGHT have something to do with the display, which of course can be in either Marlin or BigTree (Touchscreen) mode, but, I tried both and there was no change. (And, this doesn’t make sense to me anyway.)

Finally, I should add that the firmware has not been touched in any way since it was first functional back in January 2021, so, this is not a “new” problem. But, hopefully someone will recognize what must be a trivial issue and offer the solution.

Thanks.

2

What’s the first few lines of gcode?

3

As I indicated, this file runs at normal speed on the Burley, but is slow on the Primo. The Burley uses an MKS Gen L control board.

;Project digital joints_V5_2
;Created by Estlcam version 11 build 11.240
;Machining time about 01:23:04 hours
;Tool list (1/4"DownTroich)
(1/4" Downcut)
(End mill 1/8")

G90
;M03 S24000

G00 Z5.0000 F400

;No. 1: Part 7
;Tool 10 1/4"DownTroich
G00 X47.5391 Y124.0401 F2100
G00 X48.7898 Y123.8196 Z0.5067 F400
G01 X48.7325 Y123.6057 Z0.4809 F120 S24000
G01 X48.6390 Y123.4051 Z0.4618
G01 X48.5120 Y123.2238 Z0.4427
G01 X48.3555 Y123.0672 Z0.4169
G01 X48.1741 Y122.9402 Z0.3795
G01 X47.9735 Y122.8467 Z0.3287

4

Hrmmm… All I can think of is that the touchscreen is sending a preamble of some sort that’s messing with the speed. Are the steppers actually spinning slower, or are the individual instructions just getting sent very slowly to the controller?

5

I’m not sure how I can determine this, but, long-ish, straight moves are also slow when under gcode control, so I believe that the motors are spinning more slowly. Also, when using the Marlin version of the TFT35 (non-touchscreen), the movements are also slow.

6

That’s also good information. Not necessarily for me, but for the gurus who will be along shortly to straighten everything out… :wink:

7

The strange thing I see here is this:

G01 X48.7325 Y123.6057 Z0.4809 F120 S24000

The F120 sets the feedrate to 120mm/second which both slow and used for all the subsequent moves. Are you sure that both machines are treating the values as millimeters? Inch mode must be enabled in the firmware (which it is not in the V1 maintained versions of the Marlin firmware), and it can be set with a G20 when enabled.

1 Like
8

Estlcam slow
Estlcam slow986×709 16.8 KB

Check this parameter so that for “rapid” movements, it will send the feed rate every time. This isn’t needed if the firmware always assumes that “G0” is a rapid feed, but Marlin will often just keep moving at whatever feed rate was last set.

9

This box is not checked in Estlcam, but, this leaves me puzzled because the exact same file behaves differently for the two machines.

Also, what are these coordinates, I, J, F, S, N?

10

Both machines are set for mm, as is Estlcam. Also, the Burley has been in operation since 2019 and never had this problem, yet the F120 is in nearly all the files that have ever been used on that machine. (There were a couple of purely engraving files that had higher values.) The firmware on the burley has not been touched since it was initially loaded back in 2019.

I’d be very suspicious of something having changed in EstlCAM since it was just updated, but, the file in question (have not checked many others) was prepared with the new version and behaves normally on the burley but is slow on the Primo…,

11

As a test, edit the line so that the feedrate is 1200 instead of 120:

G01 X48.7325 Y123.6057 Z0.4809 F1200 S24000

Then do a dry run (router off, bit above all obstacles) and see if you get a 10X speedup.

If you get the speedup, you can then author a rectangle sized so that it will be near the edges of your spoilboard and create a path in EstlCAM for the rectangle Then you can dry run it and time how long it takes to trace each side. Given a distance and time, you can see which machine is accurate with the speed. With a feedrate of 120mm/min in the g-code file, I suspect that the Primo is the accurate one.

There are also max feedrate settings in the firmware that could be playing a role. They can be set manually or they can be set using g-code. This is the line in configuration.h:

#define DEFAULT_MAX_FEEDRATE { 50, 50, 15, 25 }

Note these values are mm per second but the feedrate set in the g-code file is mm per minute. Also if you’ve set the max feedrate using g-code (M203), the line a above in configuration.h will be ignored until you do a factory reset.

12

I and J are coordinates for arc commands (G02/G03) S is sometimes used for spindle speeds, or laser power, N? Not sure offhand. It doesn’t cause a problem.

I also had the same problem when I upgraded Estlcam. Why it works with the one machine? Maybe that one sets speeds for G0. G0 is supposed to be a non-print “rapid” move, so that option exists. I’m not looking to save bytes in my gcode files, so I’m happy having those parameters repeated every time.

I turned off the “S” parameter though, because Estlcam’s Marlin processor uses it for spindle speeds, but I’m using RepRapFirmware, which thinks it’s an obsolete homing parameter, and spits out an error when it encounters it. (Still cuts fine though.)

Just see if that fixes the problem. It isn’t likely to cause a problem with the Burley at all.

13

F120 is 2mm/s, or 120mm/min. That is pretty slow. F1200 is 20mm/s, which is quite a bit faster.

I think that setting is set by the toolpath settings. Is it possible you have a 2mm/s feedrate on a tool and didn’t mean to?

14

The example gcode that I posted earlier is perhaps an unfortunate example. It was a piece that was getting cut using trochoidal cutting. And, the first few lines are probably not enough for diagnosis.

I just prepared a new Estlcam file for a simple 200mm square, using a simple cut that is specified to proceed at 20mm/s. My interpretation of the resulting gcode is that it is exactly as it is supposed to be–for the actual cutting moves, the speed is specified to be “F1200”.

I have not yet tried to run this example on either machine, but will do so shortly. Hopefully, this will help to clarify that the toolpath getting generated in Estlcam is correct, at least for this simple piece.

;Project test square
;Created by Estlcam version 11 build 11.240
;Machining time about 00:00:43 hours
;Tool list (End mill 1/4")

G90
;M03 S20000

G00 Z5.0000 F400

;No. 1: Part 1
;Tool 2 End mill 1/4"
G00 X21.8250 Y25.0000 F2100
G00 Z0.5000 F400
G01 Z0.0000 F120 S20000
G01 Z-1.0000 F120
G03 X25.0000 Y21.8250 I3.1750 J0.0000 F1200
G01 X225.0000 F1200
G03 X228.1750 Y25.0000 I0.0000 J3.1750 F1200
G01 Y225.0000 F1200
G03 X225.0000 Y228.1750 I-3.1750 J0.0000 F1200
G01 X25.0000 F1200
G03 X21.8250 Y225.0000 I0.0000 J-3.1750 F1200
G01 Y25.0000 F1200
G00 Z5.0000 F400
G00 X0.0000 Y0.0000 F2100

M05

15

If it was trochoidal, then that requires a lot of little arcs. If estlcam is set to not use arcs, then it writes huge files to break down each arc into a bunch of lines. Too much gcode can slow down the serial or sdcard connection. If it is using arcs, then Marlin has to compute the lines from the arc commands. There is a fine balance there and turning arcs on or off can help sometimes.

16

Interesting. I’ve been sometimes using trochoidal because it seems to work better when cutting sharp corners on fairly thick (e.g. >10mm) material with fairly narrow bits (e.g. 1/4") But, it is obviously slower.

In the meantime, I did the test with the above file for the 200 x 200 mm square. It printed in about 45 Seconds on both the Burley and the Primo. Now, I’m really not sure what was going on initially. I guess I’ll just proceed with trying to get the Primo into service and see what happens. (I hate these kinds of mysteries!!)

17

Sounds to me like your running into a firmware diffrence. Marlin has changed a bit since 2019. So it is possible that a setting (such as enabling arcs) is set one way on your burly and another way on the primo. When the gcode generated uses the command, the burly ignores it and proceeds on its Mary way. The primo tries to use it but, because of other settings/hardware, it does so at a much slower speed.

Probably best not to think about trying to compare the two directly, but rather focus on the primo and figure out what what gcode is slowing g it down. So test a bunch of different g code files and see what works and what doesn’t.

18

Sorry for the late response, but I just had similar issue when I fired up my mpcnc for the first time. The crown took an hour to draw before I discovered my issue. When setting the speeds, I had inadvertently set to mm per minute vs mm per second. Second crown took 1 minute to draw and I was being conservative with the speed in the gcode. Just my 2 cents…

2 Likes