File Transfer Failure when transfering to Adventurer 4

[justinthenic]

TL:DR When transfering a .gx file from my pc to my Adventurer 4, the file shows as complete in Adventurer Client, but the AD4 shows "Failed to open the file". The same file is able to be transferred and prints via Flashprint 5, or via USB.

I've done some sniffing of the file transfer, and I see a few differences between the Flashprint 5 transfers and the Adventurer Client. They are:

1. Packet size: Flashprint sends a packet size of 4150 (TCP of 4096), while AC sends varying sizes up to 64294.
2. ACK Number: Flashprint sends an ACK number of 800, while AC sends an ACK number of 882
3. Last Packet: Flashprint completes the file transfer with a final packet similar to the rest, while AC sends a final packet flagged by wireshark as an "ESP" packet, a TCP Encapsulation of an IPsec Packet with a Security Payload.
4. M29 command: Flashprint sends a packet following the last file data packet with a M29 command

Relevant Versions:

AD4 Firmware: V2.2.4-2.3
AC Version: 1.3.142
Windows 10 Pro Version: 22H2
OS Build:19045.2604
Windows Feature Experience Pack: 120.2212.4190.0

Example .gx file attached
Example AC logs from Debug Tab for gx file
For Wireshark captures, PC is .48 and the AD4 is .24
Wireshark capture for AC transfer failing:
Notes:
The last file packet is # 1472, M29 command looks to be also at the very end of 1472.
The AD4 seems to accept the M29 command in packet # 1501,
The M23 command is sent #1506 (to 0:/user/test_transfer.gx (ends with 0x0a LF)
The AD4 seems to accept the M23 command in #1510 ok, but Size of 0.

Wireshark capture for Flashprint transfer working:
Notes:
Last file packet is # 3491,
M29 command is # 3496.
M23 command is # 3499 (to 0:/user/test_transfer.gx (starts 0x7e ends with 0x0d0a -CRLF)
M23 command is received in 3501, shows received, opened, with a Size of 4693967, FIle ok.
M119 command is sent in 3503.
M119 command is received in 3504

AC_AD4_Transfer_failure.zip

[andycb]

This is fantastic, that's for taking the time to capture the traffic - that's really helpful. I'll dig into it deeper when I have some more time (you're more than welcome to dive into the code yourself :)), but it looks like the client will need to use a slightly different protocol with the Adventurer 4. Can you confirm that on the home screen of the app, it correctly shows the Model of your printer? If it does, it can use that to decide the protocol to use when transferring.

[justinthenic]

No problem, I know what it's like being on the other side of debug reports :).
Yes, I can confirm that the Model is shown as "Flashforge Adventurer 4" and has the correct information in all the fields of the Status tab.
I also have been messing around with sending files from both the FP5 tool, and AC. I've found that if I send a much smaller file from AC, the AD4 actually goes into reset and needs a powerdown to come back, (The screen goes blank, and it drops it WiFi connection). I ALSO had the FP5 fail transfering a file once similar to how the AC fails, with a message of "Failed to open the file" displayed on the AD4, out of maybe 30 times.
I'm starting to wonder if the data is just being sent too quickly for the AD4. (There may also be a missing "print" command after the file transfers, once we have it transfering completely). I'm thinking I would like to just add a pause in after every chunk of data, giving the AD4 more time to process it and save it in it's memory (on a local test branch here). I tried to find where in the AC's code the file is being broken up into chunks to send out, but I haven't found the right spot yet to try adding a delay. Mind pointing me in the right direction if you have a chance?

[andycb]

The file is broken up and sent here: https://github.com/andycb/AdventurerClientJS/blob/3a72ee4b71e5e73946f1ad403a9de853aecb5915/src/electronApp/printerSdk/printer.ts#LL247C5-L247C12 The chunk size is a constant in that file - If I recall correctly, that was the size the Adventure 3 + FlashPrint used according to some other users on Reddit.

I don't recall off the top of my head if the printer ACKs each chunk... I vaguely think it might.. In which case, slowing it down may well just be a case of not sending the next chunk until theres acknowledgment of the previous.

[justinthenic]

Thanks for the pointer, that's exactly what I was looking for. Perhaps it's the next network layer on the windows side, but it looks like those chunks are getting re-combined and split into larger packets by the time they are sent out on the wire. I'm thinking that a pause here will force it to send the packets as intended, and at least verify this is where the issue is.
When looking at the FP5 -> AD4, they are still sending the 4096 bytes that you are breaking the file up into in printer.ts.

[marcvang]

@justinthenic were you able to solve it? I have the same issue, where my printer displays that 101% of the file is transferred.