The golden rule for the MLX300 PLC programming is to never disable a rung before the AOI has completed and its STS_DN bit turns on.
This report will show some debugging steps of an actual customer situation to determine the cause of a locked up AOI. The routine shown below was simplified, so that it is easier to analyze the issue. Seven rungs were removed between rungs 2 and 3 that executed before the move command on rung 3. Note that the MoveHome[0] command is enabled, but the Sts_AC bit never comes on, which would have indicated that the robot is moving. It was locked up in this state.
Look at Command Queue Array
In some cases, you might not know where the locked up AOI is, so a way to find it is shown in the following sections. In the PLC Controller tags, go to MLX[0].InternalData.Commands, which is the MLX command queue array. It’s possible to queue up to 25 commands max. The current queue shows there are 3 commands “inUse” and “enabled”.
Look at Current Command being Executed
The CommandType in the internal tags shown below indicates the current command being executed. Since the Command Request bit is on, it means the command has not completed yet.
The table below shows a list of all MLX300 AOI commands and their CommandType codes. For this example, the CommandType code is 19 which corresponds to “MLxRobotMoveAxisAbsolute”.
Find the Absolute Move Axis Command that’s Locked Up
You can search for the MLxRobotMoveAxisAbsolute command that’s being executed and is locked up. To do this search, go to the Controller or Local tags double click on the “Data Type” column. After the Data Types are sorted, look for all the tags that are a data type of MLxRobotMoveAxisAbsolute. You can right-click each one of these and choose “Cross Reference” to see where each of these commands are used in ladder. Look for one of these commands that is locked up. For this example, we know it’s on rung 3 in the first picture above of this document.
Analyze the PLC Logix to Determine Why the AOIs are Locked Up
Referring to that section of code again, try to analyze why it is locked up. Almost every time an AOI is locked up, it’s not an issue with that AOI. The issue is the previous AOI didn’t get finished. Starting with rung 1, when the Home push button is pressed (HomePB), the sequence step will be set to 10. On rung 2, if the system state is 3 or idle, the servo power is on, and the sequence step will be set to 90. On rung 3, the Frame Shift will be cleared just in case one was set, and an axis move command will be executed to teach point 0. Note that the Sts_DN bits of these two commands are not turned on, which means the SetFrameShift command didn’t complete and the move command didn’t queue up its motion point. The execution of these AOIs has not started, because they are waiting for a previous AOI in the queue to finish.
Conclusion for Why the AOIs are Locked Up
The reason these AOIs on rung 3 are locked up is because when the HomePB push button is pressed the sequence advances to step 90 and these two AOIs start executing. However, if the HomePB is pressed too long, on the next scan will reset the sequence step to 10 and the two AOIs will be executed again. Note that there are missing steps between rungs 2 and 3 which cause a slight delay for the sequence to advance to step 90. Therefore the first execution of these two commands didn’t get a change to finish before rung 3 becomes disabled. When rung 3 becomes enabled again, the second execution of these commands will wait until previous AOIs are completed, which will never happen.
A solution to this problem is create a new tag called “HomingInProgress”. Latch this tag on step 10 and unlatch it after the homing sequence. Place a “HomingInProgress’ examine off contact right after the HomePB button contact on rung 1 to prevent the step number getting reset during the homing process.
Comments
0 comments
Please sign in to leave a comment.