Y_CA_RotaryKnife_Registration

Parameters

*	Parameter	Data Type	Description	Default
VAR_IN_OUT
B	Master	#19516	A logical reference to the master axis.
B	Knife	#19516	A logical reference to the slave axis.
B	RegistrationData	#19273	Structure containing all information to allow both the CamControl and CamShiftControl to make decisions to run the cam function effectively.
B	ControlData	#19273	Structure containing all information for the circular buffer to operate.
B	BlendData	#28483	Structure containing the information required for engaging, disengaging, ramping in, and ramping out.
B	KnifeParameters	#41215	Structure containing all information about the rotary knife including RampIn, RampOut and Running CamTables
B	MonitoringData	#41216	Structure containing all information about products coming and being processed
VAR_INPUT
B	Enable	BOOL	The function will continue to execute every scan while Enable is held high and there are no errors.	FALSE
B	ClearBuffer	BOOL	Set to TRUE to prevent new products from being registered in the buffer and clear the all items in the buffer	FALSE
V	TestMode	BOOL	Set TRUE to manually provide "ProductTestTrigger"	FALSE
V	TestTrigger	BOOL	When ProductTestMode is TRUE, when this input transitions to TRUE, a simulated product latch is recorded.	FALSE
VAR_OUTPUT
B	Valid	BOOL	Indicates that the function is operating normally and the outputs of the function are valid.
B	Error	BOOL	Set high if an error has occurred during the execution of the function block. This output is cleared when 'Execute' or 'Enable' goes low.
E	ErrorID	UINT	If Error is true, this output provides the Error ID. This output is reset when 'Execute' or 'Enable' goes low.
V	BufferLevel	INT	This output is set to the number of items held in the rotary knifes buffer. This is set to zero when the FB is disabled.
V	ItemsProcessed	UDINT	Number of products that have been processed from the buffer

Notes

Cam tables to be used by this function block can be created in the Motion Tools Cam folder in iCube Engineer, or using the #40878 function block.

Error Description

Refer to the #18337 .

Application Example

Axes Configuration

The master axis typically is set up to be a linear load type with the feed constant set up to indicate the position scale for the master. The master axis could be a servo, or an external encoder. A virtual axis can be used as the master for this application only if the function block is used in test mode. An example of a servo master is shown below.

The knife axis is typically in rotary load mode. For a one knife set up, the position scale set up is as shown below where there is no transmission between motor shaft and load.

Cam table creation for populating BlendData and KnifeParameters inputs:

There are two ways to create cam tables for rotary knife applications.

Automatic

The first method that can be used to create cam tables is by using the Y_CA_RotaryKnifeCamGen function block. The successful execution of the #40878 FB will create three cams. RampIn, Running and RampOut cams are created using straight line, tangent matching and Bezier curve profiles. The IDs for these cams will be loaded into the #28483 structure and this structure can be directly used in the Rotary Knife FB. The KnifeParameters structure is also populated by the function blocks and can be used directly in the Y_CA_RotaryKnife_Registration FB. For details on creating cams based on the Y_CA_RotaryKnifeCamGen function block , please refer to the help page of the function block.

A snapshot of the BlendData generated is shown below. Note that the CamIDs are automatically populated. It is recommended to set the SlaveAbsolute modes to TRUE for all cams.

Custom

The second method to generate cam tables is by using the Cam Motion Tool in iCube Engineer.

If the Cam Tool is used for creating a cam profile, create the ramp in , running and ramp out cams for the nominal product length. Each Cam table can be created separately, or created in one cam program by enabling multiple cams as shown below.

The resulting #19508 element can be used in the #13929 function block to generate CamIDs. Once the three cam profiles have been generated, two inputs (KnifeParameters and BlendData) required by the Y_CA_RotaryKnife_Registration function block must be generated by the user. Define a variable for KnifeParameters input of the Y_CA_ RotaryKnife_Registration function block with the following data elements.

An example of how to calculate the TotalSpeedMatchLength is shown below.

Define a variable for BlendData ( #28483 ) to be used as an input for the Y_CA_RotaryKnife_Registration FB as shown below. It is recommended to set SlaveAbsolute modes of all cams to TRUE.

Registration Data Configuration Example

The Y_AX_ProductBuffer function block is used to manage latch based registration data to be used for product detection on the master axis.

Control Data Configuration Example

Part length = Master cycle

Setting Cam Master Cycle:

Before a cam is engaged using the Y_CA_RotaryKnife_Registration function block, the cam master cycle is not established by the motion engine. Rotary knife applications that require product registration must make adjustments to the cam cycle (shifts) in order to process the first product before motion starts. To initialize the cam master cycle, execute the Y_CA_SetCamMasterCycle function block after the desired running CamTableID has been generated and the knife servo is enabled.

Running the Y_CA_RotaryKnife_Registration function block

Once the setup is complete, servo on the knife axis. Set position of the knife axis to its home position or move it to the defined home position. Please refer to the help content in #40878 to review the various home positions based on the number of knives in the application. The Y_CA_RotaryKnife_Registration function block can be tested in test mode with a test trigger if the product sensor is not wired and ready for use.

Enable the knife axis. Home the knife axis.
Create cam table IDs and populate the BlendData and KnifeParameters structures.
Make sure that the Registration Data and Control Data inputs to the Y_CA_RotaryKnife_Registration function block are populated as described above.
Set the cam master cycle.
Enable the Y_CA_RotaryKnife_Registration function block.
Jog the master axis.
Add master position, slave position, slave parameter 1502 (master shifted position cyclic), MonitoringParameters.CamControlMonitor.CamEngage and CamDisengage, MonitoringParameters.ShiftControlMonitor.Shifting to the logic analyzer.
Trigger the sensor once or use the test trigger once to confirm operation.

Capturing the first part

Make sure that the logic analyzer plots with the above mentioned variables confirms that the first part was cut at the correct distance as specified in the RegistrationData.SensorDistance. (15 units of the master in the example plot below).

A common issue that is encountered on the first part is that the first part is not handled at the correct position on the master axis. It can be seen in the figure shown below how it took 26.28 units of the master for the knife to make a cut. The application was set up with RegistrationData.SensorDistance = 15 units. This means that the cut should have taken place when the master passed 15 units. This irregularity is seen with high speed applications. It can be seen that the CamEngage bit turned on in the previous cycle. However, the slave engaged only in the next cycle. This is because the window for camming was not set up to pull the cam in the same cycle. At higher master speeds , the default window may be insufficient to engage the cam at the right time.

Expand the Cam Window in the BlendData structure as shown below. This will resolve the issue of not triggering the cam in the correct cam cycle.

The shift for the first part is performed with the following parameters:

First correction = -REM(Latch position + RegistrationData.SensorDistance - ControlData.SyncPosition , CamMasterCycle)

MasterDistance = ControlData.SafeEngageDistance.

The MonitoringData.CamEngage bit turns on when logic sees the falling edge of MonitoringData.Shifting and CamState = 0 and RegistrationData.UserPointer <> RegistrationData.StorePointer.

Capturing all other parts

Corrections (shifts) for all parts captured after the first part are calculated by:

All continuous corrections = CamMasterCycle - (Latch(k) - Latch (k - 1))

WithinRange = ControlData.EndSyncPosition to ControlData.StartSyncPosition.

All monitored states should look like the plot shown below.

Last part and Cam Out

In the logic analyzer, make sure that the last cut takes place exactly RegistrationData.SensorDistance units after the last part is detected. This is shown below.

MonitoringData.CamDisengage turns on when (Prm 1502 > ControlData.DecisionPosition) AND (CamState = 3) AND (RegistrationData.UsePointer = RegistrationData.StorePointer).

RegistrationData.UsePointer gets incremented when (MonitoringData.Shifting = FALSE) AND ((Master Position - RegistrationData.BufferNonCyclic[usepointer]) > RegistrationData.ProductAwayDistance).

A possible issue that may arise is when the master axis is running at very high speeds. The MonitoringData.CamDisengage bit may not come on in time for the RampOut cam to be called in time. This will cause an additional cut to take place. One possible solution is to set a the BlendData.RampOutSwitchOverPos to a value higher than 0

Troubleshooting Common Issues

Ramp Out Timing

The ramp out execute command can only happen after the product away distance. This means the product away distance must be less than (RegistrationData.SensorDistance + BlendData.RampOutSwitchOverPosition + window)

Spike in position/torque profile (Usually with higher master velocities)

For high master speeds , if the user sets the cam window as a large value to assist in the engage and disengage process, the user will have to make sure that the speed match regions on the two cams that are transitioning overlap. If they do not overlap, and the window is large, the engage or disengage transition can occur where the profile or velocity slopes do not match. This can lead to discontinuities in motion. An example of such a transition can be seen below. The blue lines vertical represent the speed match area, and the red arrows shows when the ramp out is executed. There is an immediate jump in the graph because the slave is not in sync with the master anymore, and it has to make a sudden change to match the ramp out cam table.

This can be prevented by increasing the speed match end angle of the cam table which will increase the speed match area. In the diagram below, it can be seen that the knife is in sync with the master for a longer distance and when the disengage command is sent, the knife and master axis have matching slopes on their profiles. This allows the knife to smoothly ramp out.