Do the Integer, Double, or Long arrays work with the OPC ControlLogix Driver? I got the Boolean Array to work, but nothing else. Are there plans for Floats?
Thanks,
John
Do the Integer, Double, or Long arrays work with the OPC ControlLogix Driver? I got the Boolean Array to work, but nothing else. Are there plans for Floats?
Thanks,
John
Not sure what you’re asking, exactly. Arrays of any datatype should show up as a folder with the elements underneath when you browse OPC.
The only exception to that is an unfortunate mistake with BOOL arrays that shipped with newer Logix Driver (not to be confused with the legacy ControlLogix and CompactLogix drivers for firmware 20 and prior).
Ah… no, none of our drivers expose arrays as actual arrays in OPC. Arrays are all folders that contain the elements.
Ignition only gained some weak support for array type tags recently (7.9, I think).
In future versions array support on the Ignition side will get better and I hope to make better use of arrays on the OPC side as well.
Ignition only gained some weak support for array type tags recently
What types does this "weak" support include? I can't seem to get a String Array OPC tag to successfully reference an array of STRINGs in a v27 Controllogix PLC. Guessing it's just not supported, but thought I'd ask in case there is a trick I didn't think of.
You can only make OPC array tags against tags that are actually represented as arrays in the server. Our drivers all represent arrays as a folder of tags.
I agree that the tag arrays do not work except to bring in an integer or DINT in as bools. This needs to get fixed to make Edge useful. 550 Tags goes by quick and after getting used to not counting because we are using Ignition is back to counting and a pain.
550 historical… sure. 550 bools? Ran out.
While I do agree in principle that all of our drivers (and Ignition’s tag system) need to be updated with better array support, I’m not sure I agree about the bookkeeping.
500 tags is 500 tags, whether or not you stuffed them into an array, and whether or not they’re a boolean or some other datatype. If you wanna go down that road, why draw the line at arrays? What about UDTs? Should a UDT be one tag regardless of how many members it contains?
[flame state="on"] Why Not? [/flame]
I don’t wanna… ahem…
I would prefer not to go down the road of counting tags at all. It was refreshing to make as many as i wanted without limits. I jumped into Edge not realizing there was a limit and have had to switch gears on layout and do more data mapping inside the PLC to make it fit. I am using DINTS as a boolean array and it makes 32 count as 1 tag. But since you bring it up I will say that you count tags faster than Rockwell does. I’ll explain.
I created a UDT for an ABB robot that is brought in as an INT array. The data used is scattered down and is different on each of the 5 robots for the commands and feedback. I created a bool tag for each CMD and ACT, a string for the machine name, string for task, even a string to show the Parameter in the UDT so a tech could easily identify what bit in the logic they were looking for.
The PLC Bit is just an expression string of the parameter. I have it displayed to help a tech out and it costs my project a tag.
I have 16 commands and 6 clear areas. Each uses 2 string tags. It makes it convenient for pop up documentation between the 5 robots. That cost my project 220 tags. They are static strings not even being read from the PLC.
So my single UDT now has a tag count of 108. It’s only asking the PLC for about 40 of them and they are all bools. I haven’t even gotten to the point where the operator turns it on yet or is given status messages / faults or sends actual input to start the process up. So I switch gears and redesign my UDT. I consolidate all the HMI data to be in a neat sequential DINT. I spend time laying it out in a spreadsheet. I remake my templates to look at bits of a tag instead of tags. I create a STRING array of 60 and realize it counts as 1 tag. At least I won’t have to make labels for everything or embed descriptions in an IF expression.
My UDT now has all the same information minus what bit it starts with in the PLC and it takes 9 tags. Actually takes 10 because the UDT parent ‘folder’ counts as a tag.
Here’s the rough draft showing some of 2 robot’s commands and feedback.
Not having to count tags was awesome. Fixing my project to get under the arbitrary limit of 516 was not fun. Finding you count tags is a slap in the face. Finding you count them faster than Rockwell disturbs me. Edge seems like a great product. Have network connectivity issues? Here you go. It’ll backfill your historian. Great! It installs and runs without setting up a local database. Fast! But you better have a really, really small project. The setup we created for you with the awesome UDT with 580 tags in it for all the trending, alarming and recipes? That won’t work here.
Why not 516 historical tags?
Maybe it should be named ‘Edge Compact’ and just talk to 1 PLC. That’s where this tag count road leads.
Back on topic now - please fix your arrays. If you can bring in a DINT as a bool array you should be able to bring in an actual INT[5] or DINT[20] or REAL[44] without spelling out each location as a individual tag. Or you could not allow them to exist for AB OPC connections and not make us try a half dozen different
INT[n]
INT[I]
INT[3]… came in as bools.
INT
INT[…]
before heading over to the forums and reading a bunch of off topic rants about new products with old limits.
So, the itty-bitty price tag didn't register with you? You get what you pay for (and with any form of Ignition, it's a great deal more than from anyone else).
Sorry guys, didn’t mean to derail this topic. And while I defend the bookkeeping on technical merits, I guess, I’m not trying to show my support for the arbitrary tag limit that Edge ended up having. Edge is super cheap (value packed?) and needed to have a number of licensing limits placed on it in order to sufficiently differentiate it from Ignition proper (limits which I had no role in coming up with). Some users will fall on the wrong side of one of the arbitrary limits. That’s always going to suck.
Kevin, it's been over 5 years now. Where do we stand on array better support? any improvements? I want to be able to read in an array from a PLC as an array, dataset, etc... Almost seems like Ignition doesn't understand arrays?
...btw, i agree on the record keeping, (or don't care). i still need to be able to reference, read/write to a single element or tag inside a udt.
Just give me the option to not have to script out and write the values to another tag of a different data type.
For example, if i use Kepware as a 3rd party OPC connection, i am able to change the data type to bring in the data however i want it without scripting. examples below of a tag through Kepware where i can have a single tag for an array displayed in whatever data type i choose, no scripting.
Nothing has changed. No point in updating the driver while Ignition's tag system has terrible array support.
Try writing to one of those array elements you pulled in from Kepware - it only works when a server supports writes with the index range specified, which Kepware didn't used to support, not sure if that has changed.
Is your main pain point trying to create Ignition UDTs with all of an array's elements? Or is it something else?
for my current application, i want to read in an array from a controllogix PLC as a dataset without scripting, so i can bind the dataset to a chart and graph the data.
correct, in this format writing to Kepware is still not supported it seems through Ignition.
Although i seem to be able do this with other SCADA/HMI systems using the same Kepware. (just verified)
but for this graphing out the data in this particular case (last comment), i'm not looking to write, only read.
FWIW, the new driver of mine that is in the hands of some alpha testers supports reading one-dimensional arrays as numeric array tags. Writing back with a list is lenient on length--silently zero-padding or truncating as needed. Look for a public beta announcement soon.
The new driver mentioned has just been released as a public beta:
Directly reads and writes one-dimensional numeric arrays.