Page Comparison

...

1. CWM Buffering

2. OKE Inbound File Transfer Throttling

3. Aborting an OKE Inbound File Transfer

4. Transferring Large Files

5. Faster Baud Rate Negotiation

6. Fastest Interface

7. File Transfer Throughput

8. File Transfer Status

9. File Status

10. Firmware

11. Writing from the OKC to an OKE System

12. Throttling File Fragments

13. Pseudocode Example

14. Testing File Transfer from Open Kitchen

15. Common Problems

16. Debug Log Output

...

The USB interface can support the highest transfer speeds. Although the 232 and USB transfers rates are similar with the current WiFi Wi-Fi CWM hardware, in the future newer CWM hardware will allow the USB interface to go much faster than 1000000 baud.

...

The amount of time it takes to transfer a file is a function of many variables including file size, processing latencies, and link bandwidths. The following table shows the estimated throughput between the MiWi and WiFi Wi-Fi CWM versus the OKE connection type:

...

OKE implementors should use these throughput estimates along with their product requirements to help determine the CWM communication port type (USB, serial, etc.) and settings (baud rate, full/half duplex, etc.) and the recommended CWM network type (WiFiWi-Fi, MiWi, etc.) for their application. Poor wireless connectivity or OKE file transfer throttling will reduce throughput so OKE implementors should verify that file transfers are meeting their requirements during the development and integration phase.

...

1. A MiWi CWM connected to an OKE via any communication interface can transfer a 1MB file in about 1 hour.

For the WiFi Wi-Fi CWM the OKE connection to the CWM will be the primary bottleneck for file transfers. Generally, the WiFi Wi-Fi CWM should be able to transfer files to the OKE at a significant fraction of the OKE connection's baud rate.

WiFi Wi-Fi CWM transfer time examples:

1. A WiFi Wi-Fi CWM connected to an OKE via USB can transfer a 1MB file in about 46 seconds.

2. A WiFi Wi-Fi CWM connected to an OKE via TTL full duplex serial at 115200 can transfer a 1MB file in about 3 minutes.

3. A WiFi Wi-Fi CWM connected to an OKE via 232 full duplex serial at 1000000 can transfer a 1MB file in about 50 seconds.

4. A MiWi CWM connected to an OKE via TTL full duplex serial at 115200 can transfer a 1MB file in about 1 hour.

5. At comparable baud rates a half-duplex serial connection will be slightly slower than a full duplex connection for OKC to OKE file transfers.

...

Bool CWPortGetInboundFileWriteBuf (uint8_t** buf, uint16_t *bufSize)
{
    static uint8_t ftBuf[CWMSGCMD_FT_MAX_SIZE];
    CW_REQUIRE(buf != NULL);
    CW_REQUIRE(bufSize != NULL);
    *buf = ftBuf;
    *bufSize = sizeof(ftBuf);
    CW_ENSURE(*buf != NULL);
    CW_ENSURE(*bufSize >= CWMSGCMD_FT_MAX_SIZE);
    return true;
}

bool CWPortExeFileWrite (int8_t* fileStr, uint32_t offset, uint8_t* data, uint16_t dataLen)
{
    CW_REQUIRE(fileStr != NULL);
    CW_REQUIRE(data != NULL);
    CW_REQUIRE(dataLen <= CWMSGCMD_FT_MAX_SIZE);
    if (offset == 0)
    {
        if (fpWrite != NULL) fclose(fpWrite); /* Close open files */
        CW_ASSERT((fpWrite = _fsopen(fileStr, "wb+", _SH_DENYNO)) != NULL);
    }

    CW_ASSERT(fwrite(data, 1, dataLen, fpWrite) == dataLen);
    if ((dataLen < CWMSGCMD_FT_MAX_SIZE) && (fpWrite != NULL))
    { fclose(fpWrite);}
    return true;
}

Anchor

...

Testing-File-Transfer-from-Open-Kitchen Testing-File-Transfer-from-Open-Kitchen

Testing File Transfer from Open Kitchen

See the following document and video for instructions on testing file transfer.

https://sitesage.atlassian.net/wiki/x/FwBfFQ

https://www.loom.com/share/85f56abaf2874fa79c844c5e0580eb36?sid=aea09ba1-0528-40cf-890f-d6536f5d3f73

Anchor
common_problems common_problems

Common Problems

1. OKE implementation expects a hardcoded file name and file uploaded to OKC doesn’t match:
   It’s commonly seen that developers hard code an expected file name for certain file types, e.g. firmware.bin, menu.json. If someone subsequently uploads a file to the OKC with a different name (e.g. firmwareV1-2-3.bin), the file will be downloaded to the OKE (and indeed the status shown in Open Kitchen will be ‘downloaded’), but it isn’t loaded into the system because of the name mismatch. We recommend avoiding this approach and to instead encode identifiable information in the file header. If not avoidable, then ensure the file uploaded to the OKC is correctly named

2. Old CWM firmware and/or CWL version: In CWM1 firmware earlier than PIC154/SPH145 and ConnectWare Library versions < 1.0.15, there was a bug in the fragmentation layer that caused messages of certain lengths to be dropped. This can cause a multitude of issues including download rewinds due to dropped fragments (ultimately ended in an aborted download), and files that do ‘successfully' download to the CWM but aren’t loaded into the OKE. If you encounter such issues, please ensure your CWM firmware and CWL versions are up to date.

3. File name + extension longer than 16 characters: the OKC now prevents this from happening, but it may still be possible to do with the simulators. The CWL has a 16 character limit on the file name including the extension. If this limit is exceeded, the CWM will download the fragments from the OKC but just throw them away. Please ensure file names are <= 16 characters including extension.

4. File Name + Version + Account ID not unique combination: Currently, there is a unique index in Open Kitchen Database that requires a combination of File Name - Version - Account ID to be unique even the uploaded file has been deleted. If Version does not have value entered by user, it will have timestamp value. However, user can enter Version for it to be used to match with equipment data for file transfer status. If this is the case, it may cause violation of unique File Name + Version + Account ID combo key. In this scenario, if a firmware file needs to be uploaded from the same Account, it needs to have unique File Name and Version (if input by user) every time it is uploaded even after it is deleted from Open Kitchen.

5. Connectware Module V2 uses low baud rate: Some likely scenarios are the following.

   1. If a CWM2 reports the baud rate as 115200 in its heartbeat, it could be because OKE does not request a baud rate change to increase the RS232 baud rate from 115200 to 230400. CWM2 will accept the baud rate change request from the OKE over the 232 port. The OKE could put some temporary debug output in the CWL where it make the baud rate change requests and processed the baud rate change responses.

   2. If the OKE was connected to a CWM1, and a CWM2 was swapped in without the OKE restarting, then the OKE will not request a baud rate speed increase. This is because the CWM1 cannot run faster than 115200 and informs the OKE that it does not support a speed increase. The OKE will no longer request a speed increase until the OKE’s CWL is restarted. Low baud rate on CWM2 can cause slow file transfer. The baud rate speed is independent of doing a file transfer. Therefore there is no file transfers increased until the CWM reports its baud rate at 230400, since it will never go faster than about 1 hour.

   3. Does OKE run a build that does not change baud rate?

   4. There are some hardware or cabling problem that causes the speed rate change to fail. For example, the speed increase takes effect, but the OKE and CWM cannot communicate successfully at that speed, and eventually revert back to 115200. It is expected that the CWM would sometimes report “baud”:230400 if this was the case.

Anchor
debug_log debug_log

Debugging Log Output

...