Replace a Studio 5000 AOI with a CODESYS function block

What the function block gives you

A function block is a program organization unit in IEC 61131-3, usable in any of the standard's five languages. You declare it once, then instantiate it. Every instance keeps its own copy of the block's internal variables between calls, so the state of one axis never touches another. The task that runs your program calls the block once per cycle. That single fact is what makes one-shot rungs translate differently, as the example below works through. Where you place the call in the task chain changes what the block sees each cycle, so trace the PLC execution order across task layers once before you trust the translation.

What you need before you write code

Three documents, and without all three you stop:

• The AOI definition: the logic itself if the project includes it, or at minimum the parameter list with data types and the read or write direction of each.
• The jog command for the AZD-AEP from the driver communication documentation: which data item starts the jog, which value means idle, which feedback confirms motion.
• The tag mapping from the supplier's Studio 5000 example, which shows how the AOI parameters line up with driver data.

The supplier's jog example is written for Studio 5000, and the AZD-AEP speaks EtherNet/IP, so the same data items are visible to CODESYS. Being able to read and write a data item does not identify it as the jog command. The command and its idle value come from the documentation or the AOI logic. If your package has neither, request both from the supplier's support channel before you write anything that can move the slide.

Rebuild the AOI in six steps

1. Write the interface down first. Open the AOI definition and list every Input, Output and InOut parameter with its data type. Mark each one read, written or both, and note the driver data item behind it. With only an example project and no AOI logic, stop at this step until the supplier sends the definition.
2. Create the block and mirror the interface. One FUNCTION_BLOCK, with VAR_INPUT, VAR_OUTPUT and VAR_IN_OUT sections that match the AOI parameters one for one. Give every parameter that Studio 5000 set at configuration time a default value in its declaration.
3. Translate the logic one rung at a time. Keep the sequence and the interlocks in the same order. Every rung that fires once per request gets an R_TRIG instance declared inside the block and called every cycle.
4. Keep the driver mapping in its own layer. A separate block, or a clearly bounded section, that moves the outputs to the AZD-AEP data items named in the documentation and reads the documented feedback back. This layer is where the idle value is written on release.
5. Instantiate once per axis. One instance variable per axis, each called every cycle from the same task. If the axis count changes while the machine runs, create function block instances dynamically instead.
6. Carry over stop, reset and fault handling. Take these from the AOI logic and the driver documentation, with the drive's fault and status feedback wired to outputs you can watch.

Example: one jog tap through a 10 ms task

This is the translation most rebuilds get wrong, so work it with numbers.

Inputs, with their sources:

• Task cycle time: 10 ms, read from the task settings in your project. Yours may be 5 ms or 20 ms; the arithmetic here uses 10 ms.
• Operator tap on the jog input: 200 ms, a deliberate press on a pendant button.
• Behavior to reproduce, from the AOI logic: one jog command write per press, and the documented idle value written when the input falls.

The rule in words: the task calls the block once per cycle, so the calls during one tap equal the tap length divided by the cycle time. An R_TRIG output is TRUE on the one call that sees the input change from FALSE to TRUE, and FALSE on every call after. Code guarded by that edge runs once per tap. Code that tracks the input runs on every call.

The arithmetic:

• 200 ms / 10 ms = 20 calls while the button is held.
• With the R_TRIG guard: 1 of those 20 calls writes the jog command.
• Without it: all 20 calls write the command, and any counter or step number inside the block advances 20 times per tap.

Decision: an action the AOI fires once per request gets an R_TRIG in front of it. One write per tap is the signature to look for later in the watch table. The release path stays plain: the code that writes the idle value when the button is released must look at the input level on every cycle, with no edge guard.

Check the rebuild with the motor unable to move

Run every check below with the amplifier enable off and the slide guarded.

• At rest, the command output sits at the documented idle value.
• One tap produces exactly one command write, the signature from the example, and the documented feedback changes after it.
• Release produces the documented stop response within the next cycles.
• A simulated drive fault clears only through the path the AOI used.
• After a warm restart or a fresh download, no jog request is latched: the instance starts at the idle value.

Force the jog input true and false from the watch table to walk every transition without touching the pendant; how CoDeSys forcing works in the PLC cycle covers the rules a forced value follows. If nothing in the watch view changes at all, check whether the CODESYS runtime is running or stopped before you debug logic that may be fine. Only then enable the amplifier and make the first live moves with the machine's commissioning controls.

When the jog still misbehaves

• Reads work but nothing moves: the mapping layer writes nothing, or writes a data item that is not the documented jog command. Compare the idle and command values against the manual.
• Jogs but does not stop: the release path is missing, or it writes the wrong idle value.
• One tap fires the command many times: the R_TRIG guard is missing, or the block is called from two places.
• Works after a download, then sticks or dies: the instance was reinitialized, or a retained variable did not return to idle.

Recommendation: Rebuild the jog AOI as one function block with the driver mapping in its own layer, guard every once-per-request action with an R_TRIG, and accept the block only when the watch table shows one command write per 200 ms tap at a 10 ms cycle with the amplifier off. If the AOI logic or the documented jog command for the AZD-AEP cannot be obtained, stop before the motor can move and request both from the supplier.

A notice screen for the same cell

Once the axis jogs from CODESYS, the cell usually wants a screen operators read on the way past: shift targets, changeover steps, safety notices. That screen is separate from the control logic. Our shop-floor displays run on 12 to 36 V DC, play content offline or run your own Android app, and carry an IP65 rating on the front face.

Questions