ControlWave -> BSAP IP -> Kepware Slow Update

[kudave88]

We have an iFix scada using a Kepware BSAP driver to talk to a Bristol Babcock ControlWave PLC. Values take ~11 min to update. Scan times in iFix and Kepware are 5 sec or less. I created a test OPC item in the Kepware OPC Quick Client with a scan rate of 250 msec and also takes 11min to update. I'm leaning toward something in the PLC that would cause this delay in communication, however I am not at all familiar with what settings in a ControlWave might cause this.

Any help would be appreciated.

 

[krakenfan69]

ControlWave is like a dark dirty secret in the PLC world. I can never seem to find people that use it let alone are knowledgeable in it. I generally call tech support. They are pretty good at helping. Wish I knew more and could help but am struggling with ControlWave myself.

Good Luck,

Kraken Fan #69

 

[Fred_Loveless]

If you are connecting through the controlwave to other devices then communications can be slow but there are ways to tweak the gateway to make it faster. Direct connections should be fast though.

Contact Kepware Technical Support and open a case so that we can look a the setup. E-mail [email protected] or go to the website,www.kepware.com, and create a support case or call 1-888-537-9273.

 

[MitchStripp]

kudave88 did you ever find a solution to this? I had tested the kepware BSAP drvier to migrate from BR3 Driver to OPC and I noticed the same problem ~10min updates

Let me know what the solution was if you found one.

Thanks.

 

[tim.hanlon]

I have set up a couple systems with the Kepware and ControlWave. The main thing to do is try and put everything on its own Channel in Kepware. The problem with this is for the Bristol IP each channel needs its own IP address. This is accomplished by Multi-homing the NIC card. Kepware has done good documentation about this. Also Kepware support helped me out a lot setting the networks up.

 

[krakenfan69]

One issue I have ran into with KepWare is where a customer had purchased a Kepware license from Rockwell (they licensed a version that will only connect to AB equip I believe) and Rockwell is supposed to handle the tech support for this product. Rockwell has no idea about it and Kepware (rightly so) doesn't want to support it as that was part of the licensing agreement. Was a real pain as this was my first foray into Kepware!!

(This was not on a Bristol platform however)

Kraken Fan #69

 

[tim.hanlon]

I think that is on Rockwell not Kepware. Every time I have had a problem with the Kepware they have went above and beyond my expectations. Never have had a problem with them.

 

[krakenfan69]

Yes I agree 100%. Sucks for Kepware as customers see their name on it and assume ( as I did) I try to ensure customers buy their Kepware license directly form Kep and not through Rockwell to avoid this. You are correct, Kepware support has been very helpful.

Kraken Fan #69

 

[diat150]

kepware is a great company. support is top notch and they have a great team of people working there.

 

[Oceansoul]

BBL products are good when they work. I support a large number of 3330 and 3335 controllers. However its the comms that let them down all the time. Sorry I have no idea about Kepware or Bristol IP though.

 

[sgrave9]

I was in the same boat as you about a year ago. As Tim.hanlon mentioned, Kepware suggests you multi-home the NIC card. This helped a bit but was still slow. I eventually abandoned the Kepware driver and connected directly from the Bristol stand alone OPC server to iFix using the OPC power tool in iFix. I still see a slight lag (1-2 seconds) but it's acceptable.

Nothing against the Kepware driver (used it with AB all the time), just couldn't get it to perform well with ControlWave.

Hope this helps

 

[MitchStripp]

sgrave9,

How did you deal with communication failures and the state of your data links and other values when you lost communication with a RTU while using Bristol OPC

When I tested the Bristol object Server, I found that the quality bits would not change state from "BAD- Last Known" to Bad-COMM" so ifix had no way of knowing that the tag values were not valid and they would just hold the last value.

I prefer the functionality of BR3 Driver where when I loose communication or have a failure, all the datalinks change state to "????" or "@@@@" something that identifies values that are not current or failed.

I spoke with bristol and that identified it as something they would correct in a future release..... ( It's been 1.5 years+........ Im still waiting)


Thanks!


I would really like to upgrade from BR3 to OPC so I can use the latest version of OPENBSI but I'm stuck at this point.....