Waiting for inputs

In many applications involving communication with an external controller device, the project must wait for an input signal from the controller before proceeding. Depending on the type of communication, you can use one of several methods of waiting for an input signal.

When using the PROFINET and EtherNet/IP protocols, it is recommended to use event-driven triggering with Quick Comm. This method is more efficient than creating a loop because it does not require any steps to be added to the flowchart. For more information on triggering with Quick Comm, see the Set Quick Comm to trigger acquisition automatically subsection of the Procedure for communicating with controllers section in Chapter 41: Quick Comm protocol and PROFINET and EtherNet/IP steps.

You can wait for a trigger signal by creating a polling loop, which consists of a Readers step, followed by a Break step and a Halt step set to Wait. Adding this delay prevents the CPU from busy waiting (repeatedly checking without a delay) for a signal that will not arrive for at least a certain amount of time. This method of waiting for an input signal is typically used with the ModbusReader step, the IOReader step, the SerialPortReader step, and the NetworkReader step. For information on polling loops and how to set them up, see the Using a PLC trigger without Quick Comm subsection of the Triggering section in Chapter 28: Acquisition.

When communicating with robot controllers from the supported manufacturers listed in the Robots page of the Platform Configuration dialog, use the RobotWait step to pause the flowchart while waiting for a robot controller request. The project proceeds to the next step in the flowchart once it receives a request. For more information on the RobotWait step and how to use it, see the Procedure for using the RobotWait step section in Chapter 45: Robot steps. For other robot controller manufacturers, you can wait for inputs using the polling loop method, described earlier in this section.

With some Readers steps, you can set a finite timeout value. The project will wait for the specified amount of time, and if it reaches the end of the timeout period without receiving a signal, it will proceed to the next step. A Result flag will indicate whether a timeout occurred. This method can be used to avoid waiting too long in the case of errors or unexpected events (for example, an incomplete read when using the SerialPortReader step).