Error after bed mesh "no samples between time - and -"

General Discussion
1

Basic Information:

Printer Model: Elegoo Orange Storm Giga
MCU / Printerboard: BTT Manta M8p V2.0 / EBB SB2209 CAN / BTT Eddy USB/CAN
Host / SBC: BTT CB1
klippy.zip (4.1 MB)

After updating the MCU firmware, each time I start a print, the printer starts the bed mesh and when it finishes, it gives an error like !! no samples between time 214.1 and 214.1!

I then proceeded to update the toolhead and Eddy as well, but without luck. Still same issue. Online there isn’t anything about this error, so I have to ask in this forum.

The details are as follows:
Due to the size of the printer, the TRSYNC_TIMEOUT parameter in ~/klipper/klippy/mcu.py has to be increased from 0.025 to 0.050 in order for the machine to not go into shutdown at random moments. This has been done and rechecked multiple times, to assure that the issue isn’t coming from that.
I have noticed a increase in tx_retries for eddy in the log file, but I’m unsure what to make of it.
Eddy is connected to the EBB SB0000 extension board, on the dedicated CAN port there.
Due to the large print bed, the heating elements and print plates are 4 separate pieces, and in order for the probe to not pick up the gap between the boards, I have set 3 faulty regions, which are forming a + sign:

faulty_region_1_min: 390.0, 0.0
faulty_region_1_max: 430.0, 390.0
faulty_region_2_min: 0.0, 390.001
faulty_region_2_max: 800.0, 440.0
faulty_region_3_min: 390.0, 440.01
faulty_region_3_max: 430.0, 800.0

When probing, the head starts on the front left, moves towards the front middle, shortly before the middle it moves towards the back, stops almost at the middle, goes right a bit until it is on the second plate, moves towards the front again until it is almost at the front, then goes on scanning right. As my description will not be extremely helpful, here a drawing of what it does.

Head movement while scanning
Head movement while scanning649×718 2.12 KB

This takes some time, and in this time, there won’t be any samples for a short while (maybe about 1.5 seconds), which might lead to this error.

Does anyone have any idea what the issue is and why it appeared after updating the firmware? Have some parameters for timeout changed? Is there any timeout I can tweak?

2

First:

Elegoo support or Elegoo comunity forums should be your first resource for your printer.

Does not seem to be a Klipper error. Elegoo or maybe eddy_ng?

3

Not sure I quite follow.

TRSYNC can only affect the homing timeout, that is it, and only that.
CAN tx_retries are RP2040 specific; they are fine, it is arbitration.

Just in case, messages from the MCU to the host, can be missing, it is okay.
Normally, it only happen if bus is overloaded.

Otherwise, I’m not sure we can support you with EddyNG,
But you can upgrade the Klipper and switch to vanilla implementation, which I believe is better overall.

If you experience any runtime issues, I would suggest:

  • Remove led_effects, they are heavy and traffic hungry.
  • Use an adaptive mesh, because large meshes with a large point count can be heavy too for your CB1.

Normally, I would say, less custom code is better.

Hope that helps,
-Timofey

Small note, that probably, you want one of your MCUs to be the CAN BRIDGE.
To decrease the overall load on the physical CAN bus layer.

2 Likes
4

Thanks for the reply. I was sure that was one of the answers I’ll get, so I updated Klipper from the repository and only re-installed eddy-ng, which for some reason didn’t get of the dirty flag.

The printer is highly modified, thus not running anything from the original soft- or firmware, which makes contacting Elegoo useless.

@nefelim4ag thanks for your replay as well.
I suppose it isn’t a Klipper error, but probably a Eddy-NG error, if I read that correctly?

5

Weirdly enough, it seems to be fixed by increasing the scanning height (from 1mm to 1.5mm). Recommended is 2mm, but I got a better scanning result with 1mm.
Testing further and closing the thread if resolved.

6

I noticed bytes_invalid increasing over time bytes_invalid=95 -> bytes_invalid=133.
Hopefully, it should be fixed in the current master: stm32: usbotg block next bulk_in if buffer not empty by nefelim4ag · Pull Request #7238 · Klipper3d/klipper · GitHub
v0.13.0-593-g2f05309d5

-Timofey

7

I have been testing for the past few days and after increasing the scanning height to 1.5 mm, the error never appeared again.
I have also noticed that the housing of my Eddy has taken some damage. Probably from a previous disastrous failed print. I doubt that has anything to do with the error appearing after updating to the latest Klipper version, but I toughe I mention it anyway.

@nefelim4ag thanks a lot for making me aware of that. I will not update at this stage as the printer is running fine, but I will keep it in mind should I ever need to post something again.

1 Like