7.15.14 Create UDP Communication Resource and Send Data
USEND_C (Create UDP Communication Resource and Send Data)
Functionality
-
The USEND_C system library enables asynchronous creation of UDP communication resources and data transmission
-
This instruction executes asynchronously with the following capabilities:
- Configure and create UDP communication resources
- Release of current communication resources by sending data recovery through existing communication resources
-
UDP Resource Configuration
- Configure local IP/port in UDP_CONFIG block
- Set CONT parameter to true to initiate resource creation
-
Data Transmission
- After successful resource creation (status 0x7001), REQ rising edge triggers transmission:
- Bind data to DATA block
- Specify length via LEN parameter:
- LEN=0: Send entire DATA block (max 2048 bytes)
- STRING type: Default 82-byte transmission when LEN=0
- UDT type: Partial transmission supported (0 < LEN < DATA size)
- Transmission locking
- New REQ edges ignored during active transmission
- Buffer cleared if resources lost mid-transmission
-
Resource Management
- Set CONT=false to release UDP resources
Parameter Specifications
| Parameter | Declaration | Data Type | Description |
|---|---|---|---|
| REQ | Input | BOOL | Transmission trigger (rising edge) |
| CONT | Input | BOOL | Resource control: ● false: Release resources ● true: Create resources |
| LEN | Input | UDINT | Transmission length: ● 0: Full DATA block (≤2048B) ● Non-zero: Specified length (≤2048B & ≤DATA size) |
| CONFIG | InOut | UDP_CONFIG | Configuration instance |
| DATA | InOut | ANY_TYPE | Transmission buffer (supports basic types, arrays, strings, UDTs) |
| ADDR | InOut | ADDR_PARAM | Target IP/port configuration |
| DONE | Output | BOOL | Completion status: ● false: Inactive/processing ● true: Success (1-cycle pulse) |
| BUSY | Output | BOOL | Transmission state: ● false: Idle/complete ● true: Active |
| ERROR | Output | BOOL | Error indicator: ● false: Normal ● true: Operation failed |
| STATUS | Output | WORD | Detailed status code |
Status Codes
Normal Operation
| CODE (16#) | Description |
|---|---|
| 0000 | Not invoked |
| 0001 | Creating socket |
| 7000 | No task is activated, REQ detects a rising edge but CONT is false |
| 7001 | Socket created |
| 7005 | Data transmission |
| 7007 | Resources released |
| 7009 | Transmission success |
Error Conditions
| CODE (16#) | Description |
|---|---|
| 8080 | Socket creation failed (resource exhausted) |
| 8081 | The IP address is incorrect due to the following reasons : the IP address corresponding to LocalAddress does not exist, i.e., the 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 the Ethernet protocol; the current value of the LocalAddress is 0.0.0.0; |
| 8082 | Setting IP address and port number reusability errors |
| 8083 | The bind address and port number fail with the socket, mainly because the current port is already occupied by another service |
| 80A1 | The communication resource has not been created successfully, when Cont is set to true and REQ receives a rising edge, the user activates the send function but the specified connection has not been established at this time, error 80A1 is reported. |
| 80A3 | The current ADDR_PARAM parameter used by USEND_C is empty, i.e., the IP address or port is 0 |
| 80A4 | Empty data block |
| 80A5 | There are three reasons for this: the parameter LEN is greater than 2048, the value of LEN is greater than the size of the data block, LEN is 0 and the data block size is greater than 2048 |
| 80A9 | Transmission failure |
| 80AC | Async queue failure |
| 80C3 | The UDP communication resources corresponding to the current UDPConfig have already been used by other USEND_C blocks |
| 80C4 | Resources released |
| 80C5 | Destination unreachable |
| 80C6 | No broadcast mode is set, but data is sent to the broadcast address. |
Critical Implementation Notes
-
The req receives a rising edge before triggering a send action, and the send data function only triggers a new send action and sends new data when the req recognizes a new rising edge after all sends are successful;
-
When the current USEND_C uses the UDP_Config_1 function block to perform a send action, if it is currently in the process of sending and has not yet completed a send action, the USEND_C function block will be deleted, and a new USEND_C_2 will be created to also use the UDP_Config_1 block to perform a send action, and then an error of 0x80C3 will be reported. The current connection block UDP_Config_1 is still occupied by the previous USEND_C function block can not be released, at this time you need to disconnect or reset the connection can be restored to normal; or to avoid in the process of sending, delete the USEND_C instance. (This design is to ensure data consistency and avoid multiple senders using one connection block to send data at the same time, which may result in the data sent not meeting the expectation.)
-
When USEND_C uses UDP_Config_1 connection block for sending action, if it is currently in the process of sending and has not yet completed a sending action, modify the initial value of USEND_C in the GVS table and carry out an incremental download, and then still use the sending block USEND_C to carry out the receiving action, then an error of 0x80C3 will be reported, which is due to the fact that modification of the initial value of the incremental download is equivalent to the creation of a new USEND_C. Download is equivalent to a new USEND_C send block, this time you need to recover the UDP communication resources can be restored to normal; or to avoid in the process of sending, modify the initial value of USEND_C instance. (The design to ensure data consistency, to avoid multiple sending blocks at the same time using a connection block to send data, which leads to the received data is not stored to the expected DATA.)
-
When using UDT as a data block for sending, pay attention to the default 4-byte alignment of UDT, part of the data in UDT that is less than four bytes may be complemented with 0 in the compilation stage until it meets the 4-byte alignment of the row; if you use the UDP communication block to communicate between the internal Baosky PLCs, you don't need to be concerned about the UDT 4-byte alignment of the matter, if you communicate with the L2 or third-party PLC manufacturers, you 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. The data storage of Tianhang PLC is in accordance with the small end storage, and when you use the UDP function block to send the data, the same small end byte sequence is used to send, if you communicate with third party PLC manufacturers, you need to convert the size of the end according to the actual scenarios;
-
When multiple USEND_C function blocks use the same UDP_Config function block, there can only be one USEND_C function block sending data at the same time, so at this time there can only be one sending function block working properly, and the other will report an error of 80C3; in this scenario, avoid using different priority TASK bindings for different USEND_C function blocks (which USEND_C function blocks use the same UDP_C function block). _C function blocks use the same UDP_Config function block, otherwise there will be sending data disorder. If the above USEND_C function blocks do not use the same UDP_Config block, binding them to different priority TASKs is not affected.