During the dryer-power-cycle strace this line of events happened:
Open TTY
Send get_info a few times while the printer starts
Read only 64 bytes of the info
Send get_status
The rest of the info is response is never sent
Read get_status response as part of the info
Error, then try again
There's two issues here:
First, Anycubic doesn't seem to be locking access to the ACE when sending and receiving RPCs. This seems like it could be a problem during printing maybe? Who knows. Maybe they just forgot a lock for this part of code.
Second, for some reason only 64 bytes of a get_info is being received. The only thing that makes sense to me is that the ACE's logic is something along the lines of this:
Receive and buffer data
If there's a command, process command once frame is buffered
If there's command output, write command output to a buffer
Output 64 bytes of buffered data
This would mean:
get_info is filling a buffer with data
It outputs 64 bytes of that buffer
get_status empties the buffer and fills it up again
It outputs 64 bytes of that buffer
It outputs another 64 bytes of that buffer, etc
When I say 'output 64 bytes of buffered data', I mean send a USB CDC packet which is up to 64 bytes long. Linux buffers these between read() calls, which in theory means you could read while it's still sending packets, though in practice it seems that it reads are far apart enough that all data is sent by then, no handshaking needed.
During the dryer-power-cycle strace this line of events happened:
There's two issues here:
First, Anycubic doesn't seem to be locking access to the ACE when sending and receiving RPCs. This seems like it could be a problem during printing maybe? Who knows. Maybe they just forgot a lock for this part of code.
Second, for some reason only 64 bytes of a get_info is being received. The only thing that makes sense to me is that the ACE's logic is something along the lines of this:
This would mean:
When I say 'output 64 bytes of buffered data', I mean send a USB CDC packet which is up to 64 bytes long. Linux buffers these between read() calls, which in theory means you could read while it's still sending packets, though in practice it seems that it reads are far apart enough that all data is sent by then, no handshaking needed.