SLC ethernet comm's

[allscott]

Has anyone used one of these?

http://www.prosoft-technology.com/content/view/full/2497

We have several SLC's (mostly 5/04's) in the plant that we would like to upgrade to be able to communicate to an intouch server for basic data gathering purposes. We are not planning any I/O control or anything like that, just want to pull data from the SLC.

The company is intent on using ethernet so DH+ and KTX cards are not an option.

I am also considering a control logix bridge (DH+ to ethernet) but from an installation standpoint it would be much easier to simply install these pro soft cards. None of the PLC's are currently tied together on the DH.

Any recommendation or advice would be appreciated.

 

[Sheldn]

Why don't you upgrade the SLC-5/04 to a 5/05?

 

[allscott]

The DH+ port on the 5/04's is currently used for panelview 600 touchscreens. I would have to upgrade them as well, which is an option but doesn't seem like it would be the most cost effective.

 

[Peter Laing]

The ControlLogix Bridge really works nicely.
If you don't have a need for high speed, then my suggestion is to stick with the 5/04s.
A CL bridge does not need a CL processor. Just a communication card to connect to each network you want to bridge. In your case, a 1756-ENBT for ethernet, and a 1756-DHRIO for DH+. Obviuosly , you need a CL Rack and Power Supply to support them.
The DHRIO has two ports, so you can split up a single DH+ network into two, which will improve performance.
The only downside that I've seen is that the old DOS programming software won't work across the bridge.

Cheers,
PL

 

[Ken Roach]

If the serial port on the 5/04 processors is not already used, I'd recommend the 1761-NET-ENI module.

The Prosoft modules will be faster, but require more configuration and can only transfer N-file registers.

The 1761-NET-ENI will allow program monitoring and upload/download, as well as reading and writing of any data file in the controller.

 

[JesperMP]

You didnt state how many SLCs and PVs that you have.
I guess that at the moment you have physically separate DH+ networks, one for each SLC + PV "pair".
The PVs are probably polling data constantly to update screens and alarms, so each adds a medium-heavy load on the network.
The scenarios you mention about Prosoft or CLX bridge sounds like you are considering to put all SLC and PVs on the same network. That may result in overloading the DH+ network.

If you have only 2-3 SLC + PV "pairs" then I would go for the single DH+ to Ethernet bridge.
If you have more SLCs and/or PVs, I would consider to use a 1761-NET-ENI per SLC.

The DHRIO has two ports, so you can split up a single DH+ network into two, which will improve performance.

That is a good idea.

 

[allscott]

Thanks for the replies.

The 1761-net-eni looks like an interesting option.

How would I go about setting up the communication with Wonderware. Would I need RSLinx running on the Wonderware server?

 

[wildswing]

Thanks for the replies.

The 1761-net-eni looks like an interesting option.

How would I go about setting up the communication with Wonderware. Would I need RSLinx running on the Wonderware server?

I think you'll need WW's ABTCP DAServer. It's available on their web site.

http://www.wonderware.com/Support/MMI/esupport/downloads/esdownload.asp#diData

Sorry for getting a little off topic here, but I'd like to comment on using CLX bridges. We upgraded from Intouch v7.11 and WW's ABKT IOServers on NT boxes with ASA slot KT cards (directly connected to our PLC5s with DH+) to Intouch v9.0 and WW's ABCIP DAServers on XP Pro SP2 boxes and ENBT/DHRIO CLX bridges. We have struggled ever since with slow update times as well as other issues. The CLX DHRIO module does not seem to have the same capacity as a KT card. WW and AB tech are stumped. If I were to do it all over again, I would have bought new PCI slot KT cards. If you want to know more, just search for "stuck bit" or "stuck button".

 

[allscott]

Not off topic at all, these are the kinds of things I would like to know before tackling this. We are moving very little data (along the lines of 10 words per hour per machine) and time is not an issue.