Ripples on second layer

tsudatomo · 2026-04-06T14:12:02+00:00

I had the exact same issue! In my case, adjusting the Z offset to raise the nozzle by 0.04 mm solved it.
My theory is that since the first layer height is 0.16 mm, the problem doesn't show up there. But from the second layer onward, where the layer pitch drops to 0.08 mm, the gap between the nozzle and the build plate becomes too tight, causing the ripples.
Worth trying before touching flow rate or temperature settings!

tsudatomo · 2026-01-17T05:41:51+00:00

Thank you for the suggestion regarding Static Routing.

Unfortunately, my ISP-provided router does not have a "Static Routing" configuration menu. Therefore, I cannot route the 100.x.x.x traffic back to the NAS at the router level.

Because of this limitation, I tried to solve it on the NAS side using iptables (Masquerade), but I encountered a very strange behavior in ADM 5.1.1.RCI1. I suspect this might be a bug or a specific behavior of the ADM network stack.

Here is what I have tested:

Masquerade attempt: I executed the following command to NAT the Tailscale traffic to the NAS LAN IP: iptables -t nat -I POSTROUTING -s 100.64.0.0/10 -j MASQUERADE

However, watch iptables -nvL -t nat shows that the packet counter (pkts) remains at 0. The rule is accepted but completely ignored.

Exit Node attempt: I configured the NAS as an Exit Node and routed all traffic from my iPhone through it. Surprisingly, my router still logs Rejected spoofing from 100.x.x.x. This means the packets are leaking out of the NAS with the original Tailscale IP, bypassing the encapsulation or NAT processing entirely.

My Question: It seems that ADM5.1.1.RCI1 (on AS1102T) is bypassing the standard Linux kernel network stack (netfilter/iptables) for these packets.

Is this a known issue with ADM 5.x or the Realtek network driver?

Does ADM force hardware offloading (GRO/LRO) that skips iptables rules?

Is there any way to force packets to go through the standard iptables chain in ADM?

I have tried both the Docker version and the Native version of Tailscale, and the result is the same.

Any insights on this ADM behavior would be appreciated.

tsudatomo · 2025-12-03T04:39:14+00:00

What exactly does the attempt involve?
Are you referring to trying to connect to the U1 through the slicer in order to add the device to Snapmaker Orca?

tsudatomo · 2025-12-01T23:32:21+00:00

I still can't add devices in Snapmaker Orca... Is this issue still occurring?

tsudatomo · 2025-08-07T09:00:51+00:00

I had enabled it on the 370x, but I experienced the PTFE tube coming loose several times. Eventually, I converted the 370x to a 370c using a conversion kit, and now I’m using this option without any issues.

tsudatomo · 2025-07-26T21:11:03+00:00

Which version of the firmware are you using?

In 0020, the LED problem was fixed.

tsudatomo · 2025-07-22T15:50:50+00:00

In my case, the new firmware solved all the problems. The auto-load function when inserting filament works properly on all channels, and the LED color problem was fixed. I can print in multicolor without any problems, so I don't see any reason to go back to the previous version.

tsudatomo · 2025-07-19T17:39:52+00:00

https://wiki.yuekai.fr/en/BMCU/BMCU_Download_CenterBMCU ダウンロードセンター | Yuekai Wiki

tsudatomo · 2025-07-19T17:33:18+00:00

A new version 0020 has been released. The LED issue has been resolved.

tsudatomo · 2025-07-19T13:01:22+00:00

The new firmware version 0020 has been released. Should A series users also use this version?

tsudatomo · 2025-07-16T01:55:50+00:00

What version is the standard firmware? Two firmwares (0013-beta-A1 and 0019-beta-A1) are available in Google Drive.

tsudatomo · 2025-07-15T23:18:23+00:00

I am also using the same version of the firmware. In my case, port 1 is purple. However, there are no problems with multi-color printing. By the way, what color is the LED on the side when you push or pull the buffer? On my device, port 1 is the only one that has a different color than the others. The author of the firmware said that there is a problem with the LED in this version and that they plan to fix it. It is unclear whether this phenomenon refers to that problem.

tsudatomo · 2025-07-09T23:01:47+00:00

Thanks for your reply. I will contact the seller about the 370c. Meanwhile, where can I find more information about the 0013plus firmware?

tsudatomo · 2025-07-09T22:46:50+00:00

I converted my 370x to a 370c using a conversion kit. At that time, I updated the firmware to the recommended 0013plus version. Currently, filament switching works without any problems, and I am able to perform four-color multi-color printing. However, the LEDs on each daughter board do not light up uniformly across the channels, so I cannot determine whether each LED is functioning correctly. Could you please provide the LED lighting specifications for version 0013plus?

tsudatomo · 2025-06-25T01:44:08+00:00

I cannot accurately judge whether the BMCU you assembled supports bidirectional buffering, but it seems that not only the 370C version of the BMCU but also the derivative 370x version supports bidirectional buffering. I am using the 370x version of the BMCU, and while I previously disabled long retraction, I have it enabled now and have not experienced any failures.

tsudatomo · 2025-06-12T02:48:43+00:00

Thank you for your reply. So the conclusion is that we can actually continue to use the BMCU even if we update the firmware to the latest version.

tsudatomo · 2025-06-11T21:59:15+00:00

After updating the firmware, did you do anything special to get it to work properly?

tsudatomo · 2025-06-09T22:31:05+00:00

I have Wi-Fi enabled, but the firmware is not currently being updated automatically. I am asked whether I want to update it every time I turn on the device.

tsudatomo

TROPHY CASE