OPC problems with array points

[paulengr 44]

With a ControlLogix processor (L63) on rev 16 if I try to read an array of data points (via Cimplicity) using OPC, everything works fine. If I attempt write to that array, it won't change. Any ideas what's wrong? RS-Linx 2.50.

[Mike Carter 0]

Did you ever figure out how to make this work? We are attempting to do the same thing and we are not finding a lot of information. In our case we are using a PLC5/60 Enhanced with an Ethernet side card. We want to read 100 words starting at N44:0 and ending at N44:99 and put these into a Cimplicity Point as an array. From there we want to create screen that reads the value of each word and if necessary write a "1" into the word from the Cimplicity screen. We have found some information from AB on using a MSG instruction and an MG control word. Where we are running into a wall is configuring the communication parameters of the MSG instruction. What type of transfer, where you would put the IP address of the target PC who will be receiving the data.

[paulengr 44]

Yes. The fundamental problem is that arrays are not clearly defined under OPC at least up to DA 2.0. It appears that there may be progress under DA 3.0 but I don't have access to any of the standards. Sans an actual standard, most implementations do implement an array anyways and there's a de facto way to do this. HOWEVER, it only handles reading/writing the entire array as one large object. It does not allow for access to individual members. Reading then will work even if you access individual elements because Cimplicity just reads the whole thing and parses it out. But there's no good way to write back the entire array. Cimplicity COULD take the one element and write the whole array but it takes the safe approach and simply refuses to do so. Hence when I had problems writing to arrays it's not a fault of RS-Linx or the HMI per se...it's an OPC limitation. If you read the Cimplicity manual very closely, it tells you this but the information is very obscure. Search for "DA" and "OPC" in the manual to find it. The solution then is one of two ways. You could write your own. Use the array reading/writing operations within a script to read/write the entire array. This isn't pretty but it does work. And it requires a rather ugly solution in general. The second option is to just define a LOT of points, one for every array element. This sounds very tedious but there are ways to speed up the tedious part. You can use CLIE to import/export pieces of the point database. Using this function and some creative Excel or other programming tricks, it shouldn't be too hard to generate all the required tags and just import them back en masse. If you name the points ARRAY_NAME.0, ARRAY_NAME.1, etc., then when you display the "tree view" of your points, the elements will be obscured. Picking out the points when you use the point browser when creating/editting screens works. And the names in the data logger aren't all that ugly. We did it and it's working fine. I think the solution is ugly but at least everything works as expected. In the end, I hope this is one item that gets addressed in OPC UA. It's pretty obvious that GE Fanuc is setting themselves up to jump on the OPC UA bandwagon as soon as the specification gets finalized. Edited 18 Sep 2008 by paulengr