Tracing source of data on PLC-5

[TheWaterboy]

I have registers changing on a PLC-5 and I don't know the source. This was harmless until I tried to use them and found they are being zeroed even though usage shows them not being used. This obviously means another machine is writing to it, but there are many doping that and I need to narrow the field.

I see CSP session tables in the HTML interface which would narrow my manual search, But is there a technique to allow the instant capture of the comm session IP that is triggered by a data value change?
That ability would tell me which machine is making this change.

But how can I reach this raw CSP table data?

 

[James Mcquade]

I would look for the following.

1. MMI terminals
2. HMI programs
3. Other plc's on the network using messaging.

I can't think of any thing else.
I know its not much to go on.

james

 

[Mickey]

If you can post the program, maybe someone can spot something you are over looking.

 

[TheWaterboy]

There must be some place where the received connections communication data (destination, length, etc) are located however briefly. Are you all saying there is no way to see that data?
I would send the file but its huge and many other machines talk to it and I imagine its one of those.

 

[Steve Bailey]

Is it feasible to disconnect the communications cables to the other devices and reconnect them one at a time until you see the data getting zeroed?

Failing that, I expect you would need some sort of sniffer on the communications port. Something like wireshark that could capture and store the packets.

 

[Oceansoul]

You'll need to look in those other PLC machine code. Look for MSG write instructions. They write directly into the registers of the target destination PLC. Unfortunately there is no way to see this in the target PLC. One of the disadvantages of MSG write. I much prefer to see MSG reads.
I.e. your PLC reads the registers it needs from the other PLC, as opposed to the other PLC writing them into your PLC.

 

[Mike_RH]

The data could also be changing due to indirect or indexed addressing within the PLC-5.

 

[TheWaterboy]

The data could also be changing due to indirect or indexed addressing within the PLC-5.

But that should show up as "in use" wouldn't it?

 

[Mickey]

But that should show up as "in use" wouldn't it?

See this post..second to last paragraph. (Note on politics)

http://www.plctalk.net/qanda/showpost.php?p=11350&postcount=3

 

[TheWaterboy]

Ahhh. Gotcha

 

[jdbrandt]

There must be some place where the received connections communication data (destination, length, etc) are located however briefly. Are you all saying there is no way to see that data?
I would send the file but its huge and many other machines talk to it and I imagine its one of those.

If the Data Highway Plus channel(s) are properly configured, you can see the active stations on that Data Highway Channel. At least you would then know which DH+ addresses have access to your PLC, since your PLC would show those stations present.

But, as the other posters have pointed out, this is the shortcoming of a low-bandwidth, highly efficient network like DH+: All that diagnostic stuff is not present.

But, your issue really is more of a program maintenance and overall design discipline issue, in reality.

 

[TheWaterboy]

This is all ethernet, no DH+. The session table on the html page shows all the IP's that are accessing the PLC just like the diagnostic file does for DH+. SO I know its in that PLC somewhere. I was hoping to grab that ethernet data somehow. but I can't find it.

 

[rdrast]

As an aside, this is another reason that I go out of my way to avoid WRITES between two (or more) PLC's. I instantiate virtually all of my PLC to PLC communications with only READ messages. That way others looking at the program can easily see where communications events may be changing internal data.

This requires a bit more attention to making sure that messages are being received (handshaking from master to slave or peer to peer), but it is a small trade off in my opinion.

 

[daba]

"This is all ethernet, no DH+"

Wireshark should be able to tell you which PLC (or PLCs) is writing to the addresses you see changing, as the destination address would be part of the MSG data block.

 

[TheWaterboy]

"This is all ethernet, no DH+"

Wireshark should be able to tell you which PLC (or PLCs) is writing to the addresses you see changing, as the destination address would be part of the MSG data block.

I'll give that a try