I seem to be running into issues handling L5K BOOL[32] and BOOL[64], despite the different options I have tried.
Originally, I simply imported the tags in via the OPC browser, discovered it puts them into an array of 32, (So you would have 2 arrays for a BOOL[64]). From my reading, this is expected. Noticed the default data type of Integer, so changed that to Boolean Array, so now it shows them broken out with [#] for individual referencing.
Start making my objects and everything was going fine until I had to add MultiStateButton. I could add the tag pointing to ###[0] just fine, but when I went to use the button, it would strip off the [0] and then say it couldn't write the value.
From some online reading, it seemed this was a known bug, so was recommended to use the L5K Parser tool to instead create each BOOL as an individual tag within Ignition. I added that, created the UDT/Tag .jsons, imported those just fine.
But then I discovered that while it did create an array of 64 tags for each of the BOOL[64], it's like it still tried to assign the first 32 to tag 0, and the second 32 to tag 1. Tag 2-63 showed Bad.
Logix processors expose boolean arrays as arrays of 32-bit DWORDs, packing 32 bits per word. As far as any SCADA system is concerned, that is what they are and how you have to access them. (At the OPC Item Path level.)
I strongly encourage you to make individual boolean tags where writing is needed, and for any other case where the fact it is an array is not an algorithmic necessity. When you do not need to write, structure your array accesses to handle 32 bits at a time.
If you are referring to structuring it in the PLC as individual Boolean tags as opposed to an array, I would normally agree.
However, I'm not the one writing the PLC. I was simply handed a .mer file with the instructions "Mimic these Studio ME screens in Ignition", which is such an innocuous sounding phrase.
And their program is rife with BOOL[64] and BOOL[32], and that's how they built their HMI objects.
[Edit] Oh, I misread, you meant just create individual bool tags on my end for writes, like driving a pushbutton. Gotcha
Definitely not that. When an application needs a bunch of booleans for User Interface purposes, an array of booleans is way more efficient in communications that individual boolean tags. But Ignition allows you to hide that comms optimization and make individual boolean tags in Ignition, pointing at bits within those PLC arrays.
FWIW, I would normally use bits in explicit DINTs for this sort of thing. You get the comms optimization, but presents the same in PLC and in SCADA.
One further warning: bits in typical HMI applications are often tied to momentary buttons, as if the buttons replace classic spring-return physical buttons. This is a huge pain point in SCADA. Some reading for you. (Some of it quite heated.)
I hope you aren't being asked to do momentary buttons in Perspective. (Still a problem in Vision, but workarounds are possible for it.)
When I am writing the PLC logic, I do the same thing. Just use a INT or DINT and go to the bit level. I never use actual BOOL data types. But I'm stuck with someone else's work.
And so far, I've only see toggle on/off style buttons. But I've only begun to go through their screens.
WHAT TIMING! I am building a tool to update the L5K parser as we speak. If you wanted to run it through my tool, and/or send me the project docs, I'd love to test/incorporate it in:
Note that my EtherNet/IP driver suite includes L5X parsing, producing a virtual copy of a Logix PLC in the driver's "Host Device" type. That host device exposes the resulting UDTs and AOI types as easily-imported Ignition JSON for the designer tag browser. Unfortunately, both L5X and L5K omit a few details about certain types.
For a high-fidelity copy of a Logix PLC, point the driver suite's Generic EtherNet/IP Client driver at the real PLC. The browse results will be converted to UDT and Tag JSON for the designer tag browser. (Subscribing to a complete PLC is not good for comms performance, but the JSON is easily pruned/customized for the user's needs.)
The above all works in trial mode, and the resulting tags and types are compatible with the IA native Logix driver.
