大家好，我的虚拟机上装的UBUNTU，虚拟机名字为VMWAER，UBUTNU串口和WINDOWS相通，我打开KLIPPER的FLUIDD，WINDOWS上串口助手显示乱码，请问怎么办？Hello everyone, I installed UBUNTU on my virtual machine, the name of the virtual machine is VMWAER, UBUTNU serial port communicates with WINDOWS, I open KLIPPER’s FLUIDD, the serial port assistant on WINDOWS shows garbled characters, what should I do?The data sent by the upper computer is:
UART is not meant to be human readable but is a machine to machine connection, i.e. connecting the Klipper host application to the microcontroller on the printer board. See Klipper Architecture / Ecosystem for more explanation
Thank you, serial communication generally has a protocol, such as: host computer says: you are 0? The next computer said: I am 0, so that you can connect, also, there is a communication protocol here, this communication protocol can be viewed with CUTECOM software.
Thank you, but the data I found on the CUTECOM software is: [18:32:37:256] (B$~<0x1b><0x01>
[18:32:39:183] <0x01><0x0e><0x11><0x04><0x08><0x11><0x01>
[18:32:39:229] (B$~~<0x08><0x11><0x01> No description of this data is found in the protocol documentation.
Just for the sake of clarity and without any offense meant or implied:
This information makes no sense for the regular user
The protocol as described is encoded and compressed
You need to dig into the code and become very familiar with Klipper’s inner workings to understand this
If you do not understand it and you cannot follow the information provided in the documentation AND in the code, then probably this is not the right task for you
I’m not an expert on this low level stuff (and I do not care, luckily there are folks who understand it), but I’m pretty sure that just looking at the raw UART communication will take you exactly nowhere.
Thank you for your answer. I am engaged in electronic design in China, many of my friends just don’t know this protocol, so they can’t connect to it, and then they gave up this study. I want to understand this and help them, and I will review the code myself, thank you!
Can you describe the hardware that you’re using to as well as how things are wired?
It appears to me that in the first serial stream you presented, is showing invalid data due to something like an incorrect data rate on the receiver/monitor.
How are you determining the data rate for the software?
Thank you for your answer. At present, I installed the KLIPPER software in VMWARE and then installed the virtual serial port software. KLIPPER controls commands through FLUIDD software. When I open a web page, the related serial port will send commands to CUTECOM to display the baud rate of 250,000. It does not have much use, the data is still like this, of course, it seems that the data is very stable, this data should be right, but I do not know the meaning of this data.
I just used Notepad++ on one of the (B$~~\0 sequences that you’re reporting and it displays it as:
The byte sequence is 0x28-0x42-0x7E-0x7E-0x08-0x09-0x02-0x00 and going back to the pages @Sineos gave you (Protocol - Klipper documentation) , it can be massaged into an eight byte message packet knowing that 0x7E is the sync byte is at the end of the sequence (and it means that the sequence starts out with the ASCII BS character (0x08) which means that it is eight bytes long.
Following through the documentation page, I could probably decode what you’re getting by going through what’s in your original post, converting the squares to ASCII control characters and figure out what is actually being sent.
However, I don’t want to - you can do it yourself.
What I can give you that I think will be of the most help is to recommend that you continue reading the documentation page and go down to:
and set up a simulated Klipper-AVR target and observe the communications from there - that seems to have the capabilities you’re looking for and you should be able to monitor the communications between the Host and the Main Controller Board as you seem to desire.
Hello, here is a description of the message block:
All data sent from host to micro-controller and vice-versa are contained in “message blocks”. A message block has a two byte header and a three byte trailer. The format of a message block is:
<1 byte length><1 byte sequence><2 byte crc><1 byte sync> The length byte contains the number of bytes in the message block including the header and trailer bytes (thus the minimum message length is 5 bytes). The maximum message block length is currently 64 bytes. The sequence byte contains a 4 bit sequence number in the low-order bits and the high-order bits always contain 0x10 (the high-order bits are reserved for future use). The content bytes contain arbitrary data and its format is described in the following section. The crc bytes contain a 16bit CCITT CRC of the message block including the header bytes but excluding the trailer bytes. The sync byte is 0x7e.
When I open the FULIDD software using WEB, my serial port software receives the following message:
08 11 01 5c 30 28 42 24 7e 7e
The first data is 08, indicating its corresponding length。
So what does the second 11 correspond to?
The meaning of the following data is not clear, I did not see the specific instructions in the relevant documents,
what kind of data should I send to answer? thank you
If you read the documentation, you will see that a sync byte may proceed a packet (which means the second 0x7E in your sequence is actually before the next packet).
As for the actual “Byte Sequence” and “Packet Data Contents”, I think you’d be best off reading the code to understand the values.
Regardless, I think you’re going too far afield here.
Going back to the original question, you’re trying to get a PC running a VM to communicate with a main controller board running Klipper - correct?
As @Sineos indicated above, Klipper has a fair precise timing requirement for messages which is very difficult to achieve with a VM. Understanding the protocol will probably not get you to your desired state (a working printer with Klipper software running on the VM).
It would probably be better for you if you got something like a Raspberry Pi 4B and connected it to your host serially and then scope the data going back and forth. This will give you a good idea of timing requirements as well as a comparison point for your PC’s serial communication with your main controller board.
