Help - Search - Members - Calendar
Full Version: IO discrete bits getting stuck ON in WW Intouch/AB PLC5 system
Forums.MrPLC.com > PLCs and Supporting Devices > Allen Bradley
wildswing
Hi fellas,

I was sure that I posted this before but could not find it. I appologize for the possible duplication. If you know the whereabouts of my original post, please post a link. Thanks.

Until recently I've been running InTouch v9.0 P2 and DASABCIP v3.0 P1 on XP Pro SP2. Itouch was upgraded to v9.0 P3 last week. My nodes are grouped into pairs, each running the same app. Each Intouch pair talks to a pair of AB PLC5s via one of two a ControlLogix ethernet/dh+ bridges consisting of an ENBT and two DHRIO modules. I have 4 apps, so 4 pairs of Intouch nodes with 4 pairs of PLCs. The 57k DH+ networks are separate although each connects to one of the two DHRIO modules in each of the two bridges. They are still logically separate. The attached picture may help to clarify.

[attachmentid=2425]

6 of 10 HMIs are connected to the same switch. The last 4 are connected to another switch in another part of the facility and the 2 switches are connected with a gig fibre connection. Tag counts in each app range from 1600 to 2400. Our new IT department has declared that all Ethernet is to be V-LANed. The 4 nodes are on a V-LANed switch shared with one general pc and printer. The entire switch to which the 6 are connected is set up for process control ip addresses. Sorry, I'm just learning ethernet networking.

Ocassionaly we find that an IO discrete tag's item (bit in plc) is stuck, that is, is ON all the time where it should be off. The Intouch buttons that activate these tags are set as direct acting. It's as if the initial ON (1) makes it to the PLCs data table but the subsequent OFF (0) gets lost somewhere. I have no idea if this is a WW or AB issue.

The problem began when we upgraded from IT v7.11 with KT card IO servers on NT4 to v9.0 P2 on XP Pro SP2 with DASABCIP 3.0 P1. This never happaned back in the KT car days even though each node polled the two PLCs independanly (redundant and doubled the traffic but it worked fine). We thought the problem was isolated to one particular set of nodes. We knew we had network traffic volume issues with that pair (expanded to 4 IT nodes) that was experiencing the stuck bits.

We changed that Intouch app to read from only one node's DAServer in that group of 4, thereby reducing the DH+ traffic to 1/4 of what it was when each node talked to the PLCs independantly. Not only did that speed up update time significantly but the stuck bit issue became much less frequent but not entirely gone. It still happens every few weeks.

I've gone through this with tech support and have applied their hotfix to ITv9.0 P2 to all my apps and nodes where I added "ForceWriteForDiscreteIOTags=1" to the app's ini file and view's intspt.dll was updated with a new version dated 2/18/2005 3:54 pm. Even then it still happens occassionaly. WW tech has since suggested applying Intouch patch 3, which I did last week, but it happened agian the other day.

We've found a stuck bit on another of the apps so it's not isolated to the 4 node/2 plc system I described earlier.

Is anyone else running into this? How do I figure out what's causing this? Your assistance would be greatly appreciated.

Mickey
QUOTE(Alaric)
I never rely upon the HMI to turn off a bit that should be momentary. I've seen momentary PB bits get stuck on with RSView, CiTect, and Factory Link HMIs. If the bit is supposed to be momentary then the HMI handler subroutine in the PLC is programmed to make sure that the bit gets turned off.




Ditto: With Intellution FIX32 also, below is an example:

Note N22:9/0 is written to by SCADA system, PLC logic resets bit after its use. It does not matter if the SCADA system turns it off

or not ( even though it is programmed to do so )

Firetubes
I've found that the WW DASABCIP is unstable and still need a few more revs to get the bugs out. I agree with Alaric/Micky statement about using the PLC to unlatch the bit. If all your buttons are in a single data file or in a few contiguous words, you can use the COP, FLL, and some search and replace to change all the buttons in the PLC side to be oneshot self-clearing. If they're all over the place, it's a little harder and you will have to do what Micky suggests.

OkiePC
"Stuck Button Syndrome" can happen to any device connected via a communication channel. Always put a timeout and unlatch in the PLC or find some other control type.

Hardwire a real pushbutton if safety is a factor...don't use an HMI/SCADA of any kind.

There have been many posts like yours from about every make and model of PLC/HMI.

wildswing
Hey fellas,

Sorry for blowing the dust off an old thread but, being the OP, I figured I'd provide an update and close the loop.

We finally found a solution. After creating a test Intouch app that simulated double clicking a button (IO discrete tag) I was able to intentionally create "stuck bits". I shipped that off to WW tech support for them to play with. They too were able to recreate the stuck bits.

After countless months of troubleshooting, which included a site visit by my tech contact, WW tech suggested that I change the "MAX CIP connections per channel" settings of the DHRIO module in their DASABCIP server from default of 4 to 1. That did it. No more stuck bits. I thought update time would suffer but it didn't. Case closed.

FYI, I'm told this was the longest open service request in WW tech support history at 3 years and 1 month.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2010 Invision Power Services, Inc.