SLC 5/05 MSG Problem?

Hello,

I've been having a problem with a couple machines for a few days now. They have SLC 5/05 processors. Machine A is not always receiving info from machine B. Machine B has the outputs on, but it appears the information does not always get sent over to Machine A. I have attached a piece of the MSG code. 3 messages in total on Machine B, all going to Machine A. I am wondering if this is a timing issue? Looks like all 3 are set to go at the same time? It appears some of the messages are triggering faster than others. The one I am having problems with is the first msg in the attachment. Any ideas? Should I use timers, or trigger one msg off the next? Should this even be a problem?

Thanks

PFrog said:

Hello,

I've been having a problem with a couple machines for a few days now. They have SLC 5/05 processors. Machine A is not always receiving info from machine B. Machine B has the outputs on, but it appears the information does not always get sent over to Machine A. I have attached a piece of the MSG code. 3 messages in total on Machine B, all going to Machine A. I am wondering if this is a timing issue? Looks like all 3 are set to go at the same time? It appears some of the messages are triggering faster than others. The one I am having problems with is the first msg in the attachment. Any ideas? Should I use timers, or trigger one msg off the next? Should this even be a problem?

ThanksView attachment 31488

Click to expand...

that set up triggers messages as fast as they can.

I usually set up a timer , 1 or 2 seconds as a preset and compare the ACC value to trigger a single message.

I agree; what you're looking at is three instances of the classic "self-retriggering MSG instruction".

The three control bits you're seeing from the first word of the control block are:

/12 Error
/13 Done
/15 Enable

The technique of unconditionally enabling a MSG instruction and then un-latching the /EN bit goes back to an old SLC-5/02 user manual example and lots of people still do it that way.

Because the status bits are unlatched so quickly, watching them online isn't a good way to determine performance.

Instead, set up diagnostic Counters for each of the status bits, so that each /DN and /ER bit is counted separately.

Have a look at the embedded web pages for the SLC-5/05 and see if there are physical media errors showing up on the Ethernet port. You might just have some bad cabling in there.

SLC-5/05 controllers support a varying number of MSG instructions to different devices, so the model of SLC-5/05 will matter. The limits depend on firmware, too, but I think the smallest supported 16 connections. Unless you have a bunch of HMI devices or a bunch of unrelated MSG instructions, these three should be fine.

It looks like the DN bit is taking anywhere from .05 to 6 seconds to trigger. The other messages appear to be having this lag as well. The DN bit would be triggered by the receiving PLC? I'm not really certain on how to troubleshoot this problem... Program files were uploaded and downloaded on this machine (around the same time the problem occurred) so I am wondering if a setting is not correct somewhere. Everything in channel configuration seems to match.

There are other MSG statements going into the receiving machine SLC. I have attached a screen shot of the configuration of it. Wondering if half duplex may cause a problem.

I will try to look at the web pages... I would imagine just typing in the IP address of the unit would get me there.

The problem we have is some things are pulsed and the pulse is no longer present by the time the MSG comes around.

Thanks!

PFrog,
Reread post #2 &#3, what they are saying is that its best to only enable one message instruction at a time. You have all three enabled.

PFrog,

See the attachment. This is how I like to do multiple messages in order to have them execute in an orderly fashion. There are other ways, but this way you can "stack" several in a single rung. Coordinating them one at a time helps prevent overloading the network with bursts of traffic.

Hope this helps.

Thanks Fitz. It does help. I am not certain yet why the delays may be as long as they are (for the MSG DN bits), but I will try breaking up the messages with timers. I'm also going to look at cabling issues as Ken suggested.

What type of results on the embedded web page would point me to bad cabling? Anything specific, or just the collision errors?

Thanks

Ideally you'd get an Ethernet tap or mirror port and look at the traffic with Wireshark, which would tell you a lot about retries and timeouts.

Let's talk about the SLC-5/05 and the rest of the network.

If the SLC is an older one that doesn't support 10/100 MB/s or Auto-Negotiation, then it makes sense that it's in 10 MB Half-Duplex mode. Collisions are just part of life on half-duplex Ethernet. But CRC errors, framing errors, or other non-collision errors aren't.

The "Series C" hardware that supports 10/100 MB/s Ethernet will have "10/100" clearly labeled next to the Ethernet connector.

What kind of switch is the SLC-5/05 connected to ?

Has a lot of Ethernet traffic been added to the network recently ? If there is a lot of multicast or broadcast traffic that can interfere with the SLC's ability to communicate because the Ethernet channel will be busy all the time.

PFrog said:

The problem we have is some things are pulsed and the pulse is no longer present by the time the MSG comes around. View attachment 31489

Thanks!

Click to expand...

You shouldn't rely upon a MSG function to transfer a bit status that is rapidly changing. Messaging will never be fast enough for that method to be reliable. The larger your program becomes, the slower the messaging will become, especially if you also have an HMI connected.

There are also a couple of System bits in the SLC-5/05 that limit the number of messages serviced per sweep. You may need to manipulate these if you plan to do a lot of messaging. The default settings optimize program sweep time over messaging.

Ken Roach said:

Ideally you'd get an Ethernet tap or mirror port and look at the traffic with Wireshark, which would tell you a lot about retries and timeouts.

Let's talk about the SLC-5/05 and the rest of the network.

If the SLC is an older one that doesn't support 10/100 MB/s or Auto-Negotiation, then it makes sense that it's in 10 MB Half-Duplex mode. Collisions are just part of life on half-duplex Ethernet. But CRC errors, framing errors, or other non-collision errors aren't.

The "Series C" hardware that supports 10/100 MB/s Ethernet will have "10/100" clearly labeled next to the Ethernet connector.

What kind of switch is the SLC-5/05 connected to ?

Has a lot of Ethernet traffic been added to the network recently ? If there is a lot of multicast or broadcast traffic that can interfere with the SLC's ability to communicate because the Ethernet channel will be busy all the time.

Click to expand...

It's connected to a centerCOM MR820TRX. the sending plc is a B series and the receiving one is a C series.

There has been no additional equipment added. I am newer at this company so I have no idea what the history is with the equipment. It could have been having problems for a long time.

I will look into the cabling errors next week to see what type are present an I'll also look at the message system bits as Bit_Bucket mentioned.

Thanks for the help, it's appreciated!

Okay an MR820TRX is an old fashioned half-duplex Ethernet hub, so the 10 MB/s half-duplex configuration makes sense.

Because that's a hub, you could plug in your computer and run Wireshark software to capture the data going back and forth between the controllers, and that would tell you something about the timing and about errors and retries.

This does sound like a system that has a bad cable or a failing switch somewhere in it.

Thanks Ken, I'll look into the switch.