MSG problems.

[rguimond]

Two MSG are fired at the same time - See Rungs 363 & 384. They fire when S:67/8 is true AND T4:0.ACC = 25. It doesnt look like the sequence the MSG fire in make a difference, so I would change one of the "25" to "23". This could be the problem.

Although it won't cause a performance issue, the MSG description on Rung 342 is incorrect - it is actually writing to RTU-7 (not 6)

Is there a good reason behind writing and then reading from RTU-3 and RTU-7, but reading from and then writing to all the other RTUs? I'm not saying that's your problem, but it would make the logic easier to follow if all the MSG instructions followed a specific sequence.

 

[backflow]

As you can see there is a lot of problems with it. I have only been work here for.one year. So I cannot tell you why it is the way it is. Some of the data goes threw two or three rtu/plc before it gets to were it needs to be. I will look at what you see and see if that fixes the problem.

 

[rguimond]

Yeah, it looks a bit complicated. If changing the value to "23" doesn't work, I would start by drawing a "map" of the MSG to give you a visual representation of what's going on. Is there a remote PLC at each location? If so, do these PLCs read and write to other PLCs?

 

[rguimond]

Monitoring S:67 & S:68 words will show you which nodes are off-line. To do this, click on "Processor Status" (on the left),select "Binary" from the "Radix" pull-down menu and scroll down to S:67 will show you which Channel 0 nodes are active.

 

[backflow]

Thank you for looking at it. After you pointed out the firing at the same time I went over all the program and looked at the firing and the timing. Here is what I come up with.

If I look at sequencer timer it is set for 56 seconds. This should give 2 seconds or more time (2.24sec) for each MSG.

As I looked closer there are a lot that are only one second. All of them are ones that we are getting time out errors in. Now not all the errors have 1 second. There is two that fires at the same time. These are also ones that are in Error. And there are 3 that have 2 seconds of the MSG errors.

Here is my suggestion to fix this sequencing. Chang the sequencing timer to around 75 Sec. After this change retiming of the MSG to fire every 3 seconds.

If this make the program work then change the program so that only one fires at a time and the next one can not fire until it ER or DN.

I have looked at the monitoring in the processor status. All the plc are on line but one and it is turned of for a reason. That MSG does not fire at all.

"Is there a good reason behind writing and then reading from RTU-3 and RTU-7, but reading from and then writing to all the other RTUs? I'm not saying that's your problem, but it would make the logic easier to follow if all the MSG instructions followed a specific sequence. " I am sure that there is a good reason what it is I can not tell you. I do agree that this needs to be redone and made so that it can be read a lot easier.

 

[Firejo]

I’d pull the master PLC out and put in RSLinx setup as a DF1 half duplex master with all of the remote nodes programmed in. See what Linx comes up with. If it’s a problem with your programming Linx should be able to see all of the remotes. If it’s a problem with the fiber Linx will struggle as well. DF1 half duplex has always had an issue with one node failing causing others to fail (it’s complicated but I’ve been seeing it for 15+ years now). If you don’t see all of the nodes and/or if some “come and go” then I would reconfigure linx so that you communicate with one node at a time. Set it up with node 1 only and see if it communicates and move on through each node. I’m guessing that you’ll find one or two nodes that don’t come up. Then you will have a place to start looking.
Look at the basics first (the communications path) and then go from there. One of the things I do is tech support for industrial automation communications and 9 times out of 10 it’s something simple especially when it was working before something changed (the fiber got cut). It doesn’t make sense to me to have to change the logic because a fiber connection was broken then repaired. I think you still have a communications path issue.

 

[backflow]

Thank you. I will look into this. One question we had is how to ping in df1. This sounds like pinging
somewhat. We asked Rockwell if ther was a way to ping and they said no.

 

[Ken Roach]

I think I submitted a quote to your managers about five years ago for investigating and improving this program.

The communication channel Diagnostic Files are defined on the General tab of the Channel Configuration dialog. Neither Channel 0 nor Channel 1 has one defined, which is why when you click on the Channel Status icon, you get a "No Diagnostic File Defined for this Channel".

You have to create data files offline, so you could designate two Integer data files (20 and 21 are available, for example) to hold that data. The formatted diagnostic counters would then appear in the Channel Status window and also be accessible in the data table.

There isn't strictly a DF1 equivalent of "PING".

You can send a Poll Command from a software device (the contents are DLE ENQ STN CRC ) and the device designated as the Station number should respond with an Acknowledge packet.

When RSLinx Classic is the DF1 Master and does a browse it uses first the Poll Command and then a command called "List Identity" to learn the device types and names of the controllers it encounters.

DF1 Polling Master in "Standard" mode performs a "Polling List" cycle where it polls all the devices in the Priority and Normal polling lists in order.

For diagnostic purposes, you could disable all the MSG instructions and just let the Master poll... it will do so just as fast as it gets responses (plus that 2 ms delay configured in the Channel 0 System tab).

If this were my system, I would at least move all the MSG instructions into a separate subroutine, or separate out the logic for each pump station so it's not all just one big long LAD2 routine with text headers to separate the sections.