Marlin update for Atomstack Cambrian Max

Hello,

I am facing a problem with the printer mentioned in the title. It has a board labeled Atomstack fb5 v2.0. It is nearly a 1:1 clone of the Robin E3D, but it lacks the separate CH340 USB module.

Here are the settings I have tried:

default_envs = mks_robin_e3 for the STM32F103RCT6 chip.

I have attempted the following motherboard definitions:

#define MOTHERBOARD BOARD_MKS_ROBIN_E3D_V1_1

#define MOTHERBOARD BOARD_MKS_ROBIN_E3D

#define MOTHERBOARD BOARD_MKS_ROBIN_E3_V1_1

#define MOTHERBOARD BOARD_MKS_ROBIN_E3

Communication ports: #define SERIAL_PORT -1

I tried the Marlin version matching the original firmware (2.0.6.1) as well as the latest version, but unfortunately without success.

With any custom flash (anything other than the original), neither the display nor the USB works. After flashing the original firmware back, everything returns to normal.

I saw that one user attempted this update and achieved at least partial success, but unfortunately, I cannot get in touch with them: "https://www.facebook.com/groups/marlinfirmware/posts/4236668943102739/" https://www.facebook.com/groups/marlinfirmware/posts/4236668943102739/

Could you please help me get this up and running?

Just because it looks similar does not mean they are 1.1 clones. for eg the usb, you saying it does not use a Ch340, which means instead of using two serial pins is is using USB CDC which uses different pins


Enabling USB CDC also requires changes to the build environment to tell the compiler to include a USB stack.


From FB post"
"I had an Atomstack Cambrian Pro, that was great for a couple of days and then basically parts failed (fans, screen and then the motherboard shorted).
I have the below motherboard (not burned out version), it looks very similar to the mks Robin e3d, and runs Robin e3 firmware. But, the connectors for the screen are all different, this has a 6 pin serial connector, and I have returned the control screen to the manufacturer."


Step 1

You have to map out where all the pins are connected. "Sounds like most of the pins are the same as the SKR Robin E3. " so that is a starting point.
Note many of these boards are self documenting with pins names on the bottom of the board. So take a high resolution picture of the bottom of the board

To get you stared here are the usb pins.

PA11 USB DM
PA12 USB DP


Here is the full sized image


Edited 3 time(s). Last edit at 12/19/2025 08:32PM by Dust.

Oh look what I just found

[github.com]

Says its for the pro, but has the same motherboard

Pins file [github.com]

Build env

#
# AtomStack FB5 V2.0 (STM32F103RCT6 ARM Cortex-M3)
#
[env: STM32F103RC_atomstack_USB]
extends                     = common_STM32F103RC_variant
; board                       = genericSTM32F103RC
; board_build.variant         = MARLIN_F103Rx
board_build.encrypt_mks     = Robin_e3.bin
board_build.offset          = 0x5000
board_upload.offset_address = 0x08005000
build_flags                 = ${common_STM32F103RC_variant.build_flags}
                              ; -DMCU_STM32F103RC -DHAL_SD_MODULE_ENABLED
                              ; -DSS_TIMER=4 
                              -DTIMER_SERVO=TIM5
                              -DUSE_USB_FS 
                              -DUSBD_IRQ_PRIO=5
                              -DUSBD_IRQ_SUBPRIO=6 
                              -DUSBD_USE_CDC_MSC
monitor_speed               = 250000
; upload_protocol             = stlink

Edited 1 time(s). Last edit at 12/19/2025 08:59PM by Dust.

I've created a pull request to add this motherboard into main Marlin [github.com]

You can see all changed files here [github.com]

Edited 1 time(s). Last edit at 12/20/2025 02:11AM by Dust.

Thanks a lot for the help . This seems to be exactly what I needed. I had almost given up hope. I searched online, but clearly I missed it.

After the flash, PC control via USB is working, but the original screen is acting up. It seems unable to handshake with the controller. I heard it sends commands similar to PC-over-USB; something seems to be interfering with that path even with no PC plugged in, but that's a minor issue.

Photo attached.

All I know of the screen is it is a serial device (as that is the connector it plugs into)

Screens like this come in two main types

1) Screens that talk gcode and interpret the results. Basically they are a small computers with touch screens. Marlin only needs the serial port its connected to enabled.
2) DWIN/DGUS,TJC etc these talk a custom protocol, The user interface and Marlin code are tightly coupled. Marlin has to have the UI code added to support this display.


I have never seen a commercial 3d printer use the first type of screen, they are on diy or upgraded machines

If this display is the second type you really need the original source to add it into stock Marlin. These screens are generally closed source,

The pro source I found enables #define DGUS_LCD_UI E3S1PRO
But I very much doubt that is correct as that is a creality screen

Edited 5 time(s). Last edit at 12/20/2025 06:37AM by Dust.

It looks like the author of 'https://github.com/samiulbasher/Atomstack_Cambrian-PRO' also added a screen update there using the 'DGUS_LCD_UI E3S1PRO' configuration. There is a DWIN_SET folder, which the Atomstack screen should flash automatically after inserting the SD card into the display. Unfortunately, I don't have the original firmware for this screen, so if something goes wrong, the screen will be bricked.

Yes, instead of trying to support the existing user interface they seem to have just used the creality one (after removing the creality boot screen)

Edited 1 time(s). Last edit at 12/20/2025 09:02AM by Dust.

OK, just like I wrote earlier, flashing the DWIN_SET to the LCD was all it took. It looks like the person from 'https://github.com/samiulbasher/Atomstack_Cambrian-PRO' did a great job giving these printers a new life. And equally big thanks to you, 'Dust' – without your pointer, I would have given up on this already. I'm attaching photos of what it looks like now.


Edit: Naturally, the first print failed. It turns out microstepping was configured to 32 instead of 16. I've adjusted the values as follows:

#define DEFAULT_AXIS_STEPS_PER_UNIT { 320, 320, 6400, 422 } //32 microsteps

Edited 2 time(s). Last edit at 12/20/2025 12:30PM by _RAZOR_.

There is one more small issue. It concerns the pause function and its current "advanced" form. Is it possible to switch to a simple version (but while retaining the parking function) without all these extra messages and choices?

Specifically, the pause sequence behaves as follows:

1. A parking message appears (it pops up regardless of the screen I have assigned in DGUSReturnKeyCodeHandler.cpp).

2. A "nozzle parked" message appears. [Strangely, all of this is displayed on the file selection screen. I can click "confirm," and to the right of the button, there are invisible retraction and de-retraction buttons.]

3. A "resume options" message appears where I can click "confirm".

4. The file list is displayed. There seems to be an issue with the touch points here; I can only select the 5th file from the top. The remaining touch points do not react. The file selection screen definition is correct, so that is not the problem.

5. Only selecting the 5th file redirects to the main menu where I can resume (5th file).

What I have tried so far: I modified DGUSReturnKeyCodeHandler.cpp regarding screen changes or function calls. However, whenever the nozzle is parked, these windows and messages pop up, and it is impossible to exit them or resume.

The only way to resume is to power cycle the printer. After the restart, the resume button triggers command 105F 0001 to the main menu, where the "resume" option becomes available.

Photos and files are attached.