Connection errors: L71 & EN2T <--> Wonderware dasabcip

Hey folks,

Just yesterday I upgraded and old L1 processor and its ENBT module with a new L71 20.015 and EN2T 10.00?. The L1 was used for nothing more than data storage. No control. Very little logic (handshaking & such). No IO. A big chunk on the stored data are hundreds of strings used on one specific WW Intouch window.

We had been having an unrelated issue a week before. During the troubleshooting we figured we should update this old L1. All seemed fine when we fired up the L71 yesterday.

This morning when I updated and restarted the Intouch app that reads all this data, the ww dasserver could not connect with either the fast polling or slow polling tropics to this plc. The update was unrelated to either of these access names/topics.

WW tech picked out these lines from the WW logger...
[FONT=&quot]
Encountered following errors while establishing connection for PORT_CIP_000.Prog_Bridge_ENET_Module.Backplane.PLCo[/FONT] [FONT=&quot] STS=0101, ExtSTS=011A: Target Application cannot support any more connections[/FONT]

I tried restarting the WW view app as well as the dasserver. No go. I could see the L71 in RSLinx just fine. I cycled power to the processor chassis. Processor came back up faulted. I had to go online empty and reset the fault (sorry, forgot to write it down). I then downloaded the little bit of logic and data/tag files (which luckily has been saved a few minutes before). I switched the plc to run mode and everything came back ok.

Anybody have a clue what just happened? We never saw anything like this with the L1 and ENBT. They ran for many years. Note that the DASserver config was not changed.

I'm not an expert, but we just had something similar with a Unity PLC. It ran out of sockets (other applications opened sockets but did not properly close them) and could not let anything else communicate. RSLinx might have worked because it already had a socket dedicated to it.

This does not explain your processor fault though, so I might be way off.

About ten years ago, Wonderware's first implentation of DASCIP used a reverse-engineered protocol that could not deal with the memory re-allocation process inside the ControlLogix correctly. If you made an edit or a change to the tag database, eventually DASCIP would write to a physical memory location that had been re-allocated to another purpose and corrupt the ControlLogix program.

Don't discount this possibility. Talk to Wonderware support about your specific data server and its compatibility with modern ControlLogix firmware.

Ken Roach said:

About ten years ago, Wonderware's first implentation of DASCIP used a reverse-engineered protocol that could not deal with the memory re-allocation process inside the ControlLogix correctly. If you made an edit or a change to the tag database, eventually DASCIP would write to a physical memory location that had been re-allocated to another purpose and corrupt the ControlLogix program.

Don't discount this possibility. Talk to Wonderware support about your specific data server and its compatibility with modern ControlLogix firmware.

Click to expand...

Yeah, I have used the ABDASCIP both in 2012 and this year. Both times we had to add a hotfix so that tagname changes would be seen by the server.

The EN2T is twice as fast and supports twice as many connections as the older ENBT. So I don't think the EN2T would be running out of connections if it worked for the ENBT.

You made a big leap there from the L1 to the L71. So it is quite possible that your version of DASABCIP is quite old and might not fully support the newer L7x controllers running on newer firmware.

The latest DASABCIP is v5.0 and the documentation says it supports the L73 using v21 firmware, whereas v4.1 only mentions up to L6x using v17 firmware.

Worth looking into perhaps?

Regards,
George

Thanks fellas. Much appreciated. It has been quite a while since I last updated our DASservers. Stay tuned.

Ken Roach said:

About ten years ago, Wonderware's first implentation of DASCIP used a reverse-engineered protocol that could not deal with the memory re-allocation process inside the ControlLogix correctly. If you made an edit or a change to the tag database, eventually DASCIP would write to a physical memory location that had been re-allocated to another purpose and corrupt the ControlLogix program.

Don't discount this possibility. Talk to Wonderware support about your specific data server and its compatibility with modern ControlLogix firmware.

Click to expand...

This method of using direct memory access was disabled (for good reason) in ControlLogix firmware 20.014+. You may be able to use an earlier version of ControlLogix firmware, but I would try to update WW.

FYI. My DASABCIP server is v 4.1.3. WW readme for that says...

Enhancements in ABCIP DAServer 4.1 SP3

This release of ABCIP DAServer 4.1 SP3 delivers significant enhancements in functionality; an updated version of the DAServer Runtime Components is also being delivered to increase the ABCIP DAServer’s performance. The ABCIP DAServer 4.1 SP3 offers the following new features and enhancements:

Latest versions of ABCIP firmware

The latest versions of Allen-Bradley module firmware available prior to release were verified and tested. This includes version 20.x for the ControlLogix, CompactLogix, GuardLogix and FlexLogix Controllers that support it.