In general to the rs232 / can bus thingy.
Beware. My knowledge on embedded / electronics is very limited and I will often guessing and use the wrong terms
I was unsure which one I should choose. I often read that āCANā is not āfastā enough especcially if an accel is read out and the steppers are also controlled over the CAN connection.
I know CAN can also transmit video so for sure not every CAN connection is meant.
I think they mean the 1Mbit CAN connection that is normally used in 3d printing.
I wonder also that a 250kbit rs232 or usb TTL connection should be faster than a 1Mbit CAN connection like mellow wrote but they explain it with a concurrent bi directional connection while CAN is concurrent uni directional. And the smaller package overhead (not existing overhead in rs232???). Sometimes marketing is working
I googled a bit but found no information about speed of ttl vs CAN. But some are using accels connected via SPI to their print board and this information is also send via usb TTL 250kbit to the raspi and works so the 250Kbit TTL should be not a problem.
In my case only the accel would be connected over CAN and the stepper over usb so both should work without problems in my case.
So I bought UTOR and UTOC and started with UTOR. But have no problem switching to CAN if a test is needed.
And only to make the confusion about CAN and rs232 ttl complete.
I appreciate that but, especially with this issue, we need to be as precise and accurate as possible.
Yeah, I can see that. Could I suggest that you ask here before believing the hype?
Where are you seeing that 1Mb CAN becomes overloaded with reading an accelerometer with steppers operating? In general, there is lots of bandwidth available for operating the printer and the only case where steppers are being used with an accelerometer is when you are doing resonance testing which does not generate a lot of timing signals for the steppers.
It is EXTREMELY difficult to compare the data bandwidth between communications protocols. Bi-directional communications paths rarely provide any kind of significant speed advantage in applications because most messages can be characterized as COMMAND-WAIT_FOR_ACK which means that there is no advantage to having a bi-directional communications medium. RS-232 has at least a 20% overhead, assuming 8-N-1 which is the most common byte formatting, and is probably more with the actual commands/data/acks going back and forth. Itās possible that NRZ serial at 250kbps is faster than 1Mbps CAN but I would want to see the analysis along with assumptions before stating that either approach is faster.
Could I ask that you donāt buy this board, unless you absolutely need to get things running? The H36 Combo uses an STM32 as its MCU and an ADXL345 as its accelerometer. From what I understand, that combination is running fine and bringing it in can add to the confusion.
May I misinterpreted this and its only valid for bridge mode CAN but I think it was this:
Even at a CAN bus frequency of 1000000, there may not be sufficient bandwidth to run a SHAPER_CALIBRATE test if both the XY steppers and the accelerometer all communicate via a single āUSB to CAN busā interface.
I have removed that blurb from the documentation (commit 17b8ce4c):
--- a/docs/CANBUS.md
+++ b/docs/CANBUS.md
@@ -125,11 +125,6 @@ iface can0 can static
frequency. As a result, it is recommended to use a CAN bus frequency
of 1000000 when using "USB to CAN bus bridge mode".
- Even at a CAN bus frequency of 1000000, there may not be sufficient
- bandwidth to run a `SHAPER_CALIBRATE` test if both the XY steppers
- and the accelerometer all communicate via a single "USB to CAN bus"
- interface.
-
* It is only valid to use USB to CAN bridge mode if there is a
functioning CAN bus with at least one other node available (in
addition to the bridge node itself). Use a standard USB
That statement was added to the documentation a few years ago and it predates several low-level Klipper āUSB to CAN bus bridgeā mode optimizations.
That said, there are some limitations on the bandwidth available when using a CANbus. As a rough ārule of thumbā Iād say a given canbus frequency has roughly half the available bandwidth of the same UART baud rate - so, for example, Iād say a 1Mbit canbus is roughly equivalent to a 500000 BAUD UART connection. This is due to higher message framing overhead and the underlying half-duplex nature of the protocol. The imbalance is a little more extreme during SHAPER_CALIBRATE tests though, as this is one of the rare times where we have a large amount of traffic going in both directions (host sending large amounts of XY stepper movements to MCU and MCU sending large amounts of accelerometer data to host). In this case, itās probably closer to a 1/3 or 1/4 ratio between canbus and UART - so for example, a 1mbit canbus frequency may have an equivalent bandwidth to a ~300000 baud uart connection. If using Klipperās āUSB to CANbus bridgeā mode then one should account for all of the traffic going to the bridge node and the canbus nodes in that canbus bandwidth (in practice, the bridge node doesnāt get a āfree passā on available bandwidth).
Separately, regular USB typically provides 20+ times the bandwidth compared to 250000 baud UART connections. So, traditional USB (ie, emulated serial over USB) is a clear winner when it comes to low-latency and high-bandwidth.
In case anyone is curious, I think canbus can be very useful for toolhead and gantry mounted mcus where the wires going to them are under constant flex. The ability to easily deploy canbus over high quality wires I think makes up for its other quirks (eg, 20awg with silicon/ptfe insulation). I personally, would stick with USB for situations where the wiring is static. Where I do deploy canbus, I will also typically consider using āusb to canbus bridgeā mode to reduce the number of active micro-controllers.
Finally, if using canbus, I recommend using 1Mbit canbus rates regardless of required bandwidth as that higher frequency also helps reduce message round-trip-time latency.
Could I trouble you for a more detailed explanation of what youāre writing here?
Iām curious how much of the full duplex nature of a UART connection is used in Klipper. I know Iām not very versed on Klipper communications but I would be surprised that there is a lot of two way traffic - I would expect that most communications are initiated by the host which then waits for a response from the controllers, essential half-duplex in nature. Do the controllers send unsolicited data to the host or does the host send out commands while it is still receiving data from previous data requests?
Secondly, we need to make sure that we are talking the same language when we talk about UART data transmission speeds; Iām really asking how do you define ābaudā? Do you mean the total number of bits per second being transmitted or the number of data bits per second - theyāre very different things. As I noted above, for 8-N-1 NRZ Serial transmission (what I believe is being used here - at least Iād be very surprised if it wasnāt) the actual number of data bits being sent are at least 20% less than the total number of bits being sent (as each data packet is 10 bits long, with 8 payload bits and a start and stop bit which are used for synching the incoming data stream). I say āat leastā 20% less because NRZ Serial communications can have time delays in between bytes which further decreases the effective data rate.
Finally, what are the packet formats that you are using? Weāve talked recently about CAN packets, the base format (which can carry eight to 64 bits) has an overhead of 47 bits. What is the format for UART communications? At the very least, I would expect there to be a destination byte, command byte, length byte, payload, CRC and an ack byte - leading to 50 bits (five eight bit packets that take 10bits to send) of overhead plus the two bits for every payload byte. Maybe Iām putting in more overhead in my assumption of the UART packet but it seems to me that CAN vs UART is basically a wash in terms of the amount of overhead need to send each data bit with CAN becoming more efficient as the number of bytes per packet increases.
To net it out, unless Klipper is designed to handle a significant amount of full duplex traffic and UART data packets are a lot smaller than I would expect, it seems to me that CAN would have a similar data rate to UART communications for the same bit clock rate.
Please donāt think 'm trying to be argumentative; Iām genuinely curious about how Klipper works and why my back of the envelope analysis seems to be so different from what youāre saying.
Iāve moved this conversation to a separate topic.
In practice, during normal printing, very little traffic goes from MCU to host. The mcu can send messages to the host at any time (the host does not need to explicitly request content from the mcu), but there isnāt typically a lot of data to send. Most of the mcu to host traffic during normal printing is Klipper protocol ack messages - there will be one ack for every message block. A message block (during normal printing) is typically from 58-64 bytes and the corresponding ack is 5 bytes.
Iām referring to what one would set in āmake menuconfigā and what gets set at the OS level. So, 250000 for most Klipper uart configurations. Which is, indeed, 25000 bytes of available application data.
In brief, the message traffic is accumulated into āKlipper message blocksā and then we send those message blocks directly on the UART wires, or as application data in canbus packets. So, if we have to send 25000 bytes on UART wires then the equivalent on canbus would be 25000/8 == ~3125 canbus packets.
If we run the math on that, 3125 packets (each 8 bytes) would have a minimum of 346875 bits (3125 * (64 + 47)). Then weāll have the ack packets - we can estimate ~350 of them which is another 30450 bits (350 * (5 * 8 + 47)). Weāll also have stuff bits though, which Iāll estimate at ~10% and so another 37733 bits((346875 + 30450) * .1). So, all told weāre up to ~415000 bits. There is other mcu to host traffic though (weāve only accounted for ack messages here) and not all canbus packets will be entirely full. Anyway, this is how I come up with the roughly twice higher canbus frequency needed compared to uart baud - or said another way 250000 baud uart will give 25000 bytes per second in each direction, which would require roughly a 500000 canbus frequency.
Thank you - I realized that I should have done that when I sent my last post.
A couple of comments back. There are a few discrepancies I want to work through and I think theyāre largely due to my ignorance of how Klipper works.
This doesnāt answer the question: when using the UART, how much data is sent from the MCU to the host while the host is sending to the MCU? Data transferring in both directions simultaneously is how I define āfull duplexā.
My assumption is that full duplex is not really used in Klipper - the host sends out a command/request and doesnāt continue to the next command/request until the ack from the previous one has been received. Is this correct? If it is, then it doesnāt matter if the transfer medium is half duplex or full duplex.
Just for a reset, Iām realizing that the Klipper message block is embedded into the CAN base format packet so the message block increases in size to 101 bits (assuming 8 bytes for the Klipper message block and the 47 bits required for the CAN base frame packet overhead).
If itās okay, can we assume for this discussion that:
Klipper Message Block size is 64bits (8 bytes)
Klipper Ack Block size is 40bits (5 bytes)
CAN Wrapped Klipper Message Block size is 101bits (8 byte Klipper Message Block + 47 CAN base frame packet)
CAN Wrapped Klipper Ack Block size is 87bits (5 byte Klipper Ack Block + 47 CAN base frame packet)
It looks like youāve used these values in your calculations but I want to make sure theyāre stated explicitly.
The make menuconfig value is the ābaud rateā or ābit rateā but is NOT the ādata rateā.
I just went through Klipper/stm32/src/serial.c and confirmed that you are setting the UE (USART Enable), RE (Read Enable), TE (Transmit Enable) & RXNEIE (Receive Data Available Interrupt Enable) bits of the USART CR1 register. You are not changing the āMā bits which reset to 0x0000 0000 as per the datasheet:
The first bit (āSTARTā) which is low and the last bit (āSTOPā) is high with the remaining bits being the byte to be transmitted. The START and STOP bits are overhead and cannot be removed as they are part of the UART protocol.
When you are transmitting at a baud rate of 250,000 bits per second, youāre actually transmitting 20,000 bytes per second - not the 25,000 bytes per second you stated above.
To send 25,000 bytes of data per second you will have to run the USART at 25,000 * 10 / 0.8 = 312,500 bits per second.
Since your calculations below for CAN are for 25,000 data bytes per second, Iāll use the 312,500 bits per second UART rate which produces 25,000 data bytes per second in my calculations below.
I was really asking what was the size of the Klipper message block - as discussed above, for purposes of this discussion, Iām assuming its 64 bits (8 bytes).
Why are you not adding the ack packets and āstuff bitsā to the total required UART packets? This goes back to my question about how much does Klipper, when communicating via UART, perform bi-directional data transfers? If the acks, data responses and the āstuff bitsā can be sent to the host while itās sending or commands and requests, I guess they can be ignored.
If the acks, data responses and āstuff bitsā canāt occur while other commands and requests are being sent, then we need to account for the same packets when calculating the total number of bits transferred using the UART, this means that we have to add:
~350 ack packets which will be 350 * 5 bytes * 8 bits/byte / 0.8 (to account for UART START/END bits) = 17,500 bits
~10% āstuff bitsā which are (250,000 (Actual Data Bits) + (350 * 5 * 8 for the number of ack packet data bits) * 0.1 (10%) / 0.8 (to account for UART START/END bits) = 33,000 bits
So, to send 250,000 bits via UART in Klipper, a total of 333,300 bits are required.
When I get the ratio of the number of CAN Bus bits required to send 250kbits to the number of UART bits required, I get 415,000 / 333,300 = 1.24
If the acks and responses can be ignored in the UART case because they happen while other commands/requests are being sent (the āfull duplexā scenario) then the ratio increases to 415,000 / 312,500 = 1.33
I hope youāre not offended but these ratios seem a lot more realistic than the claimed 2x difference. Maybe thereās a serious error in my assumptions but I feel comfortable with these results.
That is not correct. The mcu may send data to the host at any time, it is normal for the mcu to be sending data to the host while the host is sending data to the mcu, the host may send many āmessage blocksā prior to receiving an ack, and those acks may come while the host is sending new data.
When using UART, Klipper is full-duplex. When using any other mechanism, that mechanism must emulate a full-duplex connection or the Klipper mcu communication protocol will not function.
Iām not sure how to answer that question. How much data the mcu sends to the host is dependent on how much data it needs to send. During a SHAPER_CALIBRATE command with an adxl345, for example, the mcu needs to send 16000 Bytes/s of accelerometer data (plus overhead). The mcu encodes this data into āmessage blocksā and sends them to the host. On UART, it would send this data simultaneously with message blocks arriving from the host.
A Klipper āmessage blockā can vary in size from 5 to 64 bytes, but is typically close to 64 bytes during normal printing. It does not make sense to assume an unreasonably small size because that would skew the protocol overhead.
To be clear, the āmessage blocksā are application data. They do not necessarily align with canbus packets, nor would they necessarily align with USB packets, nor with any other lower transport packet.
That is not correct. If I configure the OS to use a baud of 250000, I can consistently transmit 25000 bytes of application data per second. Each application byte is 8 bits, and there are two bits of overhead per byte (a āstartā and āstopā bit). That makes each application byte consume 10 ābit timesā total. Thus 250000 bits per second divided by 10 is 25000.
I have tested this many times. I am confident in my numbers. If you are not confident I suggest you setup a local test and time some large transfers.
The ack message blocks on UART are different because UART has a dedicated mcu-to-host channel. So, sending āack message blocksā does not delay host to mcu message blocks on UART, but does delay host to mcu message blocks on canbus.
I do not include āstuff bitsā on UART because UART doesnāt have stuff bits - it has start and stop bits (as previously discussed). Bitstuffing is a canbus thing - CAN bus - Wikipedia ,
A bit of a sidetrack from the baud rate discussion, but does the USB to CAN bridge cause significant drops in step performance? Iād imagine that a 1 Mbit connection doesnāt come for free or are these separate function blocks that are more or less independent of the rest of the MCU?
I havenāt seen any degradation like that (but I admit it isnāt something I regularly test). The stepper code is mostly driven by ātimersā (ie, irq handlers) and is unlikely to be directly impacted by typical ātaskā activities.
Just to add to this topic, if anyone is concerned about available bandwidth, then a good test is to run the command dispatch benchmark. In practice it stresses the underlying communication system and Klipperās corresponding communication code.
The benchmark results from that test will show the number of commands per second that the host can issue to the mcu. One can, in practice, also figure out the total number of application bytes the host sent to the mcu in that process. The underlying command utilized is the debug_nop command, which in practice will encode to 1-byte per command, grouped into 64-byte message blocks, with 59 commands per message block (the remaining 5 bytes in the message block are for headers/trailers). So, if the test reports 100000 commands per second, then in practice thatāll be 100000/59*64 == ~108475 application bytes per second.
You can also inspect the underlying line statistics by running the STATS command in console.py before and after each test. Look for increments in bytes sent, bytes received, sent/receive sequence numbers (there is one message block per sequence number), retransmits, canbus interface errors (if applicable), etc.
Just a final post here - I set up a couple of systems to look at the actual data going back and forth.
The setups are very simple. I just wanted to have some basic communications going on so I am just looking at temperature measurements. I wanted to keep the hardware as similar as possible so that we are comparing apples to apples as much as possible.
When I looked at the communications, I found two cases which I think are representative of whatās been discussed in this thread - one in which a data response is requested by the host and one in which the controller sends unsolicited data to the host. When showing the images on the oscilloscope, Iām using 100Ī¼s per graticule which is 1ms across the screen.
In the first system, it uses an STM32G0B1 board, running at 64MHz with a Raspberry Pi Zero host communicating serially.
For requested data, the communications take 900Ī¼s and an unsolicited communications packet takes 500ms.
In the second system to look at the corresponding CAN signals, I am using a BTT CB2 host with an STM32G0B1 main controller board, running at 64MHz with 1MHz CAN communications to a toolhead with an STM32G0B1 MCU.
For requested data communications takes 350Ī¼s and unsolicited communications take 200Ī¼s.
As CAN is running at 1MHz, I should multiply these times by four to be able to compare to the 250kHz Serial communications. This means that requested data should be increased to 1,400Ī¼s and unsolicited is 800ms.
Getting the ratio to the Serial values, CAN requested data communications takes 1,400 / 900 = 1.56x and unsolicited communications takes 800 / 500 = 1.60x.
This is a bit more than what I was expecting and what I was basing my āgutā feeling on.
Some background. When I first set up my Voron 2.4, I used an Octopus with a BTT Pi host connected serially running at 250kbps. I then added a CAN toolhead with an ADXL345 which necessitated going to a USB connection - CAN was running at 250mbps (which was standard at the time). No issues.
I then designed three custom CoreXY printers, using a combination of Octopus and Manta main controller boards along with CAN toolhead controller boards with all of them running CAN at 250kbps. Over the next two years, I made another printer plus reworked my old Sapphire Pro both with a CAN toolhead running at 250kbps. No issues.
Over this past year, Iāve āupgradedā to 1Mbps on all my printers and I havenāt seen any difference in performance or in how resonance compensation works (which I believe is where CAN running at 250kbps experiences issues).
The only reasons that I could conclude that I never saw any issues with CAN at 250kbps are a) I was lucky or b) the analysis of the CAN overhead vs Serial is not correct.
This is why I pushed back on the stated difference between CAN and Serial and tried to understand the overhead on my own.
