ifm AL1432 ISDU Reads: Release the CoE Request Channel by Reading the Response

An ifm AL1432 can finish an IO-Link parameter operation while its CoE request channel remains occupied. Polling a completed status is only the middle step. The documented transaction ends by reading and evaluating the Response Buffer, which releases the channel for the next request.

This article follows AL1432 operating instructions 11489157/02, February 2024. It describes a synthetic read-only ISDU operation carried through CoE, not a production parameter change or executed PLC test. The command-buffer write below requests a sensor read; it is not an ISDU write to the sensor.

Keep the three address layers separate

First identify the EtherCAT master and the AL1432’s fixed slave address. Beckhoff’s FB_EcCoeSdoReadEx reference defines nSlaveAddr as that fixed EtherCAT slave address. It is not the IO-Link port number.

Next select the AL1432 CoE object: port 1 uses 0x3100, port 2 uses 0x3101, through port 8 at 0x3107. Within the chosen object, subindex 1 is Command Buffer, 2 is Status, and 3 is Response Buffer. Finally, the command bytes contain the desired sensor’s ISDU index and subindex.

Use the AL1432 object directory and buffer mappings, pages 63–65, rather than copying the earlier function-input table into runnable PLC code. That earlier table mixes port-style addressing with CoE inputs. Verify the installed ESI, firmware and object datatypes before implementing the actual function blocks.

Serialize a request through its release step

Section 9.2.12.2 defines this sequence:

1. Write the command bytes to the selected port’s Command Buffer. Processing starts and the request channel becomes blocked.
2. Poll Status. 0xFF means processing is still pending; a completed status advances to response handling.
3. Read and evaluate Response Buffer. This read releases the request channel, after which another command can execute.

The manual allows one CoE command request at a time and identifies overlapping requests with SDO abort 0x06090030. Use one serialized request owner across the master unless exact firmware documentation establishes a less restrictive supported scope. Separate port objects do not by themselves authorize concurrent requests.

A PLC function block becoming nonbusy establishes completion of that CoE access, not completion of the whole ISDU transaction. A successful status read that returns pending still requires another status observation. A successful status read that returns complete still requires the response read.

Construct a diagnostic read without guessing a structure layout

For a hypothetical read of sensor index 0x1234, subindex 0x02, the five command bytes are:

offset 0: 00  read command
 offset 1: 34  index least-significant byte
 offset 2: 12  index most-significant byte
 offset 3: 02  sensor subindex
 offset 4: 00  no write-data bytes

This index is illustrative, not a recommendation to access a real sensor object. Select a documented harmless readable object from the actual sensor’s IODD for commissioning. Do not place 0x1234 into the CoE nIndex; the outer object remains the selected AL1432 port command object.

The object directory lists the Status subindex as UINT16, while the response header begins with a one-byte status. Preserve that distinction and the installed directory’s transfer size. The response mapping places status at byte 0, a zero byte at 1, payload length at 2, and payload from byte 3.

Interpret transport and device results independently

The documented completed statuses distinguish success without data, success with data, error without data and error with data. For error-with-data, the response carries an IO-Link error code and additional code. Successful CoE transport does not turn that returned device error into a successful parameter read.

Use the returned byte count, such as Beckhoff’s cbRead, to validate that the header and declared payload are available within the receive buffer. Check the declared length before decoding values or error bytes. Do not treat unused buffer capacity as received response data, or substitute a zero-filled stale buffer after a failed CoE read.

If a command write or response access has an uncertain outcome, retain the current transaction state and diagnostics. Do not blindly submit a second command as a universal recovery action. The required recovery depends on the device’s observed channel state and supported procedure.

Test the missing-release failure directly

In a proposed isolated fixture, complete the first harmless read through status polling but intentionally withhold the response read. Observe the blocked channel rather than assuming it is free. Then perform the documented response read and verify that a subsequent harmless request can proceed.

Also exercise pending status, device-error response and transport failure separately. Preserve the master identity, port object, ISDU address, each access result and final response bytes. No hardware exchange was performed here. The acceptance record should show the release boundary, not merely two successful function-block calls.