It would be nice to support CAN-FD. As far as I can see a much more stable and not so delicate protocol compared to CAN. CAN-FD can run like CAN on most of our current HW.
@marckleinebudde supports that with his branch GitHub - marckleinebudde/candleLight_fw at multichannel.
Klipper already uses candleLight_fw!
Not sure how big Pandora’s box potentially could be.
Besides the flexible data rate and the extended messages it’s pretty much the same protocol. What do you mean by delicate in this context?
I would say it would be smart to start moving towards CAN-FD compatibility, especially since it’s backwards compatible with CAN 2.0 out of the box anyways. Just do it in a way where the bus defaults to the lowest speed interface connected to it.
In other words, if you have 3 CAN-FD devices and 1 CAN 2.0, it runs with the CAN 2.0 protocol.
That way people can upgrade piecemeal.
That’s on my never ending list of projects to mess with, might be revisited soon cause I wanted to make a CANBus toolhead that fits a NEMA 14 stepper anyways. Thought about designing it with a CAN-FD transceiver for that very purpose.
Nah! Kevin O’Connor already stated, licensing or patent issues with using CAN-FD on Klipper wouldn’t be a problem Add support for MCP2518FD for RP2040 based toolboards - Looking for a Dev - #16 by koconnor
He just doesn’t see any particular gain in utilizing CAN-FD on Klipper.
I do! …and RepRap Firmware uses it! Those guys might have a reason.
CAN-FD is much more robust compared to classical CAN 2.0. That is the main benefit. 3D printers produce a lot of noise Noise (electronics) - Wikipedia. When you remember all the unexplained problems with current CAN used now with Klipper, CAN-FD might be the solution! E.g the latest Timer too close random - #2 by Sineos
Klipper already uses candleLight_fw and STM MCUs support FDCAN. Of course it needs to be implemented and I’m not good enough 
No, that’s why it is not compatible to CAN 2.0. By “delicate”, I’m thinking of the robustness of CAN 2.0 compared to CAN-FD.
Be smart and don’t do that. Enjoy the robustness of CAN-FD.
It’s definetly a lot of work! Programming Klipper source code, getting that working on our HW, and debugging on our user’s end! I think it should be a development goal for 2024!
Again though, CAN-FD just adds a more robust CRC check and an error bit. The physical bus setup (with the differential signaling and all that) is the same as CAN 2.0. The differential signaling is where most of the noise rejection comes from.
Don’t get me wrong, I’m not against CAN-FD and I think it’s the natural path for expansion. Especially as more and more people use more complex sensors and different “peripherals” the enhanced data rate of CAN-FD will be needed.
Most of the issues people bring up about CAN issues that I’ve seen fall into 2 scenarios:
2.) Bad wiring - I’m guilty of this until I got a better crimping tool. Poor crimps, loose connections etc. cause a flaky connection and data errors.
CAN-FD won’t help either of those.
Per ISO 11898-1 CAN-FD is backwards compatible with CAN 2.0, It has a bit field to indicate when it’s using CAN 2.0 data frames instead of the larger CAN-FD frames. All CAN-FD transceivers I’ve ever seen are backwards compatible, I’m not sure if they even sell ones that aren’t as it wouldn’t be ISO compliant to the protocol.
Again - To be clear - CAN-FD IS more robust in the sense it has a better CRC check and supports bigger data frames at a faster rate. But the PHYSICAL setup is the same.
And as always, I could be missing something and I’m 100% not adverse to being shown I’m incorrect. That and we might be saying the same thing in a different way.
You should carefully read: “… when using an external chip such as the MCP2518”.
This surely is true because the MCP2518 manufacturer has licensed its usage.
In my view it would likely not be true for things like GitHub - KevinOConnor/can2040: Software CAN bus implementation for rp2040 micro-controllers and I do not know how it would work for all the rest that might be somewhere in the middle. Once again, I’m not the expert in licensing stuff, nor do I intend to become one.
Yes, The license is require when making the integrated circuit, not the implementation of the software protocol.
"The right to use the CAN Protocol, CAN FD Protocol
intellectual property rights for the design, manufacture
and sale of integrated circuits or the programming of
FPGAs "
I always try to read carefully, sometimes with little success though 
I’ll take STMicroelectronics for example, because candleLight_fw supports just MCUs from that manufacturer.
ST (and all other MCU or ASIC (e.g MCP2518) manufacturers, which use CAN IP modules) MCUs from the STM32G0 series, STM32G4 series, STM32H5 series, and STM32H7 series are supported by Klipper. I guess ST is using the M_CAN IP module (https://www.bosch-semiconductors.com/ip-modules/can-ip-modules or the link @TheFuzzyGiggler just posted) and pays of course the royalty fee. This royalty fee is priced into each IC which uses this IP module. We, the end consumers pay the royalty fee in the end and we don’t use the FDCAN peripherals in our STM32s with Klipper.
That’s why open source projects like RepRap Firmware and candleLight_fw are using FDCAN peripherals, since licensing is no problem.
Licensing is no argument against CAN-FD, but it’s certainly a bunch of work!
Thanks for your reply. I almost agree with everything you wrote. I’ll try to explain the parts, where my opinion differs.
I agree, the PHY is the same. Inside the IP module they made some changes https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/papers/icc14_2013_paper_mutter_1.pdf.
This is critical in MCU designs. MCUs have usually a cheap crystal for the clock reference, this is another argument for using CAN-FD.
I don’t think the enhanced data rate of CAN-FD is a game changer for Klipper, but Klipper will have more headroom.
I agree, but we can and should avoid that. If you mix CAN 2.0 and CAN-FD nodes on a CAN bus, you’ll run with the CAN 2.0 protocol.
Of course, usually running an IC with a slower clock rate is no problem. With candlelight_fW the maximum data rate is usually 5Mbit/s and not 8Mbit/s.
The paper from above https://www.st.com/resource/en/application_note/dm00625700-fdcan-peripheral-on-stm32-devices-stmicroelectronics.pdf summarizes the benefits of FDCAN in a short nice way.
FYI, I moved this discussion to a new topic.
-Kevin
For what it is worth, the only benefit I see to CAN-FD is a slightly higher bandwidth. Today, the maximum 1Mbit bandwidth of canbus could be thought of as roughly the same as a 500000 baud serial connection. That’s sufficient for typical toolhead boards.
I’d guess CAN-FD could potentially triple that amount (the CAN-FD protocol is complex, so a 5 or 8 fold increase in raw bit rate wont correlate with a direct increase in available data rates).
So again, the only benefit I see to Klipper is more bandwidth. Klipper already has its own application level CRC, already avoids the CAN packet limits, already does its own prioritization, etc. Changing the low-level limits just translates to more bandwidth available.
The code changes to support CAN-FD would be complex. So, for what it is worth, it does not seem like a good trade-off to me. We’d always need to support the older CAN 2.0 protocol (due to the much wider available hardware that supports just CAN 2.0) and those needing more bandwidth will likely need to utilize USB (which supports hundreds of times more bandwidth than CANbus).
That said, if someone wants to implement it, I think that is fine. It’s just not a priority for things, I personally, plan to work on.
Cheers,
-Kevin
I would like to see CAN-FD supported by Klipper because of the robustness. As said above, higher bandwidth is no game changer.
I’m no programmer at all and was afraid of that answer.
Wouldn’t the backwards compatibility of CAN-FD help with that issue?
Thanks for your reply and I appreciate moving this discussion to a new topic,
hcet14
I whole heartedly agree based on the way things stand. I think any legit discussion on a NEED for the increased bandwidth of CAN-FD is several years out at least. Even then that’s only if someone comes up with a new novel idea that everyone wants to implement in their printers and it has a large bandwidth requirement.
Like the old adage goes, “If it ain’t broke, don’t fix it.”
@Sineos - Bosch is only talking about the hardware level description. Basically they’re saying you can’t go off and make a chip that implements the CAN protocol by designing the hardware yourself (not using Bosch modules) and expect to skirt the license. ANY hardware implementation of CAN is subject to the license.
For their IP cores they just mean this…
There is nearly zero chance they could feasibly enforce a SOFTWARE license on CAN implementation. There are a LOT less chip manufacturers though.
I’m sure what they’re really worried about is FPGAs though, as that’s “easier” for any designer to use without having to create an ASIC.
All CAN needs to be replaced with USB. The next gen of toolhead boards are going to solve this issue for us.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.