Easel gcode causing super slow feed rate

Hi, I’ve been carving PCB board using gcode generated with Aspire and exported using the easel post-processor. All was well for weeks but yesterday the engraving passes all slowed to what looks like 1mm/sec or less. I even went back to old projects that engraved perfectly and they too have been slowed down.

So I don’t think it’s the gcode-- has there a been a change to the way gcode is executed? I just updated the firmware and the chrome extension (using Windows) yesterday so I’m thinking that’s to blame. Any ideas? Is this a known issue? Should I roll something back?

Call customer service about the problem. I have always set everything in the program. I use Vcarve Desktop. Easel sending gcode to the machine. Nothing should change there. Have you verified your rates that you set in aspire? Also when you finish a carve it asks how does your project look. Check off that there was a problem. That creates a ticket for the inventables team to look at your project

@MikeFischthal Maybe an inches - mm thing? If you think you’re feedrate is in inches/min, but the machine is actually using mm/min.

I’ll try switching that but I don’t see what that would affect previous projects that had been working. I’m talking with support team as well. But I’ll try switching the numbers. Do you know where in the gcode I can manually view and edit that?

Can you post your gcode?

It seems like its pausing at every vector point instead of moving smoothly. The preview shows how slow it moves. This is the project:

I’ve tried re-exporting, changing the values, and editing the gcode F value directly with no success.

Code attached: trace-etch.nc (670.2 KB)

I’m not an Easel user, but it appears that your project has a feed rate of 15 and plunge rate of 12. Maybe these are set when you pick a particular mill/bit and/or material.

Your easel project isn’t shared publicly, so we can’t see it.

Can you post your grbl settings? Send $$ in the machine inspector.

Looking back at other projects some are simulating fine. I’m wondering:

Do you know if it matters that there are LOTS of points on the vector path. Like each straight line has hundreds instead of 2. Would that make it run slower? Is the gcode feed the speed between the points?

(project should be public now: http://easel.inventables.com/projects/LPwpUnkU7K4tnlfF7XjeWg)