7.15.15 Create UDP Communication Resource and Receive Data
URECV_C (Create UDP Communication Resource and Receive Data)
Functionality
-
The URECV_C system library is used for asynchronously creating UDP communication resources and receiving data.
-
This instruction executes asynchronously with the following capabilities:
- Configure and create communication resources
- Receive data through existing communication resources
- Reclaim and release current communication resources
-
Configuration and Creation of Communication Resources
- After configuring local IP address and port number in the UDP_CONFIG parameter block, set CONT parameter to true to initiate UDP communication resource creation.
-
Data Reception via Existing Resources
- When EN_R parameter is set to true after successful resource creation, data reception is activated. Users must:
- Bind data variables for reception in DATA block
- Specify reception length
- If LEN=0: Uses DATA block size (max 2048 bytes)
- If LEN≠0: Uses specified length (max 2048 bytes)
- Errors (0x80A5) occur when: LEN>2048 or DATA block size < LEN
- When EN_R parameter is set to true after successful resource creation, data reception is activated. Users must:
-
Connection Termination/Reset
- Set CONT parameter from true→false to reclaim and release communication resources
Parameter Specifications
| Parameter | Declaration | Data Type | Description |
|---|---|---|---|
| EN_R | Input | BOOL | Enable reception (continuous when maintained true) |
| CONT | Input | BOOL | Communication resource control: ● false: Release resources ● true: Create resources |
| LEN | Input | UDINT | Maximum reception length (bytes): ● 0: Use DATA block size (≤2048) ● Non-zero: Use specified length (≤2048 and ≤DATA size) |
| CONFIG | InOut | UDP_CONFIG | UDP configuration function block instance |
| DATA | InOut | ANY_TYPE | Reception data buffer (supports basic types, arrays, strings, UDTs) |
| ADDR | InOut | ADDR_PARAM | Source IP/port information storage |
| DONE | Output | BOOL | Operation status: ● false: Ongoing ● true: Success (1-cycle pulse) |
| BUSY | Output | BOOL | Operation busy flag: ● false: Inactive/completed ● true: Processing |
| ERROR | Output | BOOL | Error indicator: ● false: Normal ● true: Error detected |
| STATUS | Output | WORD | Execution status code |
| RCVD_LEN | Output | UDINT | Actual received data length (updated when DONE=true) |
Status Codes
Normal Status Codes
| CODE (16#) | Description |
|---|---|
| 0000 | Not invoked |
| 0001 | Socket creation ongoing |
| 7000 | No task is activated, REQ detects a rising edge but CONT is false |
| 7001 | Socket created |
| 7006 | Receiving data |
| 7007 | Resources released |
| 7008 | Data received successfully |
Error Status Codes
| CODE (16#) | Description |
|---|---|
| 8080 | Socket creation failed (system resource exhausted) |
| 8081 | IP configuration error: The IP address corresponding to LocalAddress does not exist, i.e., LocalAddress does not match the IPs of all the network ports of the PLC; The protocol of the PLC network port corresponding to the currently used LocalAddress is not Ethernet protocol; The current value of LocalAddress is 0.0.0.0; |
| 8082 | Address/port reuse error |
| 8083 | Bind failed (port occupied) |
| 80A1 | cont = true, the UDP communication resource has not yet been created successfully, but the current receive function has been activated |
| 80A4 | Empty data block |
| 80A5 | Length violation: ● LEN>2048 ● DATA size < LEN ● LEN=0 & DATA>2048 |
| 80A6 | Received data exceeds buffer |
| 80AA | Reception failure |
| 80AC | Async queue failure |
| 80C3 | Resource conflict |
| 80C4 | Resources already released |
Critical Implementation Notes
-
When EN_R is True, the UDP receive function is enabled. Unlike TCP, which uses data stream communication, UDP uses datagram communication. That is, the receiver of UDP can only receive one datagram content from the other party at a time, and cannot receive the specified size of data according to a specific length, once the other party sends more data than the size of the DATA size or the size of the LEN, then the error 0x80C9 will be reported;
-
When the current URECV_C uses the UDP_Config_1 connection block for receiving action, if the data has not yet been received during the current receiving process, the URECV_C function block will be deleted, and a new URECV_C_2 will be created to use the UDP_Config_1 connection block for receiving action as well, and an error of 0x80C3 will be reported at this time due to the fact that the current UDP_Config_1 connection block has not been received. UDP_Config_1 is still occupied by the previous URECV_C function block failed to release, at this time you need to release the recovery of UDP communication resources can be restored to normal; or to avoid the reception process, delete the URECV_C instance. (The design to ensure data consistency, to avoid multiple receiving blocks at the same time using a connection block to receive data, which leads to the received data is not stored to the expected DATA.)
-
When URECV_C uses the UDP_Config_1 connection block to perform the receive action, if it is currently in the process of receiving and has not yet finished receiving the data of the specified length, modify the initial value of URECV_C in the GVS table and perform an incremental download, and then still use the connection block URECV_C to perform the receive action, then it will report an error of 0x80C3, which is due to the fact that modification of the incremental download of the initial value is equivalent to the creation of a new URECV_C instance. Download is equivalent to a new URECV_C receiving block, this time you need to release the recycling UDP communication resources can be restored to normal; or to avoid modifying the initial value of the URECV_C instance in the receiving process. (The design to ensure data consistency, to avoid multiple receiving blocks at the same time using a connection block for receiving data, which leads to the received data is not stored to the expected DATA.)
-
When using UDT as a data block for receiving, pay attention to the default 4-byte alignment of UDT, part of the data in the UDT that is less than four bytes may be complemented with 0 in the compilation stage until the 4-byte alignment is satisfied; if you use the UDP communication block to communicate between the internal Baosky PLCs, you don't need to be concerned about the 4-byte alignment of the UDT, if you communicate with the L2 or a third-party PLC manufacturer. If you communicate with L2 or third-party PLC manufacturers, you need to pay attention to this issue.
If you communicate with L2 or third party PLC manufacturers, you need to pay attention to this issue. * Baosky PLC data storage is in accordance with the small end of the storage, when using UDP function block to receive data, the same is the small end of the byte sequence to receive, if you communicate with third party PLC manufacturers for network, you need to convert the size of the end according to the actual scenario;
- When multiple URECV_C function blocks use the same UDP_Config connection block, there can only be one URECV_C function block receiving data at the same time, so at this time there can only be one receiving function block working properly, and the other will report an error of 80C3; in this scenario, to avoid the use of different priority of the TASK bound to a different URECV_C function block (the URECV_C function block uses the same UDP_Config connection block). _C function blocks use the same UDP_Config connection block), otherwise there will be reception data disorder. If the above URECV_C function blocks do not use the same UDP_Config connection block, binding them to different priority TASKs is not affected.