RSLinx OPC Error

Hi,

We have been experiencing some issues with an installation that is utilising RSLinx OPC to serve data to Wonderwares Factory Suite OPC DAS IOServer.

Tags were configured to be N9:20/15, but when viewing the status of them in the DAS monitor, they were displayed as -1, which in my limited knowledge is not possible for a discrete item.

Wonderwere agent has said that they recall an issue maybe with the way that RSLinx reports the data to the IOServer, and depending on when it was done etc, sometimes gets confused and reports the wrong data type. Whilst this sounds semi-possible, is still a bit of a crock as the IOServer should report an error under that scenario for a discrete item.
They have asked to check if the latest version of RSLinx is installed, the installed version is 2.54.00.11 CPR9 STR1.

I think that a later version is out now, is it worth updating it, or does it sound like a IOServer issue?

Has anyone heard of this type of issue before? The other thing that is behaving oddly, is that it seems that the variable address's are getting over-ridden with the last value, if I try & change the value of address, it gets over-ridden with the last value.
What I don't know, is this the IOServer or RSLinx OPC doing this?

Showing a -1 for N9:20/15 leads me to believe that the DAS server is treating that (just bit 15) as a signed integer instead of a single bit.

RSLinx itself will always properly return a single bit if asked for one, not an integer, AFAIK. WonderWare probably optimizes the read to grab the whole N9:20 word, and then manipulate it, but it is reading an entire word, and assuming that since bit 15 is the 'sign' bit, the resultant is negative.

Showing a -1 for N9:20/15 leads me to believe that the DAS server is treating that (just bit 15) as a signed integer instead of a single bit.

Click to expand...

True, & I thought something similar. There are other bits within the N9:20 word that are used for similar control functions. But when I spoke to our WW agent, he mentioned the likelihood that it was the RSLinx version, & to check that all out. Could be more of dodging a bullet perhaps...

RSLinx itself will always properly return a single bit if asked for one, not an integer, AFAIK. WonderWare probably optimizes the read to grab the whole N9:20 word, and then manipulate it, but it is reading an entire word, and assuming that since bit 15 is the 'sign' bit, the resultant is negative.

Click to expand...

I don't know whether the '15' is directly related, as I did try swapping some bits around, with similar results. At the end of the day, if a tag is configured as a discrete item, then it should only be a 1 or 0, never -1!!

More concerning is the issue with a value in the PLC getting written a value without it being commanded. I know for sure that this is not happening in the PLC, but am not sure if it is RSLinxOPC or the DAS Server. I can try & test this I guess, maybe isolating the tag in question to see if it is the DAS or RSLinx.

My thoughts are that it is the WW end, based on previous knowledge of similar type issues that have been reported over the years.

In the meantime, I have replaced the controls with integers, which did work for a short period, but then it now appears that one of these values is getting over-written also.

I've run a bunch of bits, including N9:20/15 backwards and forwards through RSLinx Classic (although it is 2.57.00.14), and RSLinx Enterprise with a PLC-5, and didn't see anything strange.

Of course here, I only have FTView for testing.

Have you tried reading that value as a boolean into Excel?

rdrast said:

I've run a bunch of bits, including N9:20/15 backwards and forwards through RSLinx Classic (although it is 2.57.00.14), and RSLinx Enterprise with a PLC-5, and didn't see anything strange.

Click to expand...

RSLinx Classic 2.57.xx, interesting, I must have a look & see if I can update this version. I still need to try & isolate if it is the WW DAS or Linx

Of course here, I only have FTView for testing.

Click to expand...

And you would think that this would be more robust than anthing else....

Have you tried reading that value as a boolean into Excel?

Click to expand...

No, net yet. I am not sure if there is Excel on this machine. I should be able to just use a DDE link through right?
Can I do it from Excel on another machine?