Data Overwrite Issue with FSQL running on KEPWare OPC Server

I encountered a rather scary problem yesterday with a FactorySQL configuration that I’m moving from RSLinx OPC Server to KEPWare OPC Server.

When my project was running on RSLinx, someone had set up a bi-directional group in FactorySQL, and had defined all the integer items as “Integer (4)” even though I was collecting data from an AB SLC500, which only supports “Short (2)” integers. The project ran for about 3 months this way, without any issues. Apparently RSLinx automatically assumed I wanted short integers, and converted on-the-fly.

When I migrated my FactorySQL project onto a new machine, and began using KEPWare OPC Server, I made a startling discovery. For each integer, when FactorySQL wrote data down to the PLC, it actually wrote 4 bytes worth of information, instead of two. So when I specified N7:0 as my item I wanted to write, it wrote to both N7:0 and N7:1 !! I found the problem, and changed all my integers to “Short (2)” and the problem was resolved, but it took some time to figure out just what was going on.

You may want to put this in some help file or warning or something. Maybe it’s a KEPServer issue, I don’t know. What I do know, is it caused me a few hours worth of grief trying to figure out how my data was getting mangled.

-Dave McGlynn

Wow, yeah, that definitely is a scary issue. Fundamentally I’d say this is certainly a kepware problem, as the driver should know what the word size of the device is and how the addressing lines up. The OPC specification dictates a certain level of data type conversion that should be allowed, and requesting an integer from a short should be fine.

One question: Did you have your tags defined in Kepware, or were you simply using implicit addressing (where there’s nothing defined it kepware, it just uses the requested address to look up the tag in the PLC).

Regards,

I’ve got nothing defined in KEPWare Server, so I’m using implicit addressing. How close are you guys with the KEPWare people? I bought KEPWare Server from you last week. Is this something you would have a better chance at
resolving with them, or should I have a go with their Tech-Support?

Thanks,
-Dave McGlynn

I quickly glanced at Kepware’s documentation, and found the following information:

[quote]The DWord, Long and LBCD data types are not native to any of the PLC models.

When referencing a 16 bit location as a 32 bit value, the location referenced will be the low word, and the next successive location will be the high word.

For example, if N7:10 is selected as a DWord data type, N7:10 would be the low word and N7:11 the high word.
[/quote]

So, while maybe not desirable to the unsuspecting user, this is actually a “feature”. Terminology note: DWord above refers to “Integer” as it relates to this thread- a 32bit int value.

I think the main thing here, and the reason I asked in the first post, is that you’re using implicit addressing (actually called ‘Dynamic Addressing’ in Kepware’s documentation). In that case the only information about data type that Kepware has is what FactorySQL asks for. When defining the tags inside of kepware, I believe that it will default to shorts, and then even if FactorySQL asks for ints, it will just send it the int version of the short.

However, with nothing else to go on, requesting the value as a 32-bit int will cause it to behave as outlined above, as if you went into Kepware and defined a tag and override it to be a DWord instead of a Word. The documentation doesn’t say that this is what should happen, instead it says that the driver will pick a “default data type, specified in the driver’s documentation”, but who knows, the default might be 32-bit.

At any rate, it looks like there’s one more thing you can do to make it safer: the dynamic addressing system allows you to specify a data type in the address. You can add a ‘@’ followed by one of the following types to any address:

[quote]Boolean
Byte
Char
Short
Word
Long
DWord
Float
BCD
LBCD
String
[/quote]

So, all said and told, it looks like it’s more of a tricky feature than a real problem.

Hope this information helps you out,

You know… after I posted that, I worried that it was actually documented somewhere, and that I should have researched this before posting a message… especially if a “quick glance” would have done it for me!

Thank you for doing my homework for me. And yes, it does help and makes complete sense. I suppose it’s just another classic example of RTFM. :slight_smile:

I’m glad you posted it. I had no idea and I’m sure others will appreciate being in the loop on things like this.

[quote=“dmcglynn”]You know… after I posted that, I worried that it was actually documented somewhere, and that I should have researched this before posting a message… especially if a “quick glance” would have done it for me!

Thank you for doing my homework for me. And yes, it does help and makes complete sense. I suppose it’s just another classic example of RTFM. :slight_smile:[/quote]