Machine Stopped Responding

I know there are a lot of lost connection posts - and everyone talks about power issues and static issues…however, I’ve been running my SO3 XXL for 2 years without EVER having a disconnect. I upgraded to the beta CM and started to see the “Machine Stopped Responding” messages pop up. I’d say this has happened 5-8 times since the Beta upgrade (and as I said, never before). Is there ANY way this is software related? Not being much of a believer in coincidences, it seems strange that this problem would pop up at the same time I did the upgrade and be so consistent.

I’m guessing I should downgrade to the last production CM release and see if I continue to have problems? Which release was that, and where can I find it?


  • Gary

You should still have the old Carbide Motion install file in your Downloads folder.

I often clean it up…or I have every beta download too…which version was last production?

I have 557 and 551… Was it 557?

You can launch it from the command line with “–notimeout” added to disable that timer code.

If you can find any triggers that make it happen, I’d love to know because “this can never happen in normal use”.

1 Like

Ah…timer code. I should mention that the last time it happened, the cutting continued for a good 30 seconds before it stopped.

I’ll add the suffix and report back.

I don’t know what I can find in terms of triggers, but I can try … it sounds a bit deeper in machining than I’m capable (not being one of the engineers in the group).

But I’d like a dollar for every time something that can never happen in software, happens… :slight_smile:

Thanks Rob.

So, the error popped up during normal operation during a program, not jogging, MDI, etc.?

Correct…it was in the middle of a cut.

I reran the same job (which had timed out twice this afternoon) with the -notimeout and it completed with no issues.

Perhaps it’s my Fusion Tablet (Fusion 5). If you may recall, I had intermittent problems loading the visual representation of some .nc files during the Beta - which went away at times. Specs are below. I know other folks are using that tablet - and I have the pro version with 6gig in it, but maybe the processor is slow.

Here’s what I know:
There’s nothing else running on the tablet at the time except CM and Win 10
The USB is hooked to a powered hub that holds the SO3, a wired mouse, a wired keypad, and the USB stick. Power to the hub is on.
Here’s the machine:

  • Gary

It also came up during zeroing today…I was pressing the pgdn key multiple times to trap paper with the bit…and it showed that message and forced me to re initialize.

That’s interesting because the timeout should only occur if Motion hasn’t gotten a reply from GRBL in quite a while (relative to computer time). I wonder if the CM process is getting put in the background temporarily. Maybe we’ll see about bumping the priority of the CM process on launch.


I had the same thing happen to me this past weekend in the middle of a project, with the latest version for the PI, on a Raspad 3. First time it ever happened, and once I re initialized everything worked as it should.

This is more for internal testing so it might be more “beta” than normal, but check out and see if you get any timeouts with 564.

1 Like

I’m not around this weekend…but will try it out as soon as I can. Thanks!

EDIT: And, BTW: No problems since I started using -notimeout.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.