First of all, I would really prefer Carbide Motion didn’t just totally bail out in the middle of a project. I (erroneously) thought the latest and greatest would have been fleshed out before being posted, but alas, I was wrong. Never have had it totally crash before, but I decided to update to build 667 like a good boy. Totally dumped out in the middle of a 3 hour run. It sent a bug report, but I’ve learned from Carbide Create bugs that those bug splats don’t get any attention from the development team. Have no idea what happened, it just stopped.
But then, re-starting it (to spend 1.5 hours doing nothing), I found that it decided the current X and Y were both 2 mm off from where they were before. So it ruined the piece. Why did it shift coordinates? Nothing caused it to be off, it just decided to be off. In fact, I checked X and Y before restarting and they were right, but on actually carving it was 2 mm off.
If you’re going to have full crash bugs left in production code, at least be consistent with zeros so the project can be restarted.
Please have somebody check my bugsplat and tell me why it crashed.
They all get looked at. Most people choose to put not name, email, or additional context, so we get limited information and we cannot contact them with potential fixes.
There have been two crash reports in Motion this week (one today)- both in video drivers. We’ve been working on the video driver problems in Create, since Motion and Create share a renderer, and Create is much more taxing. That work should be moved into ported into Motion for the next release. As Motion is now, we have far fewer video driver problems than we ever have before.
Check for an updated video driver in the meantime.
The zero is saved when you set them in Motion, so it’s very unlikely a crash changed it. Any offset in running the job again is probably not related to the crash.
I have had to stop a job because of my mistake. I fix the file and reload it in CM and start again. The newest release I have CM 667 has some new quick actions and one is one inch above Z. Anytime you initialize there is a possibility that things can be a few thousands off because of triggering at the home position. For me the previously set X Y and Z have been spot on (SO3XXL). The last set X Y and Z are remembered in the shapeoko.json file. So after a power off and/or initialization those are already set but it is always a good idea to check them with the quick actions or in jog to verify things have not changed. The restart function I have yet to figure out. Plus if you get a disconnect you have to see the line number to restart there. Moving 2MM is about .15" so that is not likely a homing error but possibly mechanical issue.