Professional version of FT Linx Gateway now deliver Logix Extended Tag properties, and Tag-Based Alarm, it is also an MQTT publisher,
I think this is a huge thing that Rockwell decided to release them for any third-party client. I tested Extended tags properties, was readable easily. I think you dont need to change anything at PLC. Just build the objects as per FT View in Ignition.
Linx Gateway works fine, I am running it at 400,000 tags in our plant and seems fine, we don't have any problem with Citect. Rockwell capped it to 500,000.
I guess if someone makes PlantPax 5 objects and use Gateway, could be good solution.
I never hesitate to recommend using FTLinx as an option. The only problem(s) for some people is it’s an additional piece of software they need at an additional cost, and it requires Windows.
I have a project where PlantPax v5 is a requirement and we are trying to push them away, at least back to v4.1. Aside from the fact that instructions are now baked into the firmware (no AOIs) and requires one of their special "P" controllers like L320ERP, I have also noticed tag naming differences (Dly vs Delay) and missing Cfg tags. So, any SCADA/HMI that was developed for v4.1 is not going to magically work without some massaging.
For v4.1, to my knowledge all alarms (Alm_) would be accompanied with a Cfg_Has...Alm tag. In v5 these tags are no longer present, instead it uses alarm properties like @Alarms.Alm....Used.
So, the question, what drivers can use these extended props, only a Rockwell product? I know the native Ignition driver can't, but Phils driver, TopServer, etc.?
Thanks Kevin. I'm just making sure I understand completely and if there's in fact nothing other than a Rockwell product to read these props then I'll simply forward that info on to the client. IMO they shouldn't attempt using v5, but they'll have to make the final decision and then live with the consequences.
Supposedly, you can now use FactoryTalk Gateway Pro to expose extended properties as OPC tags, but I can’t personally confirm this.
I’m sure you’ve read the threads. Do not use V5 with Ignition unless you also plan to use FT Gateway. Neither the Ignition driver or 3rd party are capable of doing this with v5.
In my opinion, Rockwell has done this to intentionally box out Ignition and force you into FactoryTalk View SE… at least until Optix catches up in 10 years.
I've been reading this and other threads about PlantPax and Ignition drivers. I have a project adding Ignition to a plant that has one PLC with PlantPax v4.0. It is a small program and Ignition will read less than 500 tags from this PLC. Would you all recommend following this structure? If not, what tag count (in Ignition) would this practice be recommended? Keep in mind this is an existing PLC program and uses FTView ME as the HMI on the floor. (Ignition is being added for SCADA purposes only).
You are probably fine with only 500 tags. I'd only start worrying when you have several thousand tags in AOIs. (Or lots of individual small tags--similar optimization problem.)
Rockwell has been doing this dance ever since they bought Allen-Bradley in the late 80s. Allen-Bradley makes fantastic hardware. Rockwell has always made crap software. The only reason their ladder editor is/was decent is because of ICOM, who they bought out and eventually turned those features into RSLogix 500/5000. The rest of their software history is blunder after blunder. The worst thing they ever did was get in bed with Microsoft 20 years ago and now their visualization software is reliant on Windows XP/Vista/7-era libraries that they've constantly had to patch over. FactoryTalk View is so bad because so little has changed since it was RSView32. It's literally 1990s software they're still trying to pass off as modern. And they're not even the worst. Don't even get me started on iFix. There's a reason I've often described Ignition as "SCADA software that was designed in this century."
Going back to the original topic, and I apologize if it was already covered, but in moving the PlantPAX AOIs to the processor firmware in those P class processors, wouldn't that make them, technically, no longer AOIs, and thus no longer have the same issues that AOIs have?
From what I understand, the reason AOIs have an issue with Ignition is because not all of the AOI members have external access turned on, and additionally I believe InOut Parameters can't have External Access, at least there's no option in the external access column when you set up the AOI.
But doesn't that all change when the instruction is part of the firmware? Wouldn't it be the same as, say, a timer, counter, MAM, etc.? Or do those tag structures have issues with Ignition as well? Or did Rockwell lock down the instructions permanently in the firmware too? I guess I'm just confused because everybody's talking about them like they're AOIs, but the way Rockwell salespeople explained it to me is that they're now baked in the firmware, which makes them by definition not AOIs anymore, because they're not add-on anymore. Or does that not functionally make a difference?
I can't speak to your question, but what I noticed is a lot of the Cfg tags are now extended properties, like Cfg_Has_...Alm, Cfg_Desc, Cfg_State(s), etc. and aren't accessible via OPC by any non-Rockwell driver. So IMO that change alone is a deal breaker.
Interesting. I did see a few comments about FactoryTalk Linx Gateway being able to provide those externally, which is huge. I know a lot of people use Extended properties for alarm messages, too.
I haven't dealt with PlantPAX much. I've tried to sell it a few times, but the customers I spoke with always said something along the lines of "that's too complicated. We want something simpler." From what I've seen, it looks like Rockwell took every possible function any customer has ever asked for and baked it into these mega instructions, and the result is most customers are each using a slightly different 25% of the available functionality. And honestly it wouldn't be so bad if A-B wasn't also charging $5,000 a megabyte for processor memory.
Not really. For the IA driver, they fall into the non-reverse-engineering rule. For both IA's driver and my driver, it doesn't matter that they are built-in types, but we do care that they have non-readable members. And they do have non-readable members. (Certain other built-in types also have non-readable members, particularly I/O module data.) Utterly unoptimizable, just like any earlier PlantPax AOIs that are sealed.
Just say no to PlantPax 5. And to earlier PlantPax, if any are sealed, or are using any unreadable types.
My first ever exposure to Ignition as an actual paid project was a couple years ago coming into a plant where another contractor had bungled the integration so badly that my customer decided that having them continue to "fix" it was doing more harm than good, cut them loose, and have been (slowly) fixing it with in-house engineers ever since. The PLC program was written in PlantPAX, and the (Gold Certified) SCADA engineer was linking Ignition to all those AOIs directly. Every tag was on the Default tag group, polling direct at 1,000ms. Thousands and thousands of them. Pulling every bit of data from those bloated PlantPax AOIs, even the String data.
When my customer's Controls Engineer came on board, their $14,000 blade server dedicated solely to Ignition (and the SQL database on the same machine, of course) was running at full capacity. The PLC comms were pegged at full capacity. Ignition would crash multiple times a day.
They've spent literal years reworking their PLC program and Ignition app to streamline it and get it to a workable solution they have now. Last I talked to them, they were actually replacing the PlantPax AOIs with their own home-grown versions that only have the features they need. Thankfully, my part was just adding some screens and popups here and there. But I learned how much of a nightmare PlantPax can be, and also that simply being Gold Certified doesn't make you an Ignition expert.
That actually makes me wonder. Is anybody offering an "Ignition-friendly" alternative? Like a suite of Rockwell AOIs/code blocks and Ignition templates that perform a lot of the same functions? Rockwell built their Faceplates on such a cruddy platform, which I'm sure translates to programming weirdness that wouldn't have to exist on a more modern visualization platform like Ignition.
There's a lot more to know that isn't covered by the gold cert test. You wouldn't know that reading aoi tags was terrible on performance unless you are active on this forum, for one, and that excludes swathes of people already. Unless I've simply missed it, this isn't discussed at all in the user manual (it really should be!!!)
