Troubleshooting with RSLogix 5000... can't find how a value is written.

I'm troubleshooting a customer's machine, and I've been racking my brain trying to figure out an answer to a question of where a value is being written to a tag.

The customer's machine has an "N2" printer hooked up to this box making machine. They powered up the machine the other morning and the HMI no longer displayed the N2 printer (with all of it's set-up parameters). It displayed an N1 printer. They don't have an N1 printer. The customer has the RSLogix 5000 file, as well as the Panelview 700 file. I downloaded and installed version 17.01 on an XP virtual machine, and loaded the Panelview Plus 700 file (version 7) on my FactoryView Studio ME, version 9, to re-load the programs and then troubleshoot the issues.

The N2 printer did not show up. So, I found the screen with the object that displays the printer name and looked at the tag-name. Then I looked in the PLC program and found the tag and checked where it was used in the program. In all the cross-reference locations, the function was EQU... where the value of the DINT was compared. I could not find anywhere where the value was written.... just compared.

So, I figured it must be coming from the HMI. So I checked the tag browser in the HMI and the only location that tag was being used was for the display object that I was referencing. I just can't figure it out and I need some more experienced eyes to look.

I'm a independent tech... so I need to know a little about a lot of legacy equipment... from Siemens to Automation Direct. I'm not able to focus on one software package long enough to really build expertise. The RSLogix 5000 is fairly new to me. I had it in school, about 10 years ago, but just got to purchase my own copy about a month ago. I have a couple of customers who have SLC's, so I've spent much more time in Logix 500. I figure the answer is simple... but I just can't figure out where to look.

Attached are some great pics to get things started. I won't go back on-site until I have something figured out. It's an 90 min. drive, and I've got good coffee here at home.

Any thoughts?

As a general rule, don't trust the "Find" feature in RSLogix 5000. In 500, it works fine. In RSLogix 5000, use the tag cross reference. The find feature has so many bells and whistles, that even if you get them all ringing the way you want, you still might not find everything you expect.

BTW... if anyone wants to look at the file, let me know. I'd rather email it than post it. It's version 17.01. I'm hoping to learn something good from this issue.

Someone may have committed the sin of the undocumented "write" message. If you have other PLCs or even a computer set up with an ODBC connection or something, you could be writing to that tag from any device that can see the PLC on the OT network. If it wasn't documented, it might be a real pain to track down where the write is coming from. However, the maintenance and engineering people at the location might be able to offer suggestions as to other devices that are related to the process, and those would be the first places to check. Focus on PLCs first, then any industrial computers that are involved.

LoganB said:

Someone may have committed the sin of the undocumented "write" message. If you have other PLCs or even a computer set up with an ODBC connection or something, you could be writing to that tag from any device that can see the PLC on the OT network. If it wasn't documented, it might be a real pain to track down where the write is coming from.

Click to expand...

I thought of that at the end of the night, last night. So I looked for devices that could do that. The printer has a separate panel ...there is some remote IO, and servo drives for the printer. The remote IO was communicating with the PLC. I'm just thinking about that remote IO as I write this... I wonder if there is a bit that is activating the printer selection by writing a bit to the PLC. Hmmm... it would still need a rung to do that.

you can email a copy to me if you like ... I'll treat it in confidence ... you can find my email address by clicking the link below my signature ...

A controller that's old enough to be running v17 firmware is probably also old enough to have an exhausted battery, and might have re-loaded from a nonvolatile memory source (generally a CF card) that had the incorrect printer type value in that tag.

You can't tell the status of the battery from an offline file, but it should be straightforward to ask a person at the facility to look at the BAT indicator LED. It will either be OFF or solid red (depleted battery).

LoganB said:

Someone may have committed the sin of the undocumented "write" message. If you have other PLCs or even a computer set up with an ODBC connection or something, you could be writing to that tag from any device that can see the PLC on the OT network. If it wasn't documented, it might be a real pain to track down where the write is coming from. However, the maintenance and engineering people at the location might be able to offer suggestions as to other devices that are related to the process, and those would be the first places to check. Focus on PLCs first, then any industrial computers that are involved.

Click to expand...

Ken Roach said:

A controller that's old enough to be running v17 firmware is probably also old enough to have an exhausted battery, and might have re-loaded from a nonvolatile memory source (generally a CF card) that had the incorrect printer type value in that tag.

You can't tell the status of the battery from an offline file, but it should be straightforward to ask a person at the facility to look at the BAT indicator LED. It will either be OFF or solid red (depleted battery).

Click to expand...

Ken... when the other tech called me about a PLC issue (which he can't address), that was my very first thought. The battery died, and I'll re-load the program onto the PLC and go home before lunch. This CompactLogix did not have a batter LED lit (see attached pic).

Ken....

But you gave me another idea. The compactflash card was gone, and there was a theory that a disgruntled ex-employee took it. So one of my tasks was to load the program onto the PLC, put a new CF in, and copy the program to the CF. I'm still a little fuzzy with my Logix5000 programming, but I suppose the program itself could be the source of the "2" in that DINT. But.... I downloaded the file (with the "2", as you see it in my pictures) and the PLC changed the value to a "1" when I went online, which makes me think there is something else affecting the value. BTW, this was the original problem I was asked to solve.... the printer choice was wrong, and the CF was missing from the PLC. I did re-boot the PLC without loading the program on the CF. I was trying to find what was causing the "2" that was on the file I downloaded, to be changed to a "1" in either run, or remote run.

There was a side-issue I was dealing with yesterday... my XP VM was unbelievably slow, and as one of the symptoms, had a hard time staying online. I researched it and found my AVAST software on my host OS was the culprit. But the UI wouldn't load, and I couldn't "uninstall" the program for whatever reason, so I couldn't apply the remedy. This morning, the first thing I did was fix that issue so my XP would run at least a faster version of slow. (Thank goodness the FactoryView is on a separate Windows 7 VM)

I bring that up because I'm wondering what affect that slowness had in troubleshooting.... I still don't know why I downloaded the program with a "2", and it was changed to a "1" while running. To me, that sounds like some logic in the program.

Have you tried manually changing the value from 1 to 2 while online just to verify it's immediately set back to a 1?

Ok... I went back to the HMI and I found something. I figure the value MUST be written by the Panelview. Look at the picture. These are the HMI tags. In the description it says if the tag = 1, the OEM scrolls and selects the printer. I figure the OEM uses a password to get a screen that shows that field. I just need to think of how to find where the field is and then figure out how to manipulate the value.

As a side note, the business and the machine mfg. had a huge disagreement over the terms of the purchase contract. There is no support from the mfg. I have opinions, but my job is to keep my customers up and running.

I assume BoxMaker is a plc and GlobalPrinterModel is a Controller Tag in the PLC.

Can you not find it and cross reference, if it comes up with a result saying it is written by logic, go there, if no detructive results come up, then it's generally written elsewhere, likely by the HMI.

You can use the "find" tool in the HMI software as well. Hit Cntrl+F and type "PrinterModel" or "PrinterOption". It will search all the displays and show you any place that this tag is referenced.

Control F didn't work, but I did find the "Find" in the tools menu and I'm working through a list of results ....as I start another pot of coffee.

I also just saw Ron Beaufort's offer to look at the files, so I sent him the PLC and zipped HMI files.

I believe Cntrl+F in the HMI software only works as a shortcut if you have a display open already and it's actively highlighted.

The more you know... *rainbow star*