I’m working on reverse-engineering the Creality AMS spool-holder thing to use it on a different printer, and have had some success (I’ve got klipper running on the embedded MCU and have a pretty complete pin-map).
However, one of the major stumbling blocks I see to using these things with klipper directly is that both the creality and bambu AMS systems use a RS-485 bus for communicating with the main printer host. Realistically, this is fine, since they don’t need to move fast and there is little that’s extremely time-sensitive on them.
So, that all stated, is there any possibility of additions that allow use of a half-duplex (e.g. RS485) communication interface between the klipper host system and the multi-material peripherals? If I can do that, it would mean that it should be possible to swap the creality CFS over to klipper with zero hardware changes, making it a reasonably compelling alternative to things like the BoxTurtle project in terms of cost, though with somewhat lower swag points.
Although unrelated to this topic, I had wished for an integrated and generic Modbus / RS485 solution as well.
For example, there are hardware PID controllers that allow communication via Modbus for:
Managing settings
Getting temperature values and status information
Integrating one into a Klipper setup would have been a convenient solution.
I’m interested in RS-485 as a possible transport for the main Klippy-host → MCU transport. The protocol would be exactly the same as it currently is, just with some flag somewhere to allow it to operate in half-duplex mode with looser timing constraints.
Interfacing with arbitrary other RS-485 peripherals is a very different use-case, and would need a LOT more software configurability to allow all the different ways devices implement what is effectively a serial interface.
@Sineos I agree. The Magneto X uses a separate chip to talk to the linear motion controllers. It would be nice to not have to go through that extra step.
@fake-name The way you described things, I’d assumed you were going to use the AMS systems as is, instead of flashing them.
Half-duplex RS-485 is the physical layer for CAN. If you’re just talking host to an MCU, you’re set. The only option you may need is a baud rate control.
That was originally my plan, but Creality are being jerks and violating the GPL by not releasing the source for their klipper extensions that talk to it (and static analysis of the firmware was a lot), so I instead pulled it completely apart and flashed klipper onto it as well.
The RS-485 interface that is present is not connected to the CAN interface, so I can’t just switch it to talk CAN without board modification. On the other hand, there is what I’m pretty sure is a debugging connector that does expose the pins for USB and/or CAN, so I’m using that at the moment.
Generally, it is quite unlikely that Klipper main-line will ever support manufacturer-specific interfaces, as this will create a huge maintenance burden in the future. Therefore, any such extensions should live in a dedicated fork.
It is quite sad to see that current developments (including some in the open-source scene) are heading in the wrong direction (at least in my opinion):
Instead of collaborating with the official Klipper project, everyone is doing their own thing:
Multiple approaches to support load cells
Countless approaches to support multi-material systems
And so on
This fragmentation will lead to:
Incompatible and non-interchangeable hardware
Incompatibility with Klipper main-line updates
Breaking systems and strange errors because relevant Klipper system requirements have not been observed, and only the feature itself has been focused on (and in the end, the issue is attributed to Klipper)
Proprietary and even closed-source interfaces
In the years to come, users will be left with outdated systems as project owners or OEMs declare their systems as no longer maintained or obsolete
Instead, the community and OEMs should seek to:
Define open interfaces
Create hardware that supports these interfaces
Contribute to Klipper main-line for popular hardware
I don’t disagree. I’ve actually been going back and forth with creality about the fact that they’re in violation of the GPL, and asking them to give me the source code the are required to do. So far, their support is completely useless.
However, this question was basically:
Is there a way to use klipper between a host and a klipper MCU over a slow (e.g. RS485) link.
I even described in the original question that I’ve already reflashed the MCU in the AMS box with klipper. The main issue at this point is that I’d like to reuse the existing 485 link the AMS system exposes, and it has a lot of filtering/capacitance that prevents high speed serial traffic from running over it.
To my understanding: Not without code changes to the currently implemented protocols or interfaces. This brings us back to the points mentioned in my previous post.
It’s technically possible, but it would require some coding work. The main issue I can think of is that the Klipper mcu is expecting to be able to transmit messages to the host at any time (and the host is also expecting it can send messages to the mcu at any time). So, some form of “line arbitration” is needed to handle cases where more than one chip wants to send data at the same time. The usb and canbus protocols handle this at the hardware level, but as far as I know, there is no standard for this on 3 wire rs485 links.
If you can solve the line arbitration issue, then it should be possible to emulate traditional rx/tx serial over the rs485. If you look at Klipper’s usb and canbus code, both basically emulate a serial port. Indeed, the original Klipper canbus code used an external unix daemon to map the canbus interface to a unix pseudo-tty serial port, so that the Klipper host code could be used unmodified.
I know @koconnor knows this, but it isn’t clear in his post: RS-485 is an Electrical Only Standard it is not a complete standard with communications protocols like USB. It’s meant for (relatively) long distance serial communications and low datarates.
I’m really surprised it’s come up in 3D printing at all - I thought that it’s only current use was in model trains. I haven’t seen it use anywhere else since the 1990s although in doing a search it seems to be primarily used in building HVAC systems.
If you are going to use RS-485, you will have to come up with your own communications protocol. Note that it is NOT full duplex unless you set up a dual pair connection.
Looking at the GitHub page you set up, I’d recommend starting with a basic NRZ Serial connection between the AMS STM32F106VET6 and your host. By doing this, you won’t have to buy an RS-485 hat and implementing the Klipper interface code should be simpler with example code you can start with.
It’s also super broadly used in industrial contexts, not that that’s what’s under discussion here.
In any event, I wound up figuring out a way to adapt the thing to speak can proper.
Looking at the GitHub page you set up, I’d recommend starting with a basic NRZ Serial connection between the AMS STM32F106VET6 and your host. By doing this, you won’t have to buy an RS-485 hat and implementing the Klipper interface code should be simpler with example code you can start with.
The whole point was I was hoping I could come up with a clever way to not have to even open the box. Creality has some mechanism for remote update, and if I could get that to play nicely one could potentially flash the CFS without having to open it, and then reuse the existing everything.
As it is, I designed a interposer board that sits between the main controller PCB and the rear connector that swaps the RS485 lines for CAN, and it connects to an unused header on the board. I also have a respin of a candleLight compatible design that handles the other end of the bus.
Playing devils advocate here, but at some level that becomes unrealistic. For instance, every chip has its own I2C or SPI commands. Heck, even Klipper uses a custom MCU protocol instead of something like CANOpen.
I agree that everything would be much better if it was open source. Even getting a Modbus datasheet for VFDs is hit and miss.