Import variables XSY file to Citect SCADA

I don't think that importing from XSY is supported.  If you were keen the format is not that complex.  It depends on the way the PLC is programmed.  XSY does give you the UDT instances, and their structure, which is nice.  Ideally, the structures would be converted to equipment types and the instances to equipment database entries.  So none of that exists as far as I know.

The supported way of importing variables into Citect is through the "import Tags" option in the topology->IODevices form.  This gives a few options for Schneider PLCs.  The one I am most familiar with is "Unity Speedlink to OFS".  I just gave it a test and it worked for me.  You will need a running/licensed version of OFS.  Downside for me is that it just produces discrete tags for everything.  That could be what you want.

There is support for XSY file into Citect SCADA, but it is fairly limited. Only the following driver types are supported:
MODBUS, MODNET, MBPLUS, or UNITE.

Import Variable Tags >  Database Type = Unity Speedlink (EDT) Static

The following file formats are supported for this type:

Path of the Unity project file from which you want to import the tags. If the database type is Unity SpeedLink Dynamic, this is a *.stu file. If the database type is Unity SpeedLink Static, this is a *.xsy file.

I think it is much better to use OFS and import from there. Much more streamlined and easier (Unity Speedlink to OFS) or just default OPC import should also work well.

The static option keeps telling me it's not supported for my IO device

You must use MODBUS, MODNET, MBPLUS, or UNITE as the protocol.

Yes I tried MODNET.

OK, I'm an idiot

STUART tell us more about this one :-)

How long have you got?

Hi Stuart,

not so long. XSY file is a text file with xml content. With a smart editor like Notepad++ it took 1minute, but it needs some expertise, not something special, don't worry. If you need, I can make a video, just let me know

Thanks Arian, good to know that it was an easy fix for you.  To be honest, I am out of this space now, but would probably lean towards a product supported option, which I eventually got working in my test setup after repeatedly missing an obvious, important step.  This would give future maintainers an opportunity to continue to use the integration without needing to maintain a separate workflow.  This may not be a problem for your application.

If you are using an import file that is not supported, it is possible to create your own tag import/export filter. This is documented in the help page: https://gcsresource.aveva.com/plantscada/WebHelp/plantscada2020R2/Content/Format_file.html

However, if you don't have to do imports too often, it may be easier to just manually edit the XSY file.

If you are using an import file that is not supported, it is possible to create your own tag import/export filter. This is documented in the help page: https://gcsresource.aveva.com/plantscada/WebHelp/plantscada2020R2/Content/Format_file.html

However, if you don't have to do imports too often, it may be easier to just manually edit the XSY file.