Feed Rate discrepancy in X and Y

Troubleshooting
1

Hi All,

I’ve recently received my “2021 M2 Automated Cutting Machine Kit” and am currently having fun setting it up and doing some initial trial cuts. Off the bat I noticed that the feed rate in the x-direction appeared to be slower than the y-direction, so today I took a bit of a deeper look into it.

Using the following g-code, I made 3x straightforward moves: one 500mm in the x-direction (0,0 to +500,0), one 500mm in the y-direction (+500,0 to +500,+500) and one 707mm long diagonally back to (0,0).

G90
G21
M05
M0 ;T102
M03S16000
G0X0.0Y0.0Z7.00
G1X500.0F500.0
M0 ;T102
Y500.0F500.0
M0 ;T102
X0.0Y0.0F500.0
Z7.00
M05
M02

The intent here was to use a feed rate of 500mm/min for each of the 3x moves.

I then timed each move with a stop watch and calculated the corresponding feed rates. The results were:

Move 1: 72sec, 417mm/min
Move 2: 44sec, 682mm/min
Move 3: 92sec, 461mm/min

I thought this was a little strange considering:

  1. I requested 500mm/min
  2. The observed feed rate was not constant per move

I followed up with a second measurement - this time using 762mm/min (30in/min). The results this time were:

Move 1: 48sec, 625mm/min
Move 2: 30sec, 1000mm/min
Move 3: 60sec, 707mm/min

Changing the requested feed rate from 500mm/min to 762mm/min corresponds to a scaling factor of 1.524. The measured scalings per move were:

Move 1: 1.5
Move 2: 1.47
Move 3: 1.53

so even the scaling doesn’t look constant per move.

Has anyone observed this type of behavior before? I can’t imagine it’s intentional but being new to all this, perhaps I’m overlooking something. Any input here is greatly appreciated.

One last thing - the feed rate reflected in the “Status Reports” portion of the “Makerverse” GUI did show the desired feed rates in both experiments.

Thanks !

2

That is very interesting. That does make sense because in the vertical direction the speeds of the motors add together so it is possible to move much more quickly, however the firmware should correct for this.

How accurate are the side lengths?

3

Hi Bar,

I’ll immediately have to show my ignorance and ask what you mean by the “side lengths”. Are you referring to the lengths of the front legs? I built the standard frame per “Assembly_6.15.2019.pdf”. In general I at least attempted to be very careful with all measurements and cuts. While I’m no carpenter, the frame is pretty level and square. After running through the MakerVerse calibration steps, I most recently ended up with 1.7mm accuracy. If I recall correctly, 1.2mm was the best I’ve every managed to achieve.

Thanks !

4

Sorry, that’s my bad I wasn’t clear.

What I was thinking is if you measure each of these moves

(or cut out a square) what are the actual measurements of each side?

5

Got it - thanks !

I adjusted the original code (the version with the x & y feed rates at 762mm/min) to include a small z-plunge at each of the three positions, i.e.:

Z-1.0F100.0
Z7.00F100.0

I then measured the distance between each of the points.

Move 1: 500mm +/- 0.5mm (pure X)
Move 2: 501mm +/- 0.5mm (pure Y)
Move 3: 709mm +/- 0.5mm (diagonal move)

So nothing way out of the ordinary there in my opinion. To be honest, I didn’t expect to find a smoking gun here as I’ve already performed a few cuts and they came out fine in terms of dimensions.

Nonetheless, I then did a fresh repro measurement and got similar numbers (within the measurement tolerance), as well as a repro measurement of the original move times - again similar numbers to what I originally reported using a feed rate of 762mm/min.

I had previously observed that the reported feed rate in the “Status Reports” section of the Makerverse GUI matches expectation:

ReportedFeedRateDuringMove1

so I decided to try to see if this number was being pulled directly from the g-code (i.e. the set feed rate) or if it’s a reflection of the measured feed rate. To that end, I removed the “G1” command from the original g-code (the version with no z-plunge) and then checked the Makerverse GUI values during each of the three moves. What I expected / hoped to see is that the moves would be performed at the max. possible feed rates supported:

Move 1: ~1300 - 1400mm/min (actual move time = 27sec)
Move 2: ~1150mm/min (actual move time = 20sec)
Move 3: ~1020 - 1150mm/min (actual move time = 44sec)

While it looks like the moves were indeed performed at or close to the max rates possible, to be honest, I’m struggling to make sense of the numbers.

I’m currently running with version “MaslowDue v20200915” of the firmware.

Thanks again for any guidance you can offer ! Hopefully I’m just making a classic rookie mistake :slight_smile:

2 Likes
6

Or you just discovered something because you tested the machines performance is more likely. I can send and original maslow board if you want to try to run webcontrol or ground control and see if you have the same issues. send me a pm.

7

Haha ! :slight_smile: Will do - thanks !

8

Yeah this is really interesting. @Metalmaslow knows their hardware better than I do so I’ll let them take it from here, but I’m curious to follow along. All I can contribute is that I don’t think you made any classic rookie mistakes, this seems like some unexpected if not particularly problematic behavior.

I actually thought about adding a mode which would cut at the max possible speed in any direction since it is hardware constrained and the max speed is different in different parts of the board and in different directions, but I haven’t gotten to it. Maybe its a feature and not a bug? :grinning:

9

Nice :slight_smile: Thanks for your input in any case and a huge kudos for getting this project “out in the wild” for the rest of us to enjoy !

1 Like
10

I’m going to call this one. It’s been almost a month without any progress on the delivery of the alternative board.