PanelView Plus Comms

[Jiri Toman]

If it was noise somewhere else in the duct bank, then why would the problem only exist when the PV+ is connected.

That is a good question but I think that the noise could be affecting
the network only when there is a load on the section of DH+
where PV+ is connected.

A-B likes to preach about the need to have at least 6 feet of cable between devices. If the cable between the PV+ and the SLC 5/04 in our panel is less than 6 feet in lenght, could we be getting some reflections in the signal?? Just graspong at straws, but I'll throw that out there.....

I usually leave 10 Feet coiled up in the panel just to be on the safe side.

I also had a recent problem with Remote I/O which works approximately the same way as DH+. We had blue hose in a duct next to cables feeding
plating rectifiers and that was enough to cause a problem. We had to
re-route the blue hose.

I suggest that you run a parallel blue hose cable next to the duct outside and away from anything that might produce noise.
Then connect this cable instead of the one inside the duct.
Blue hose is not that expensive and you can always re-use it.
This way you will eliminate one possible source of noise.
If that does not help I suggest that you lower your line end termination resistors to 75 Ohms.

There is another way of reducing the traffic on the DH+.
Instead of polling your RSView tags you could
do unsolicited messages and send the data up based on an event.
However I do think that your problem is hardware related.

 

[Jiri Toman]

Hey Tom,
Did you manage to solve the problem?
If the answer is yes, what was it?

 

[Tom Jenkins]

We're still fighting it. The progress is slowed by the 1,500 miles between us and the problem.

WE have our distributor's tech support working on it now. THere seems to be a general feeling that we have missed a firmware update somewhere along the line - that is our next line of attack.

 

[Tom Jenkins]

The AB tech support gurus have come back stating that none of the recent firmware upgrades affect DH+ communications. Their opinion is that the problem is due to an addresss conflict. Since we pulled the addresses for both the PanelView and the SLC off a list of unused adresses, I'm more than a little skeptical. I will ask Scott to confirm just for general principal, though.

A-B is anal retentive about having no less than 6 feet of cable between any two devices (and they count a terminal block as a device!). We may be one or two feet short, so that may be the problem.

I am leaning towards the PanelView Plus hammering the network and not having adequate timing control on the internal comm divers. The description Scott provided of intermittent Red X's on various devices is very like the phenomenon I see on our DH-485 network at the same plant. This network has several PanelView 550's and PLCs. When the 550's are connected I see the same thing. When I pull the plug on them, I can see every PLC in the network without problem.

I'll let you know the final resolution. I wonder If A-B will pay for my plane ticket - I didn't get the golf balls!

 

[JesperMP]

When bypassing the PV+ on the DH+ network we simply remove one jumper between the Blower PLC and the PV+ and connect the exiting DH+ leg to the Blower PLC DH+.

I dont understand this description.
To disconnect the PV+ it should be sufficient to remove the DH+ plug (with the DH+ cable(s) in it).
Do you use daisy-chain connections or trunkline/dropline ?

If it was noise somewhere else in the duct bank, then why would the problem only exist when the PV+ is connected.

Everything seems to indicate that the PV+ is responsible for the problems in one way or the other. It could also be that the PV+ generates noise (not regular traffic) on the network.

 

[Rick Densing]

What happens when you connect the PV+ w/o the application running, as was suggested before? This would prove if it is the PV hammering the net.

 

[PhilipW]

Gents,

Just another longshot here:

Has anyone put a scope on the network and looked at the signal? It is important to check from blue to clear AND blue/clear to ground.

AND then check the signal at a range of locations along the whole length of the network.

What you should see is reasonably square edges, over couple of volts and differentially symetric between both lines. This is why is is important to check from line to ground.

Some years ago I ran into a very wierd problem on a DH+ network that was working ok, but adding a node to PLC edit with causing all manner of problems. It was a very busy network with about 8 PLC and 3 SCADA nodes in a dairy application. Everything appeared to be working until we tried to online edit one of the PLC's. Then everything would slow down and most times the edit session would fail.

Using the scope we eventually tracked it down to a line to ground short somewhere along a 150m run of the cable at the far end of the network.

What can happen with DH+ is that the error correcting is strong enough to keep the system running in the face of a lot of signal degradation, but adding just another extra load onto the network will tip if over the edge.

Something like this is possibly the problem you guys are having.

 

[Tom Jenkins]

Update

Scott has done more testing on the system at Pocatello using the PanelView Plus on DH+. It is pretty obvious that the problem is not addressing or cabling, but rather a problem with the comm driver in the PanelView Plus.

When the PanelView Plus or the SLC are disconnected, the PanelView Plus kept running, the SCADA DH+ serial link tied in, and then the PanelView Plus and SLC re-connected, the network goes down.

When the PanelView Plus application is stopped, PanelView Plus or the SLC are disconnected, the SCADA DH+ serial link tied in, and then the PanelView Plus and SLC re-connected, and then the PanelView Plus application re-started, the network functions properly.

Scott speculates, and I concur, that the PanelView Plus comm buffer backs up with a big bunch of pending transactions when the application is running but can't connect. When the PanelView Plus re-connects with the DH+ it hammers the network with so many transactions that it brings the whole thing to its knees.

As far as we can tell the network doesn't ever recover, possibly because the crash causes the PanelView Plus comm driver to continue storing more pending transactions in the buffer and it never stops hammering teh DH+ link.

Any ideas, or suggestions?

 

[akreel]

Add another COMM port or RIO scanner, so that the Panelview can once again have its own private network?

The Panelview Plus terminals run RSView ME. Is there some version of RSLinx running on it? Can the Panelview Plus act as an OPC server, or request OPC topics? If so, you might be able to reconfigure your HMI tags to use OPC, rather than direct DH+ communication. By doing that, you MAY be able to further restrict the traffic without causing communication faults, because OPC has some of its own data packing and scheduling tricks. I haven't used a Plus terminal, yet, so I'm not quite sure what they're capable of.

AK

 

[Ken Roach]

You could solve this problem conclusively with a DH+ analyzer.

I use an SST 5136-SD card hosted inside an old Dolch ruggedized PC. An oscilloscope helps a lot, too.

That analyzer will tell you how much traffic is coming and going from each node. It will allow you to know, not just guess, what effect on network loading the PV+ and the RSView32 system are having.

I recently used it to great effect determining that just two nodes on a 15-node network were experiencing timeouts. We found a bit of conductive debris inside the DH+ connector at one of those nodes.... and the performance went from 10 timeouts/sec to no timeouts in 20 minutes.

RA Network Services engineers have these tools, too. Somebody should pull the trigger and order one up.

 

[Tom Jenkins]

Somebody should pull the trigger and order one up.

My feeling is that "somebody" should be Allen Bradley - we pay for support, after all. It is not reasonable to expect a user to buy that kind of tool for at best infrequent or more likely one time use!

I have sent the same info from above to our distributor, and I'll let you what kind of support we get.

 

[Jiri Toman]

here is the question

You could solve this problem conclusively with a DH+ analyzer.

FrontLine test equipment Inc. is a Company that produces the
analyzer software for DH+. I am not sure if this sofware is used in conjunction with the SST card that Ken mentioned or if you could use it with an existing 1784-PCMK card in your lap top.
If you could use it with your existing PCMK card then it might not be that expensive. If your DH+ produces un-acknowledged / incomplete messages or if there are many DLE NAK's and DLE ENQ's being sent, you will know that you have some sort of noise introduced into the network.
However if you have a situation that you describe, with many outstanding messages, I am not sure how the analyzer will be able to tell?
It might give you a running count of messages sent and received and
how many messages are being sent per second but how will you
be able to tell what is normal and what isn't?
It seems to me that Ken's scenario is different than the one you describe.

 

[Ken Roach]

By "order one up", I mean "order up an RA network services engineer". If course I wouldn't recommend buying an analyzer and learning to use it just to solve one problem.

If this does turn out to be a firmware or driver defect in the PanelView, I presume that Rockwell will absorb some of the labor cost.

The SST software samples DH+ traffic over a specified interval (usually 10 seconds or so). If you plug in the PV+ with its running application during one of those intervals, you should see a large increase in the number of messages from that station number if your hypothesis about a "buffer backup" is correct.

The feature I find neatest about the SST card is that there is a test point on the card where you can hook up the trigger input of your oscilloscope. The SST card turns on that test point (and the green LED on the card) whenever there is traffic from a specified node on the network.

This lets you compare visually the traffic from each node, (just by watching the flashing LED) and also lets you capture the difference in amplitude and waveform of the transmissions of each specific node.

 

[Tom Jenkins]

Well, it looks like this one may FINALLY be working. Scott downloaded new firmware last week, and downloaded a new configuration with some minor changes in bit addressing. It looks like the comm link is now behaving properly. I'll want to have a few more months on it before I'm 100% convinced, though!

Thanks to all for the suggestions, and thanks to our local Allen Bradley distributor, who kept beating on Rockwell Software until they finally came through with a working solution.

Did you ever think "It shouldn't be this hard"?

 

[Michelle]

increase bandwidth for comms ?

I have seen that you list this as resolved.

I have seen a similiar situation with a PV and SLC 5/05 and PC all on ethernet, and the network going down. I cant remember if it was PV or PV+.

Anyway, the slc handles one communication command per scan of ladder, by default. Changing it to handle all commands available to it, resolved the issue that I have seen. This will increase scan time. Here is the rockwell kb that explains it.

At www.ab.com, select support - online support - kb

G54059311 - Setting the Overhead Time Slice or
​

Increasing Processor Bandwidth for Comms