AVEVA is looking to understand how customers are using the Equipment model. If you would be open to sharing your Plant SCADA application, and are using Equipment, we would welcome the opportunity to analyze your shared project internally.

Thanks Greg, this is typical feedback we are seeing on projects 5K-10K tags or less. The question still remains for other to share if interested, please reach out directly. Cheers!

We have one customer where we use it a lot - they have multiple sites with a lot of commonality which fits the equipment model fairly well. We build suitable XML files outside Citect (I find the equipment editor cumbersome) but it generally works well for us. These are actually all pretty small sites (I think some are <500 tags).

Conversely on larger projects we find it doesn't work for us because there are too many parts of Citect which aren't equipment aware. It's been a while since I looked but I think local variables was one? In the end we've rolled our own solution and almost all tags/alarms/trends/cicode/graphics symbols are managed in whole or at least in part outside PS Studio.

(As an aside: we have been importing tags from CSV files for over two decades, but have recently hacked our own replacement for the I/O Devices -> Refresh Tags dialogue, which has become unmanageable due to the number of devices we now have on this site; expecting it to be slower but easier to use it's actually far faster than the standard tool which makes we wonder what the official import does and whether that could do with some love?)

If you're looking at automation more broadly there are also some GBA limitations it would be great to see the back of, in particular the inability to import symbols with flashing colours and the lack of automation for "Swap Colours" which would be the best workaround for it (our current scripts have to push Alt-L,S,ENTER via the keyboard buffer which is slow and frequently fails, and even then there's no way to select which colours are being swapped that way).

PS: I did try to contact you via direct message but got no response. If you've not had many replies that might be an issue for other people too.

Thanks for that information Mark.

If you get time, I'd love to hear about the other areas you found that are not Equipment aware that get in your way.

Local variables is an interesting one. Interesting in that they are associated to a computer, not a cluster. Equipment, for good or bad, must be associated with a cluster. That oddity is why we haven't supported them in equipment. I am not suggesting that insurmountable, just those differences justified not including them at the time. I am still interesting to know who you use local variables with equipment though.

For import speed, just so I understand you clearly, are you saying Tag Import via I/O Devices, is faster than the "Import All" options you see on the grid views (like variables)?

Not being able to generate Local Variables is one of the main reasons we have created our own Equipment Editor and Generator (and for way better generation speed of course).
We use Local Variables to cache operator input (setpoints) so the operator can transfer them to the PLC only after reviewing the set and hitting an 'Activate' button. For this we need a Local Variable for every PLC setpoint.

Thanks for that Patrick.

Have you compared against 2023 R2 for equipment gen and update speed? I would be interested in results.

I'm talking about "Refresh Tags" (not import) on the I/O Devices page of PSS. Either you select the device(s) you want to import (cumbersome when you have >250 devices to select from as I do) or you "select all".

There doesn't seem to be any attempt to combine multiple tasks into one, so "select all" is essentially the same as repeating the process for each IODev individually. As a test I just tried updating all (with no changes needed) but gave up after about 3 minutes as it was clear it had only handled a few devices by that point. (And "Cancel" only cancels the current import so I had to cancel the other 200 or so as well - that took almost as long!). Each IODev import takes about 15-20s on my box, so extrapolating that means 250 would take a  bit over an hour.

The comparison is with out own scripts which use ODBC to do the update from the same CSV tag files (maintaining compatibility, although we've started to add some extra functionality like support for comments in the CSV files). A "do nothing" test (no changes) takes maybe a second (it skips any files which are older than the last update time in units.DBF). If I force it to update everything regardless of timestamp it takes maybe a second more with nothing to do. If there are a lot of changes it takes maybe 2-3s, sometimes a few seconds longer if it takes the ODBC driver a while to flush the changes to disk but PS will see the tags before the flush anyway so that's immaterial.

The script isn't doing anything particularly clever or highly optimised (it's written in PHP because it started out as a quick hack to test a theory), but it still shows what is possible via ODBC (which I assume is what the existing tool uses).

Local variables: for our use case there are thousands of "zones" which have pretty common properties and would suit equipment. But part of the functionality is that individual client PCs can edit scenarios involving these zones. and those edits have to be local (two client PCs might edit different scenarios at the same time). (These used to be MEMORY device variables back in Citect 5.x/6.x days which we could therefore import via the above mechanism, but even that was lost when transitioning to local variables.)

As to other things: well each zone also has custom cicode (which could equally be implemented as labels but they're not equipment aware either). Since these points alone were show stoppers for us I haven't delved any deeper to see what else might break!

To be honest, I think any competent developer working on large projects will roll their own tools anyway - the main thing is to keep formats as open as possible to allow that and to provide scriptable automation tools where the format is closed. GBA is a fantastic example of this (which could use some love as I mentioned before, but even as it is it's saved us hundreds of hours of work so far this year alone).

I'm talking about "Refresh Tags" (not import) on the I/O Devices page of PSS. Either you select the device(s) you want to import (cumbersome when you have >250 devices to select from as I do) or you "select all".

There doesn't seem to be any attempt to combine multiple tasks into one, so "select all" is essentially the same as repeating the process for each IODev individually. As a test I just tried updating all (with no changes needed) but gave up after about 3 minutes as it was clear it had only handled a few devices by that point. (And "Cancel" only cancels the current import so I had to cancel the other 200 or so as well - that took almost as long!). Each IODev import takes about 15-20s on my box, so extrapolating that means 250 would take a  bit over an hour.

The comparison is with out own scripts which use ODBC to do the update from the same CSV tag files (maintaining compatibility, although we've started to add some extra functionality like support for comments in the CSV files). A "do nothing" test (no changes) takes maybe a second (it skips any files which are older than the last update time in units.DBF). If I force it to update everything regardless of timestamp it takes maybe a second more with nothing to do. If there are a lot of changes it takes maybe 2-3s, sometimes a few seconds longer if it takes the ODBC driver a while to flush the changes to disk but PS will see the tags before the flush anyway so that's immaterial.

The script isn't doing anything particularly clever or highly optimised (it's written in PHP because it started out as a quick hack to test a theory), but it still shows what is possible via ODBC (which I assume is what the existing tool uses).

Local variables: for our use case there are thousands of "zones" which have pretty common properties and would suit equipment. But part of the functionality is that individual client PCs can edit scenarios involving these zones. and those edits have to be local (two client PCs might edit different scenarios at the same time). (These used to be MEMORY device variables back in Citect 5.x/6.x days which we could therefore import via the above mechanism, but even that was lost when transitioning to local variables.)

As to other things: well each zone also has custom cicode (which could equally be implemented as labels but they're not equipment aware either). Since these points alone were show stoppers for us I haven't delved any deeper to see what else might break!

To be honest, I think any competent developer working on large projects will roll their own tools anyway - the main thing is to keep formats as open as possible to allow that and to provide scriptable automation tools where the format is closed. GBA is a fantastic example of this (which could use some love as I mentioned before, but even as it is it's saved us hundreds of hours of work so far this year alone).