PLC

The machine’s logic is written in IEC 61131-3 Structured Text. The language is the standard’s; what follows is what is NEV’s own, and what a program that is correct in the language can still get wrong here.

There is one way in. A PLC project is added on PLC, and everything inside it, a program, a global variable list or a struct alike, comes from Add Element on the folder that holds it.

The PLC is what gives permission

Trajectories belong to the motion side. Whether they are allowed belongs to the PLC: the interlocks, the door, the tool changer, coolant and the safety chain are logic you write. Enabling a channel, starting a cycle and holding feed are PLC actions, so a machine that will not start is a question for the logic before it is a question for the program.

Motion is commanded through function blocks

Do not write to the axis or channel structures. Every command goes through a function block from the shipped libraries, on the PLCopen interface: Execute in, and Done, Busy, Error and ErrorID out, with the axis or channel passed as VAR_IN_OUT.

Read the block’s own Busy and Done, never the channel’s status. Channel status is channel-wide and carries no command identity, so logic that derives its own state from it reports an unrelated program’s motion as its own block still working. This is what makes a finished operation appear to run forever.

One command at a time, per channel

A channel holds one command. Wait for a block to answer before submitting the next one to the same channel, or the later command replaces the earlier one and the first is never carried out.

Alarms need their text

A PLC event reaches the operator as words only if the project’s alarm catalogue is deployed with it. Without it the machine still runs and the alarm arrives as a pair of numbers.

Where to go next

• Libraries: the function blocks that ship with the environment.
• Motion & NC: the axes and channels the logic commands.
• Building & Deploying a Project: what compiling produces, and how it reaches a target.