Thanks,
I understand about licensing.
But, "huge source of external noise" is a little bit stretch for me. I have WiFi in raspberry pi in the printer, laser printer with WiFi next to it, phones and computers WiFi. Additional WiFi module in the printer head will not ruin everything.
WiFi, BT and other forms of RF communication is
just a no go in a real time system. The default 250K baud on serial in Klipper, while far less bandwidth than even the oldest WiFi spec (not that Klipper really needs high bandwidth, it's all binary messages), the win here is the far more consistent message latency. Klipper expects things to be solved within about 25 ms in a multi MCU setup for the full round trip acknowledgment of things, meanwhile WiFi might be 3ms, but then someone turns on the microwave and causes interference that takes the access point a bit to resolve by hopping bands, then you get spike of lost packets or latency. Bluetooth is kinda infamous for it's latency being detectable by humans with watching video and the audio going out of sync (though modern protocols and codecs have gotten much better).
Serial is just constant 4 microseconds per symbol/bit sent, the packet to turn on a pin is about 8 bytes with all the headers and no additional commands (would pack in more commands for the cost of the 5 bytes of headers, CRC check and the sync byte). That's a consistent 256 microseconds to transmit, or just over a quarter millisecond, plus an average of 2 microseconds for arriving out of sync with the serial clock. Could tack on more to account for how it got to the serial chip or off it on the target device, but I'm discounting that for WiFi too. And yes, I'm aware it often gets punted over USB, as far as Klipper is considered on both sides, it's still real serial/UART and that's
far easier to math out, never mind that WiFi on the host device might be connected over USB too.
WiFi on the other hand, I will assume comes prewrapped in a IPv4/UDP packet into the WiFi module (20 bytes, 16 bytes minimum for IPv4, then another 4 for UDP). That all needs to be packed into a WiFI frame (looks like a minimum of 28 bytes for the frame's headers), so we are up to 48 extra bytes in headers and overheads in just shipping the 8 bytes we want Klipper to get. I'm going to just hand wave any cost for encryption, but I assume it's there, even if accelerated in hardware. Then it waits for it's turn on the on the RF (carrier sense multiple access with collision avoidance or CSMA/CA for short) which then allows it to be sent to the WiFi router/AP. After it gets to the AP, it's got to be decrypted, checked, and processed on the AP's firmware/OS before repeating the whole task of transmitting it again to the target device. Anything around 1-20 ms is reasonable for WiFI, but it's not consistent, nor does it promise anything for delivery times. Plus my example does not cover the cost of ACKing the WiFi frame, or other management frames, let alone issues with the RF spectrum like interference or what not blowing out the message and requiring retransmission.
Sure WiFi Direct and Bluetooth cut the AP hop out of the picture, that's fair. But no commercial CNC machine has anything wireless within it's control systems.
Why? No one wants to have to say why their spindle/gantry failed to stop when someone hit the e-stop because WiFi dropped out and lost that packet to that controller. I have a hard time getting 3 WiFi smart LED bulbs in a single control group to change color at the same time at a human scale of things, never mind the tight tolerances Klipper expects out of MCUs.
