ControlLogix V15.X and InTouch (FSGateway)

shaunw

Member
Join Date
Nov 2007
Location
Cheshire
Posts
4
Hi All,

While I appreciate the following problem has a lot variables, and as such, we are currently proposing alternative solutions to the end user, should anyone be able to shed any light on what I've experienced I would be most grateful!

I was tasked to carry out some expansion on an existing system provided by another vendor, the system basically consisted of;
  • Multiple redundant ControlLogix L55 V13.X processors (c/w SRM's & CNBR's - Series 'D')
  • Redundant ControlNet network
  • Dual redundant InTouch V9.0 SCADA servers (kinda hot-standby as far as DRaX will allow) using FSGateway 1.5 OPC through RSLinx 2.51 and PCICS cards straight onto ControlNet.
  • Multiple client SCADAs on Ethernet.
Now, while slow, this system did work to an extent. I believe the config not to be upto much, with zero data packing considerations, and excessive tag name lengths (upto 50 chars) for SCADA comms tags, and one of the PLC's had 50+ active connections (this has since been reduced by taking out some of the redundant Produced/Consumed tags).

Taking all this, and more, into consideration, it did sorta work!

Anyway, in order to expand, we need to add more CNBR's into racks already containing CNBR's. Rockwell, in it's infinite wisdom has decided that Series 'D' modules are no longer available, and we could only have Series 'E'. However, this would also mean a full firmware upgrade to redundancy pack V15.X, and an upgrade of RSLogix to V15 in order that we could mix Series 'D' & 'E' in same chassis.

While this was a pain, it went ahead, trouble free, I re-scheduled the network and all fine, expansion installed, all tested, faster, no problems....Until I switched the SCADA back on!

The SCADA would NOT communicate with the PLC's, no modifications had been made to the SCADA or communication paths or the tags, and RSLinx continued to see the whole network.

After a couple of days, and nights, nights with an anxious client on my back, and numerous Wonderware tech support I was advised to drop FSGateway in favour of DASABCIP and install 1756-ENET cards in the racks, which I did, still no joy.

Wonderware tech support arrived on site, immediately said go back to FSGateway, spent two days messing around then left site with it still not working.

I then took the decision to roll-back all AB PLC firmware to redunancy pack V13.x and remove the expansion, re-schedule the network, boot everything up and hey-presto, it all works again!!!

The outcome to date is...

WonderWare do not believe it is their problem and do not intend to investigate, they claim it must be an AB issue.

AB do not believe it to be their problem, and say it is WonderWare who is at fault.

We have currently recommended to the client that in the short term, we fully audit the system and clean up the comms, and long-term, replace ControlNet with redundant Ethernet, and InTouch with RSView.

I just want to know if anyone else has had a similar issue with CLX 15.X and InTouch, and if so, what has been found please.

Any and all help would be appreciated. Thanks.

Shaun
 
Could depend on the version of DASABCIP was being installed. Check the supported versions.

I currently run WW 9.5 using DASABCIP (3.5 I think) via ethernet to ENBT on redundant controllogix V13.

I do recall seeing a technote from WW that listed the supported versions of controllogix and the respective versions of WW DASABCIP.

The one issue that bugs me is that WW DASABCIP driver does not support password protecting controllogix controllers. They are well aware, but have not yet decided on supporting this feature.
 
Thanks Oakley,

Yes we have had both FSGateway and DASABCIP running fine with CLX V13. However, due to Rockwell no longer being able to supply Series 'D' CNBR's, our only option is to upgrade to V15 so that Series 'D' & 'E' cards can be used in same chassis. It's at this point that the comms suffer...

Cheers

Shaun
 
I fully understand your troubles with CNBR/D's vs CNBR/E's. I had to have a conversation with the product manager at Rockwell to have some D's released for our use in a redundant V13 system.



Anyway, did you verify that the version of the DASABCIP driver that you were deploying was in fact validated for use with ControlLogix V15?
 
The DASABCIP was V3.5 SP1, and initially wonderware confirmed it was certified for use with CLX V15. After I informed wonderware that it was not working with our V15.6 (Redundant Firmware) they changed their stance to say it had only been confirmed with V15.5 and it would 'NOT' be tested with 15.6.

Not too helpful!
 
Just as a confirmation test, why not try communicating to a non-redundant system at V15.5. That way you can confirm that the issue is with the WW IO driver.
 

Similar Topics

I'm trying to integrate a Beckhoff IPC with a Controllogix PLC. There is some documentation, on the Beckhoff website, on how to do a PLC-PLC comms...
Replies
0
Views
91
Why does the controllogix redundancy modules use a single mode fiber vs multimode fiber?
Replies
1
Views
103
Hello, I have two 16 point input cards and 1 16 point output card showing module faulted on my IO tree in Logix Designer. The fault code is...
Replies
7
Views
231
Hello, My associate and I are trying to sync up two ControlLogix racks (7-slot chassis) with identical modules. We are able to see the secondary...
Replies
4
Views
216
Trying to setup a message read via Ethernet. I have the path setup as 1, 1, 2, 192.168.66.10 I get an error code 1, ext err 315. I am beating...
Replies
9
Views
253
Back
Top Bottom