I have an application where there are two traction rollers moving a PVC sheet by a fixed traveling distance. At the same time, there is an aluminum foil with printed marks. The aluminum foil is sealed with the PVC. An ACOPOS P3 is in charge of moving the traction rollers when the sealing stations are open. In the ideal world, when I move the PVC+Aluminum foil the same distance between marks (period), the mark is detected in the same position on every cycle. But in the real world, due to mechanic issues there is a small drift in the position of the mark that I need to correct.
I’m using the MC_BR_TouchProbe with the following settings:
Mode = mcTP_MODE_SHIFT_FROM_EXPECTED
Period = Distance between marks
UseFirstTriggerPosition = TRUE
Once the mark is placed manually where we need it and the process started, the MC_BR_TouchProbe detects the first trigger but has the following behavior:
The second mark comes and it is detected in a different position, then the function calculates an error.
In the next cycle I can apply a correction based on the calulated error. In this example I increase the traveling distance to get the mark closer to the expected value. Here, my error should be “corrected” so in the next cycle I should come back to the theorical period.
Because I changed the traveling distance with a correction, my expected value is misplaced for the cycle after.
How can I make the MC_BR_TouchProbe function update the expected value based on the corrections I did? I was reading there is a parameter called UpdatePeriod but I couldn’t find more information of what it does.
Has anybody used it before? Would it correct the calculation of the expected value in my application? My application is slow, I do 26 cycles per minute, so it means I have plenty of time between movements with the ACOPOS to send changes.
If I understand your explanation correctly, the print marks on the film are not 100% equidistant. This means that, over a longer period of time, your period length deviates slightly from the theoretical period length. For this to work, you need to change the mode from “mcTP_MODE_SHIFT_FROM_EXPECTED” to “mcTP_MODE_SHIFT_FROM_RESULT.” And, of course, make the window large enough.
After all, in principle, you want to achieve the following: The touch probe simply detects the print marks and provides you with their exact positions. Positioning takes place completely independently of this. While the axis is positioning or waiting at a standstill (sealing), the touch probe waits again for the next mark. With this, you don’t need to change the period length.
To clarify the requirements of my application: the logic assumes that the registration marks are equidistant and that the cycle period equals the physical mark-to-mark pitch.
The main goal is to correct position drift caused by mechanical factors (material stretch/slippage, backlash, jerks) and keep the registration mark continuously centered relative to the product cut/seal point.
The issue I’m facing with mcTP_MODE_SHIFT_FROM_RESULT is that I don’t have a stable anchor point. Without a fixed reference point per cycle, the correction becomes floating and drifts over time.
In other applications, you might have independent control over the printed material and the underlying substrate, but here both materials move together. The only way to adjust the mark position is by modifying the traveling distance of the traction rollers for both materials simultaneously.
I considered letting the MC_BR_TouchProbe capture the first expected value as a result and then switching the function mode to use the expected value as an input, allowing me to modify it as needed after applying corrections. However, it seems the function does not accept changes to the expected value input while it remains enabled. To apply the new value, you have to disable and re-enable the block.
Thank you in advance for your help and suggestions.
