The Adventurer3 controller also supports the problematic part of Adventurer3-Wi-Fi connection with firmware Ver1.3.1..
How to respond
The Adventurer3 farm now supports transfer in both old and new versions.
There are two change sources, AControlerAdventurer3.cs and PrintControlerAdventurer3Controler.cs.
Adventurer3.cs has been changed so that the file transfer process is separated from the Adventurer3 class and performed via the interface called ISender.
ISender prepared a class for the old version (V1Sender) and a class for the new version (V2Sender), and changed to switch the class to be used depending on whether V2.1 is included in the return character string of the M601 command.
For the transfer processing of the old version, the original transmission processing in the Adeventurer3 class can be used as it is, but the transmission processing of the new version has the following two problems.
- It was necessary to create and send a packet with a fixed length of 4096.
- Cancellation process during file transfer.
Adventurer3Controler.cs contains a small modification related to the file transfer cancellation process.
Send at fixed length of 4096
Originally, I thought that it should not be necessary to send with a fixed length, but in order to implement cancellation processing during transmission, I internally called the send API with 4096 bytes.
When I looked at the network protocol in this state, it was sent with an appropriate length, probably within the SendBufferSize set in TcpClient, and split in units with a little time between send. ..
There was no problem with the small file size, but with the long file size, the problem occurred that the file could not be sent correctly and the connection with Adventurer 3 was disconnected.
Therefore, when the SendBufferSize was set to 4096 and the data was sent, the data could be sent without any problem.
Looking at the network protocol, I was able to confirm that it was transmitted in 4096 byte units.
Cancellation process during file transfer
In the old version, it is confirmed whether Adventurer3 has received it for each packet, and when the cancel command is sent, a confirmation dialog indicating that the transfer has stopped is displayed on the panel of the device. It was.
By the way, the old version can communicate with the device while the dialog is displayed, so it is possible to control from the Adventurer3 controller without selecting OK in the confirmation dialog.
In the new version, files are still being transferred, so if you cancel in the middle, you will have to wait until Adventurer3 exits the transfer failure timeout, during which time control from the Adventurer3 controller will not be accepted.
When I actually checked the time-out time, 15 seconds was just right.
コメント