Registration with PLCopen Example Project
The attached KAS project contains a Registration example used on a real machine. It is a two axis program that uses PLCopen motion functions. It will not work with the simulator because the MC_TouchProbe function block uses the position capture engine of an AKD drive to provide a latched position. No variables need to be mapped to onboard I/O and everything can be run from the built in Control Panel. For offline reference there is a write-up inside of the KAS project included as comments in the ProgramDescription program. The first axis in the program represents a rotary knife that will make one cut per revolution. The second axis is for material unwind that feeds material under the knife to be cut. The material contains registration marks spaced out at set intervals to ensure the cuts are at the desired point even if the material stretches, shrinks, or if your commanded gear ratio is not exact.
Step by Step Instructions to run Demo Program
-First open the control panel.
-Once program is running, press the Enable button.
-Have the option to press the Home Knife and Home Unwind buttons to zero each axis position
-Swtich the Run/Stop switch to start a geared relationship and give a velocity command to the master knife axis
-Press the Start Registration button to start capturing latched positions, calculating offsets, and commanding superimposed moves
Program Steps Explained
I have helped multiple customers implement registration adjustments for packaging machines. They typically have three steps, first to capture the latched position of where an axis when a sensor reads a registration mark. Then we have to calculate the desired offset distance, as we have to decide if we need to make a positive or negative adjustment and possibly convert units as we might latch a position on one axis but make an adjustment on a different axis that has different user units. Lastly, we have to command a move for the calculated offset, which we typically use the MC_MoveSuperImp function block because it will not cancel any active velocity, gear, or cam moves but instead apply the offset immediately on top of any currently active move functions. Below are screenshots from the attached demo program that contains these three steps.
In the first network of the Registration program, the TriggerRef structure is setup for use with the MC_TouchProbe function block. In this example, we choose to use the first fast input with capture engine 0 on the AKD drive to wire in our sensor. We also choose to capture our position on the rising edge of this input. Last, we select that the sensor is wired into the first AKD drive on our EtherCAT network.
The second network of the Registration program contains the MC_TouchProbe function block. This returns a latched position of the master knife axis every time a registration mark is seen. We have logic to automatically recall the function when a new mark is seen, so we will be ready to capture the next one. This is tied to the position latching engine on our AKD drives so it will be much more accurate than reading the position at the EtherCAT update rate.
In network 3 we calculate the desired offset move for the unwind axis. Sometimes the registration adjustment will be made on the same axis where the position is latched (in our example the knife) but we are assuming that it is easier to make adjustments on the material unwind axis and that the knife mechanics are harder to accel/decel. We first take the difference of the latched position from an expected position to have a base error amount. Our knife user units are 1 per rev of our motor, we compare the error calulation to normalizie it between -.5 and .5. It does not make sense to make an adjustment greater than half of a revoution in which case we will go the opposite direction. We than convert the offset from Knife units to Unwind units, in our example a 10 to 1 ratio based on the different units for each axis.
A MC_MoveSuperImp function block in network 4 of the Registration program. Logic could be added to delay the calling of this move so that it will not be done during a certain window of the master move (such as while the knife is in contact with the material it is cutting). Also, if the master velocity is variable might want to add a multiplier to the velocity of the super imposed move to ensure it will complete before the next registration mark is seen.
When troubleshooting issues with registration, I have found it is easiest to implement these three steps one at a time. First, add the MC_TouchProbe function and make sure that you are seeing similar latched positions (or distances between consecutive latched positions) so that you do not have any issues with your sensor or mechanics. If you are not reliably seeing the registration mark each cycle then you will not be able to move onto the next steps.
Once you confirm that you are not missing any registration marks (and are not seeing any false or extra marks) you can work on calculating the correct offset. This can seem obvious but I have seen many customers get this calculation wrong by switching positive or negative signs in the wrong places. They think with a certain error offset they have to make a positive correction move, but they really need to make a negative one so their corrective moves actually make their machine accuracy worse.
Then, once you are certain you are calculating the correct offset move, you can add code to apply it to an axis. You can use the built in scope to make sure that these adjustments are applied before you see the next move, or else you can have issues with compounding your error. If you cannot complete the move fast enough, there is nothing wrong with only calculating an offset move for every other or every third product mark and ignoring the others to make sure you have time to finish your adjustments. It might take longer when first starting a process to start hitting the desired mark exactly, but you should find a good equilibrium adjustment point instead of jumping all over the place this way.
This demo program also contains a program called Main which contains functions to enable each axis, read the current position, start the Geared relationship between a Knife and Unwind axis, and give a Velocity move to the Master Knife axis. MC_GearIn setup normal relationship between a knife and material unwind axis (10 to 1 based on user units for each axis) in network 9 of the program Main. In an ideal world without materials that can stretch or shrink, we could calculate an ideal gear ratio and not have to apply registration adjustments. Many programs will use an MC_CamIn function instead and/or use a virtual master axis and have both the Knife and Unwind servo axes be slaves.
Then, in network 10 of the Main program, MC_MoveVelocity commands a constant velocity move to the master Knife axis, which results in both axis moving at the same rate on our standard demo systems. If you look at the user units for each axis, the Knife has 1 units per rev and the unwind axis 10 units per rev hence the 10 to 1 ratio for the gearing function.