[Bug]: Operation stops / Systematic USB errors

[zufus]

Summary Description

When executing cut operations I get a deterministic "USB Error" which causes the board to disconnect and stops the job. I tried to change cable and PC. Disconnection always occurs at the same point during the JOB. So I exclude cable issues. The same drawing seems to run smoothly when using k40whisperer. However, I would prefer using meerk40t.

Another issue I found is that when I launch the job the laser head stars moving/cutting: the main screen background becomes green and I see a cursor moving along the drawing path: however, the cursor on the screen runs much faster than the laser head.

Depending on the drawings, the job is completed, but it seems that on the PC it is executed much faster: result is that meerk40t sees the job as ended, while the job is still running. In this case, the Abort button is not functional anymore..

it seems to me that meerk40t sends commands at a rate which is faster then the rate that can be handled by the machine.

My laser machine has a M2 nano board. I don't see useful error messages on the USB log trace.

can you please guide me to create a meaningful bug-report?

The same behavior occurs either with 0.8 and the latest 0.9.0009 git version.

I am using it on a Debian GNU/Linux machine. Other details:

Python 3.11.4
wxPython gtk3 wxWidgets 3.2.2

Thanks!

Marco

Additional Details

No response

Crash logs

No response

MeerK40t Version

0.9.0009

MeerK40t Type

Git

Your Operating System

Linux

[tatarize]

When executing cut operations I get a deterministic "USB Error" which causes the board to disconnect and stops the job. I tried to change cable and PC. Disconnection always occurs at the same point during the JOB. So I exclude cable issues. The same drawing seems to run smoothly when using k40whisperer. However, I would prefer using meerk40t.

1. This is extremely unusual. If the file that does it is consistent can I get a copy? Either here or tatarize at my gmail account. There is nothing as part of cut operations that should cause a USB error.

Another issue I found is that when I launch the job the laser head stars moving/cutting: the main screen background becomes green and I see a cursor moving along the drawing path: however, the cursor on the screen runs much faster than the laser head.

2. It's generally the write position rather than the actual location of the physical device. There's a bit of a buffer between the time it starts writing and the time position of the laser-head.

result is that meerk40t sees the job as ended, while the job is still running. In this case, the Abort button is not functional anymore..

3. This is an error. I would have figured this was corrected, but I guess I might need better testing for it. While the job finishes the buffer there of yet to write or even already written data may complete and the program may believe no job is running and fail to send the abort sequence anyway. I'm pretty sure I had it fixed. And it should send I* anyway now to reset the device.

it seems to me that meerk40t sends commands at a rate which is faster then the rate that can be handled by the machine.

4. MeerK40t can only send things to the card at the rate the machine handles them. There's actually basically no physical buffer on the machine. If it's sending at a rate, that's the rate the card is allowing. This doesn't ever overflow the card, it signals the program that it's busy and refuses to accept the packet. The other extreme is that sometimes the program doesn't send commands fast enough, (or isn't allowed to send them fast enough) and the buffer underflows causing a stuttering effect.

can you please guide me to create a meaningful bug-report?

This appears to be quite meaningful, other than directly on Discord (see, meerk40t help) where we may sometimes be more active, this is pretty reasonable.

---

1. Copy of file that disconnects during run. If this can be duplicated, it can be easily fixed.
2. Not an issue, sort of by designed. (Should be red screen rather than green, but the color can be directly set sometimes).
3. That used to be an issue, and I thought it was fixed, and will certainly check again.
4. Not an issue, it can underflow but doesn't overflow.

[zufus]

Hi, thanks for the reply. I am not sure about the lack of buffering on the machine, I will think on it.

Please find attached a file where I get this error. What i can say is that this kind of error occurs on files having "long" cutting patterns. If I send a small rectangle, for example, it works flawlessly. As I increase the number of rectangles n the drawing I start see "USB disconnected". Meanwhile, I ran it also on Windows. I used the "pip" version of Meerk40t. Same exact behavior.

1001.dxf.zip

[tatarize]

Found and fixed 3. I can't get 1 to disconnect during a run. We're trying some more things but we can't duplicate that happening as of yet.

We could probably also fix 2. It doesn't happen that often but we are usually waiting until finished in that case and could certainly send the right signals for those.

[Sophist-UK]

This is amazing support from @tatarize - issue noted, discussions made, and a bug fixed all in less than 12 hours.

[tatarize]

It helps that the dxf made it pretty easy to test. Still holding off on 1, since I can't get the described behavior to happen.

[Sophist-UK]

I would be happy to try this on my K40 to see if I can reproduce it. Also, it might be helpful if @zufus were to:

a. Load the DXF file and save it as an SVG and share this here.
b. Define the exact version of MK they had this problem on, which O/S they are using and which drivers (CHxxx or LibUSB)
c. Export or list their MK settings so that e.g. we can ensure that we have the exact same settings when we try to recreate the issue.

[tatarize]

• Linux OS, LibUSB for linux. 25 mm/s cut speed. No optimization.

I tried this with CHXXX and LibUSB for windows 7. No replication.

The current belief is that maybe the wait for finish hammering is too fast or something and causes it to disconnect. This would probably be Linux only if that was the reason.

[Sophist-UK]

@zufus Apologies for missing that you had supplied some of this detail.

@tatarize If you cannot replicate it with a slightly different setup, then you probably need to try it with an identical setup - hence my request for all the info that you would need to have it as identical as you can.

Now that I see he is trying it with the 0.9 beta, I think it might help if he tried it with the 0.8.9 full release to see if it is common or not.

[tatarize]

I asked some on discord. I think he used some others. Dunno though.

I also fixed 2 which is pretty minor but might as well. Just changed from the driver;mode signal to the pipe;running signal. So it'll stay red-background until it finishes up. Also, should work with grbl here and there.

I'll hold off on merging #2059 until we get some more tests for the other part of the report.

[zufus]

@zufus Apologies for missing that you had supplied some of this detail.

@tatarize If you cannot replicate it with a slightly different setup, then you probably need to try it with an identical setup - hence my request for all the info that you would need to have it as identical as you can.

Now that I see he is trying it with the 0.9 beta, I think it might help if he tried it with the 0.8.9 full release to see if it is common or not.

I tried also the stable release, on Windows, installed by using pip. Same behavior.

[zufus]

I would be happy to try this on my K40 to see if I can reproduce it. Also, it might be helpful if @zufus were to:

a. Load the DXF file and save it as an SVG and share this here. b. Define the exact version of MK they had this problem on, which O/S they are using and which drivers (CHxxx or LibUSB) c. Export or list their MK settings so that e.g. we can ensure that we have the exact same settings when we try to recreate the issue.

Will send the configuration settings later tonight,

[zufus]

Hi, those are the

usb send/recv files, as logged by using "channel save m2nano/usb_send" and "channel save m2nano/recv".

M
MeerK40t-channel-m2nano_usb_send.txt
MeerK40t-channel-m2nano_recv.txt

[tatarize]

Looked like you ran it for a bit and hit abort. I can't really see anything else in there. It might need both in the same file so I can see send and response.

[tatarize]

Reopened for the unknown last remaining issue of disconnect while running. Other issues are corrected.