CTU presets changing on their own and other weird events

For a week now, my coworker and I have been troubleshooting a machine which has been displaying some crazy behavior. HMI values were changing on their own. Some of the stations disabled themselves. Never seen anything like this. The first thing we started with was the processor (SLC 5/04), then the PLC power supply, the HMI and all associated wiring back to the PLC has been changed. We then put in a known good appliance 24VDC power supply that powers the rest of the machine with 24VDC. After these things were changed out, some things that were affected before are not displaying the same behavior (counts, stations disabling themselves), but the one thing that is still happening is that some CTU presets are changing on their own. The pass part & total part count was always set to some number that was unreachable in a weeks production much less in a day. It was set at zero for both of these totals. Also, in one of the assembly stations, there is a counter to see 'x' bad parts in a row and throw a fault. Normally these are set at 3 and yesterday I found it at 46.

I'm unsure where to look next. Thinking about changing the chassis/rack.

General Background: The machine has a DC motor to rotate a dial for station indexing. Nests move around 12 stations. There are pneumatic presses and servos on the machine. The machine also has a sibling machine that is working fine built to the same specs so I have something to compare things with.

Looking for any suggestions. Thanks in advance!!!

Well, the good news is that those values aren't changing on their own and it isn't a hardware issue!


The bad news is, now you'll have to track down what exactly is happening here. 3 things spring to mind as possible culprits:


1. Poor programming - it is very possible that some bug in the code is modifying these values for unexpected reasons. In RSLogix 500, do a cross reference on the counter preset that is changing and check anything and everything that might affect that register. This might include some indirect addressing which is more tricky to diagnose. It is also possible that the HMI itself is programmed incorrectly and is sending values to the wrong registers - I've seen this happen with copying and pasting errors.



2. Is there something, anything else on that same network (DH+?)? It could be (and IMHO is likely) that another PLC, HMI or computer is writing values to what it thinks in another node on the network.



3. I know that the operators are probably telling you that it "changed on it's own", but is it possible that they're screwing around with the HMI and not realizing what the consequences of changing some values are?

I was online with the processor yesterday to changed the pass part and total part presets back to something that couldn't be reached in a days production. I did search for the bits that were associated with the station fault preset. I did not do a cross reference. The operators can't change the pass part and total part counts. There is nothing on the HMI to enter that info.

When things were worse, we could watch the HMI totals change on their own around 45 parts. Where that 45 was coming from to impact the program and how it was resetting things, I have no idea. We could not find anything. There is only one operator on 1st shift (which I work).

There is only a PLC and an HMI. DH485. HMI is Automation Direct and has already been changed. All wiring changed. All cables (DH485 to ethernet) changed.

I will cross reference some associated bits and check the HMI as suggested.

Can this system be reached from the internet? Do you have any recently departed employees?

No access to the internet. I'm online at the moment. They are fixing an unrelated issue. Should be up and running soon.

The PLC has an empty DH+ port then?



What's the exact wiring between the HMI and PLC? You mentioned DH485 to Ethernet - is this done with a module? If so do you have a part number and ideally a diagram on how everything is hooked up? There's no such thing as a DH485 to ethernet cable. If it is in fact a module, there might be something on the ethernet network writing to the PLC.

No OPC servers that collect an push data to the CPU?

No servers connected to this machine. The HMI is connected by a RS-485 serial cable that has an RJ-45 male on the other end which is plugged to a female/female ethernet cable adapter that is plugged into the DH485 port. We need the adapter because Automation Direct only makes a 10ft cable and the run back to the PLC is through a seal tite. Total length is around 32feet! Too long maybe?

And the processor is a SLC 5/03 not a 5/04. Had that incorrect. I apologize.

What version of software are you running?
I am aware of an issue with a certain release of the software.

james

RSLogix 500 Version 10.00.00 (CPR 9)

"What's the exact wiring between the HMI and PLC? You mentioned DH485 to Ethernet - is this done with a module? If so do you have a part number and ideally a diagram on how everything is hooked up? There's no such thing as a DH485 to ethernet cable. If it is in fact a module, there might be something on the ethernet network writing to the PLC."

I don't know if you've gotten the jist of my explanation but it is an EA7 HMI, which has automation direct's 15pin to RJ45 cable (3M length). That RJ45 end plugs into a F-to-F RJ45 adapter which has a 22 foot CAT6 cable running through a Seal Tite into the controls box to the DH485 port on the PLC.

How are the pass part and total part signal feed to the PLC?
Are there any sensors involved?
Have any change made to this machine since it was working?

These two machines are close to 10years old. As I explained, there is a sibling machine that is producing identical parts that is working flawless. The last modifications we made to either programming or HMI was maybe last November on both machines. Really simple timing stuff, no changes to functionality or process. The CTU instructions for the display of 'pass parts' or 'total parts' are indexed through the Camco indexer switch and part tracking. That is it. We've examined the switch already. The machine made some adjustments to part tracking that we've adjusted and I've discussed already where it changed presets so that we failed parts for a long time without the operator being alerted but outside of those items....

They've been running the machine for about 2 hours with no issue but that is how yesterday started as well.

What I would try is change your CTU to another C5:xx counter, or replicate it to another CTU counter, that is unused and see if that behaves like it should, or something is changing its preset.

If the second counter works like it should then change the other references in the program THAT MATTER to the new counter. Don't change every reference or write to your counter globally, do them one at a time and make sure each one changed is proper to change.

I'll give it a go and report back. They've had no issues today thankfully.