MSG problems.

backflow · Oct 23, 2014

We have a slc 505. It has about 12 msg instructions. The fiber on our DF1 ring got cut by a contractor. Got the fiber backup and 6 of the msg are now erroring out with a time out error. We checked the fiber and it all looks good. The msg are all right together as in order. There are about 5 that worked then 9 that don't then about 5 that do. It is always the same ones. Some are writes and some are reads. There is one msg to a plc that works the the next to msg the same plc do not. We have rebooted the plc and the same problem same msgs error out. Any ideas?

Ken Roach · Oct 23, 2014

The sequence of events as describes still seems to point to damaged fiber.

Do you have a Diagnostics File defined for Channel 0 ? That will give you some statistics that will tell you if there are timeouts, or corrupted data, or something else going on.

rguimond · Oct 24, 2014

backflow said:
We have a slc 505. It has about 12 msg instructions. The fiber on our DF1 ring got cut by a contractor. Got the fiber backup and 6 of the msg are now erroring out with a time out error. We checked the fiber and it all looks good. The msg are all right together as in order. There are about 5 that worked then 9 that don't then about 5 that do. It is always the same ones. Some are writes and some are reads. There is one msg to a plc that works the the next to msg the same plc do not. We have rebooted the plc and the same problem same msgs error out. Any ideas?

Is it possible for you to slow the triggering rate of the MSG commands? You didn't mention how fast they're triggered. Are they all triggered at once, or are the cascaded?

Sometimes, slowing the firing rate down to something like 50-100ms will allow all MSG to complete.

I agree with Ken that the cut is probably the root cause. The repair may not be perfect

Bit_Bucket_07 · Oct 24, 2014

I agree with what has been said thus far. If it worked prior to the fiber damage, then it should work now. That said, I wouldn't attempt to execute 12 MSG instructions without some logical restrictions to prevent all of them from executing simultaneously.

backflow · Oct 24, 2014

Sorry l did not put the firing info in. That is very important. The status of the other plc has to.be good. If the plc in question can not see the other one it will not fire. The next one is a timer. Every 3 sec. one msg will fire.

rguimond · Oct 24, 2014

backflow said:
Sorry l did not put the firing info in. That is very important. The status of the other plc has to.be good. If the plc in question can not see the other one it will not fire. The next one is a timer. Every 3 sec. one msg will fire.

Are you saying that one MSG ERror will stop the next MSG from firing? If this is the case, won't that stop everything from firing?

The following 2 rungs show what I do when firing multiple messages. This is only a two-message routine, but the same logic works well for multiple messages. Basically, fire the first MSG on the first pass, and fire the next message after the first one is TO, ER or DN.

SOR BST XIC S:1/15 NXB XIC MG9:1/DN NXB XIC MG9:1/TO NXB XIC MG9:1/ER BND BST OTU MG9:1/EN NXB MSG MG9:0 Read 500CPU Local MultiHop( SLC:1->ENET:"192.168.9.194" ) N7:20 N7:11 RI40:18 1 33 192 BND EOR
SOR BST XIC MG9:0/DN NXB XIC MG9:0/TO NXB XIC MG9:0/ER BND BST OTU MG9:0/EN NXB MSG MG9:1 Write 500CPU Local MultiHop( SLC:1->ENET:"192.168.9.194" ) N7:30 N7:12 RI40:19 1 33 32 BND EOR

backflow · Oct 24, 2014

The er or dn to fire the next one is what Rockwell has suggested. My boss will not let me change it because it has worked for years and he says somthing else is wrong.

Here is my thought. The fiber all looks good but the splice of the fiber has degraded just to the point that it is a little slower. What I would like to do is turn off all MSGs. Clear the ERs and then turn one on at a time. We also may need to make a longer time between each one. Once we get it working to make the boss happy make it so that the next MSGs will not fire until there is a ER or DN on the one that is fired.

rguimond · Oct 24, 2014

Sometimes it's easier to ask for forgiveness than for permission...

backflow · Oct 24, 2014

rguimond said:
Sometimes it's easier to ask for forgiveness than for permission...

Yes it is. Part of the problem is my boss did what I do now. We are also a water utility and this plc use to be what I will call the brains of the system when he did it. He is afraid that we may cause problems if we change it. The problem is I have to make some changes to trouble shoot it.

backflow · Oct 24, 2014

Ken Roach said:
The sequence of events as describes still seems to point to damaged fiber.

Do you have a Diagnostics File defined for Channel 0 ? That will give you some statistics that will tell you if there are timeouts, or corrupted data, or something else going on.

There is a status file. Is there some other file that I need to look and or make?

backflow · Oct 24, 2014

rguimond said:
Sometimes it's easier to ask for forgiveness than for permission...

Yes it is. Part of the problem is my boss did what I do now. We are also a water utility and this plc use to be what I will call the brains of the system when he did it. He is afraid that we may cause problems if we change it. The problem is I have to make some changes to trouble shoot it.

rguimond · Oct 24, 2014

Would you be able to post a copy of the .rss file?

backflow · Oct 24, 2014

rguimond · Oct 24, 2014

You have to rename the .rss extension to .zip. You don't have to "zip" the file, just rename it.

backflow · Oct 24, 2014

here it is.

MSG problems.

backflow

Member

Ken Roach

Lifetime Supporting Member + Moderator

rguimond

Lifetime Supporting Member

Bit_Bucket_07

Member

backflow

Member

rguimond

Lifetime Supporting Member

backflow

Member

rguimond

Lifetime Supporting Member

backflow

Member

backflow

Member

backflow

Member

rguimond

Lifetime Supporting Member

backflow

Member

rguimond

Lifetime Supporting Member

backflow

Member

Similar Topics