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?
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…
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:
Yes…however,
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 https://carbide3d.com/carbidemotion/beta/ and see if you get any timeouts with 564.
