Wonderware DASMBSERIAL comm failures

I'm working with a customer these next few days troubleshooting a bunch of Wonderware issues. There are numerous comm issues, unused tags, false alarms, etc. They are using both DASMBSerial and DASABCIP drivers to talk to a wide variety of controllers. The MBSerial is used to communicate with a bunch of Eurotherm temperature controllers. Someone had setup a bunch of alarm tags that look at each device with the item reference: $SYS$Status. If I watch the alarm log, this tag will change state every few minutes. Similarly, the SMC log shows "PLC poll message timed out on port COM9, revoking message" and then it immediately comes back.

PC is Windows XP. WW is 10.1. DASABCIP is v4.0 (which I am upgrading to 5). DASMBSerial is v2.

I haven't used the DASMBSerial driver before so I am looking for some guidance as to what these intermittent drop-outs could be from.

I can't help you offhand with the DASMBSerial I/O server but I'd like to give you a heads up on the DASABCIP upgrade. 5.0 will require the newer license file (ArchestrA.lic) and will not license with the "classic" WWSuite.lic. If you are under support I believe your WW distributor should be able to give you a new license file but if you aren't your mileage may vary.

Can you increase the timeout setting in the System Management Console for DASMBSerial?

bjh said:

I can't help you offhand with the DASMBSerial I/O server but I'd like to give you a heads up on the DASABCIP upgrade. 5.0 will require the newer license file (ArchestrA.lic) and will not license with the "classic" WWSuite.lic. If you are under support I believe your WW distributor should be able to give you a new license file but if you aren't your mileage may vary.

Can you increase the timeout setting in the System Management Console for DASMBSerial?

Click to expand...

Yes, I'm aware of the newer license requirement, and I did install their updated license files, so they're all set with that.

The only thing I changed, so far, with the timeouts is under the DASMBSerial configuration for each comm port, "Read Interval timeout" was 1000ms and I made it 2000ms. I have no idea if this will help but I did look at all their topics and these temperature controllers are all being polled at 5000ms, so a 2000ms timeout seems perfectly OK.

There already is a 15 second reply timeout and a 500sec transaction timeout. I'm really hoping it's not one of those that is getting tripped.

I'm really curious what the $Sys$Status is actually looking at! Any idea which timeout it might be referencing?

What do you make of this?
There are about 30 disconnected and 30 connected all within the same second.
At the same timestamp, the WW alarm logger showed the Main PLC offline/online, which is one of the PLCs under the DASABCIP.

68164047 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164048 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164049 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164050 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164051 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164052 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164053 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164054 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" disconnected
68164055 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected
68164056 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected
68164057 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected
68164058 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected
68164059 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected
68164060 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected
68164061 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected
68164062 3/6/2017 4:02:47 PM 4924 5660 Info INTSPT Node "localhost" connected

ryangriggs said:

Could this be a flaky Ethernet connection due to bad cabling/switching hardware?

Click to expand...

Very possible. I noticed a bunch of things in the windows Event log that was showing the e1qexpress disconnect for over a minute before it would reconnect. The easiest first step was to replace the ethernet cable, so we did. I didn't see the error pop up the remainder of the day, but that's when I noticed this same-second blip in the SMC's log.

I noticed that the 12 devices under the one COMM port were staggered, and I understand this is to prevent overlap because of the serial communications; however, they had them staggered such as: 5000ms, 5100ms, 5200ms.... and so on. So occasionally you have several that try to hit at the same time. I changed these to 5000, 5101, 5207, 5313, and so on. Yes they will still bump every once in a blue moon, but so far I don't see the errors we were seeing with the original update rates.
Too bad the DA server won't allow you to trigger the next group upon completion of the prior group. I don't know how else you can make serial communications flawless when dealing with multiple devices.