K40 whisper timeout bummer

My wife purchased a wooded craft book from Michael’s for me to engrave for a friend of hers birthday. We came up with two designs for each side of the book. The front cover burned fantastically. We were both totally happy with it. The back cover was looking fantastic too but at 65% completion the laser just stopped and a red timeout error came across the bottom of the screen. It would never recover and it ruined the book. What a bummer. I couldn’t figure out what happened. The computer was still working fine, the water temps were fine, nothing seemed out of the ordinary.

What causes this?

Something caused the controller board in the laser engraver to stop responding. K40 Whisperer tries to get a response from the controller board but sometimes it just won’t respond without a reset. A lot of people say yhat replacing the USB cable fixes the problem for them.

2 Likes

I agree with @Scorch. Replacing the cheap stock USB cable for a better quality one is often an underrated upgrade.

1 Like

Okay I’ll try that thanks.

In the meantime, might be time to start researching alternative controller boards and software. If it happens on cardboard that’s one thing. But happening on more expensive objects is a bit aggravating.

Damn. Bit me again 40% into another project. Even after replacing the stock USB cable with one I borrowed from my HP printer.

Hmmm, timeout problems have also been traced to some electrical interference issues. See this post for some links to some discussions on reddit.

1 Like

I also had at least one person say that improving the ground connection for the controller board fixed the problem. I would think that making sure the controller board ground (ground plane or ground wires) has low resistance to the ground wire on the plug that goes to the wall would be sufficient.

1 Like

There’s also a chance that some of it is due to missing a critical packet. The protocol in K40 Whisperer is somewhat bugged. It sends a packet, then sends “hello”, then reads status and deals with the status. But, there’s some chance that between packet send and “hello” that the state has changed. For example, if it’s busy, the packet is ignored. Then Whisperer sends “hello”, and read the state, but the state is now OK. – It will wrongly assume the initial packet sent correctly.

There are some packet gaps that could actually cause it to fail to respond, if it lost some important commands. For example sending “NSE…NSE” without the S1E command between them will sometimes often lock it up. Also, there’s no wait time on a busy signal it just starts hammering the board with data as fast as it can, that might not be optimal. So it gets hammered with hello packets far faster than it should ever need to be. That might actually be able to Denial of Service the board.

There’s redundancies in both the USB protocol and the subprotocol within the Nano’s protocols, it should actually survive channel noise. When I worked through the Whisperer code for K40Nano, I pegged this as a likely problem. And added a time.sleep(0.1) to avoid it.

Well after continuing to deal with this issue I bit the bullet and ordered a mini grbil and lightburn from Awesome.tech. hopefully it can fix the issues I’ve been dealing with. Now to learn an entirely new software package.

1 Like

I had this error yesterday and it mangled the raster it was working on. It’s absolutely dropping the packets there. While it certainly connected the USB back, it obviously lost several packets, banged into the wall and messed the stuff up during that time. While writing K40Nano and testing a lot of raster engraving, I never had this issue. I had long since fixed packet loss bugs. And I certainly must conclude that the difference I noted above had something to do with it.

I read through the .32 source code and identified a couple places where packetloss could occur. Those have been fixed as of .33 so if anybody sees this error in .33 it might be nice to know. Basically it could eat a packet if it became busy at an inopportune time, now though it always checks before trying to send a packet.

2 Likes