Hey everyone I think that this is because of a change we made on Friday afternoon. I’m going to look into it this morning, hopefully have a fix within a couple of hours.
Sorry about the inconvenience / confusion.
Will update with findings.
2 Likes
@Rusty it looks like your analysis is right, the gcode used to start (pseudocodely)
G1 Z<safety>
G0 X<first_cut_x> Y<first_cut_y>
G1 Z<first_depth> F<plunge_feed>
...
But a change on friday made it instead write
G1 Z<safety>
G1 X<first_cut_x> Y<first_cut_y> F<cut_feed>
G1 Z<first_depth> F<plunge_feed>
...
Which causes the initial movement to be at the cut feed rate instead of the default feed rate.
This was totally my fault. @rodovich had actually caught this in a code review, but neither of us realized the implications because the default G0 speed in Grbl is actually lower than most of the cut feeds in Easel. I didn’t realize that most people were adjusting those rates. To complete my embarrassment, here is proof you should never second guess @rodovich’s code reviews
UPDATE: I deployed a fix for this now. I’ve confirmed that the gcode goes back to the way it was before. Can someone confirm on their machine?
4 Likes
First traverse is full speed now, thank you.
Yeah, it’s fixed, as are the x-axis slipping issues I was having. i guess this is the downside to a cloudbased app that’s still in development.
@JohnBaum or maybe it’s the upside that bugs get discovered quickly and the fix is instantly rolled out to all users without requiring users to download updates or reinstall.
Next year we plan to build up our internal testing capability even further. We started the process at the end of this year but we have more work to do.
1 Like
Except when you discover the bug by ruining material.
1 Like
I’m sorry. I’ll message you direct.
While it’s great that the team is so responsive and professional with getting fixes done when we find bugs, I’d like to point out that most of the bugs we’ve found have been the result of the team changing things that worked reasonably well before.
I wonder if it’s possible to ‘sandbox’ Easel so that we can have a frozen version that works predictably for us, and then we can update it as we see fit to. Perhaps that can be an opt-in or opt-out kind of thing so that most users have the current build, but if stability and predictability are important, a user could opt to freeze their version. This way, for the people who are trying to run a business or even just make Christmas gifts, a sudden change or bug doesn’t knock them out of commission.
1 Like
@Mike it’s a good idea. Some sort of staging environment where the new build gets pushed to for people that want to be on the bleeding edge.
I’ll talk to the dev team to see what options we have.
1 Like
Thanks! Great work as always guys!
I really do like how quickly the response is to our inquiries and concerns. Then to top that off they jump on bugs like Raid on a roach.
1 Like