I am writing this article, and sharing it with PLCGurus.NET members and readers so that I can share my experience with a seemingly undocumented or variation on a supposedly corrected bug by Rockwell Automation in its Studio 5000 programming software (v29).
The bug renders built-in base instructions (i.e., XIC, XIO, OTE) appearing as UNKNOWN (UNK) in the logic editor. I should mention, before I get into all of the details, that there is an existing Rockwell Technote: 866333 if you are fortunate enough to have a support agreement that addresses a close variation on the issue I discovered, however, the technote indicates that the issue existing in version 24 and has since been corrected in version 29…guess what Rockwell…your anomaly still exists!
If you’ve encountered this issue or a similar issue, keep reading to see exactly how this anomaly presented itself and what I had to do to get out of it.
First a little background info…
I was called in by my employer last weekend to make changes to an assembly dial for automotive parts. At one of the first stations of the assembly dial, there is a bearing press that inserts a bearing and pushes it into the part using a servo motor with a probe on the end of it.
Because of a problem with the part diameter the probe jammed into a part and when the servo retracted it lifted the part off the table. When the part came free from the probe the impact broke a fixture critical to the press operation. Of course, we had no spare, but manufacturing engineering did find a way to push the bearings in before loading the dial, they just required some programming changes to bypass that station on the dial but complete the rest of the operations.
I didn’t know when the new fixture was going to arrive, so I decided to program a toggle button on the operators HMI to give the operator the ability to select the use the bearing station on the dial. This of course has nothing to do with the issue I encountered, just explains what I was up to when it happened, now I’ll try and explain the pertinent details leading up to this strange UNK Instruction event.
Details leading up to the UNK anomaly…
The PLC is a 1769-L36ERMS Compact GuardLogix 5370 and the HMI is a Proface PS5711W and I am using Logix Designer 29.00.01 on my laptop.
I started by going online using a recent copy of the program I had, correlation was required. I backed up the program before and after I went online with the processor. I uploaded a copy of the Proface program and added a toggle button to the display where I thought it was appropriate. At this point, I have to mention that the maintenance crew welded the fixture back together.
They were not sure how long it was going to last so I continued to work on the bypass, so I didn’t get called back when it broke again at 3AM the next morning. This is only relevant because the rest of the programming had to be done with online edits while the dial was in operation. I created the new tags in the PLC and saved a new L5K file which I imported into the Proface program.
I then downloaded the HMI program with no issue. I tested the HMI button to make sure that the bit was changing in the PLC program and it was. I then added a rung of logic with only an AOI instruction the equipment vendor made called “Toggle”, identical to the other HMI buttons used in the program.
I hit the “Finalize All Edits in Program” as I always do, and this is when the problems started. I could not assemble edits as the were 3 program warnings and 38 programming errors. The errors were on 2 rungs of logic in a different routine, part of a different program, but in the same task I made the edits in. Here is what the rungs looked like:
The rungs were not in edit mode, they were green. I opened a back-up of the program and found the 2 rungs this happened to are
At this point I am a little nervous, I have a proper back-up of the file that was in the machine but downloading is the last option as there are 12 servo motors on the machine and I have had issues with losing the home position on the motors after downloading (completely different topic, maybe for a follow up article) also, I am currently in operation. I opened a back-up file to see what the rungs looked like on the back-up, here is a pic of the same rung as it should have looked:
As you can see every instruction in the rung is still there but has been changed to an unknown instruction except for TEST_01 XIC. This is important to note as both of the corrupt rungs had instructions using this TEST_01 bit which must have been put in by the equipment manufacturer during commissioning, I will explain more on the relevance of this later on.
How I fixed the immediate issue…
- I copied the 2 rungs from the back-up file and inserted them below the corrupt rungs. I marked the corrupt rungs for deletion.
- I tried to Finalize all but no go, errors. I stepped through the process with one of the inserted rungs: Verify, Accept, Test, Finalize and it worked.
- To get rid of the corrupt rungs I had to put the rung in edit mode, delete all the UNK instructions, add instructions that were harmless to the program operation and step through Verify, Accept, Test, Finalize.
- After the edits were accepted, I could delete the rung with no issues.
- After I had this straightened out, I completed the rest of my program edits with no further issue.
So what happened…Rockwell to the rescue…or so I thought?
I did some research to try and figure out what caused this and found there is a lot of info and advise on chat sites that I do not trust, here are my opinions and advice if you come across this issue.
- The file in the processor is not corrupt, it is a Software / Program glitch with Logix Designer. I know this as my robot continued to get signals instructions from the 2 corrupt rungs.
- I would not delete the corrupt rungs without first replacing the logic in additional rungs. I have read a suggestion in a forum I came across to delete the rungs with the UNK instructions and completely I disagree. First, you are going to have difficulty deleting the rungs as I explained earlier but I feel you will be deleting the good logic still held in the processor.
- Remember that TEST_01 XIC instruction? I believe this is the culprit. I found this Rockwell Technote: 866333.
- In studio version 24 when you upload a file where a Program Scoped Tag controlled a Controller Scoped tag UNK instructions were a result of program corruption which was fixed in v.24.02 and 29. This is not that exact same scenario, but, that TEST_01 XIC instruction that the equipment vendor made for troubleshooting and left in the logic, was a Program Scoped Tag. Coincidence? I think not, I would not have even checked this out if it weren’t for coming across that publication, something to keep in mind when your quickly adding that but to assist you in troubleshooting and it defaults to a Program Scoped Tag.
- If all else fails and you do not trust downloading a back-up file to fix your problems, try a complete upload to a new file first. The corruption does not occur in the processor and therefore should not be there when a new file is generated directly from the processor. Being able to extract a complete file from the processor (in Logix Designer v.21 and up) has helped me out in more then a few occasions.
If this happens to you, good luck. I hope these this article helps you out, please leave comments, I will do my best to respond.
I am an Electrical Engineering Technologist working for a large Tier 2 automotive parts manufacturing company in Ontario, Canada. I have over 10 years in the field of automation and work primarily with Rockwell Automation controllers.