Fixed Robot Controller - Encoder Position Latch Period Limitations

 Under construction, quick idea draft, have better content to provide here.

When considering latch period limitations from an application perspective, there are generally 3 things to consider:

1. Latch signal detection and stability
2. Latch data processing by V+
3. Latch data process by ACE Process Manager

#1 is usually not a risk unless there is significant noise or "debounce" issues. Most modern sensors and devices with proper circuit and installation can provide clean rising or falling edge signals to use for latching. The fixed robot controller digital input and FPGA capability to detect and buffer latches much faster than 1ms latch period is sufficient for robot applications. For comparison, this is more likely a risk for fixed automation bottling operation triggering a camera/sensor to inspect every bottle at very fast rates.

#2 needs to consider the time required from when a latch is detected and entered into latch FIFO buffer to when it is extracted for use by the robot. It is necessary to consider the latch period and number of latches the robot must process in a certain time interval. It is necessary to ensure that the robot controller can process latches consistently at the required rate. Inefficient V+ programming such as WHILE loops without delay can waste processor time repeatedly executing code unnecessarily fast. V+ task scheduling can influence how quickly latches can be processed. Some applications have experienced trouble in this area if latch period is <64ms? 48ms?

#3 is a more commonly encountered risk for applications that use ACE Pack Manager (previously PackXpert). as it is necessary to consider additional technical limitations of the complete system (ACE + multiple controllers), which can be easily overlooked. Perhaps the most common is latch period limitations for applications with single part or target instance per latch.

The Process Manager is built to manage product flow of Parts to Targets using defined Processes for specific Part and Target types. It is NOT designed for sequential operations of specific part instance to specific target instance, though this may be achievable with customization. In order to manage product flow for many controllers and many robots it also needs to efficiently manage latch data for detected instances. For example, imagine a packaging system that locates part instances using a camera and picks those parts using 3 i4L-ENET robots. The camera latch is wired to each robot controller. When the process manager triggers a picture, each controller detects a latch, and the process manager V+ belt program will report the latch information to the ACE process manager running on an IPC Application Controller. It takes "some time" to detect and report the latch from controller to PC and ACE to consolidate data from image processing with controller latch data, let's call this "latch processing". Applications with multiple part or target instances per latch usually lead to the robots and belt velocities being the limiting factor, where as applications with a single instance per latch make the "latch processing" time critical. Most ACE to controller communication happens within 250ms. Applications with single instance per latch and a latch period <250ms are at high risk of latch sequence errors.