Errors migrating project from CitectSCADA 7.10r0.28 to PlantSCADA 2023 (update 06)

Good evening, I'm a new user of the PlantSCADA/CitectSCADA and I have been tasked with migrating and merging two existing SCADA systems, both made on the same older Citect version 7.10r0.258.

One of them the migration was done sucessfully and I have started to make changes to it and so far it works fine in the simulator (I have not tested the communication with a PLC yet, will do so this week).

The other project is giving me an error that seems to be like an internal exception of the PlantSCADA since the text is very generic and in my OS language even though I have installed PlantSCADA in english.

I can attach the .ctz files if such is allowed..

The error that I get is the following:

The text in the message box translates more or less to: "Invalid chain of characters"/ "Invalid character chain"

This text box appears dozens of times while doing the project import, specifically when this action is being executed:

It reaches around 4000 tags analyzed, throws the error in the PlantSCADA main window and starts again, I can abort it, and I can run the imported SCADA in simulation mode, but I don't even know if I'm losing tags or not, since after aborting that step no more errors are generated. This is a project with 4000-4500 tags, so validating one by one with is not a feasible option.

Any idea on why this is happening, and what can I try to fix it?

Best regards and thanks for your time.

  • Olá Angelo

    Probably there is an error in the variable tag name. It seams to be a spanish project and now is in a portuguese operation system. 

    I would search for a special character like ñ, ç, õ, etc in the tag name and replace it with correspondent letter without accent.

    You can open the original variable.dbf file in excel just to search for the tag. And also to check if you are loosing tags or not.

    May be there are tag names starting with numbers, but I think that will not make that error. For that there is a citect.ini file o enable tags starting with numbers.

  • It sounds like that project has one or more I/O devices that are linked to an external tag database, such as the PLC project. Every time you compile, it tries to import the external database and refresh the tag list in your project.

    Go to the I/O Device properties as shown above. Set Automatic Refresh: FALSE and compile again. The error should not appear. You still have the full list of tags in the Plant SCADA Variable Tags list from the last successful refresh. You just won't get automatic tag definition updates from changes made in the external database. If you can fix the problem in the external database, you can manually trigger a refresh by clicking Refresh Tags in the toolbar.

    If the format of the external database has changed and is no longer compatible with the Citect import filter, you may have to export the database to an Excel file and manually copy that into Citect's tag list when you need to get updates.

  • Olá Ventura,

    You are correct, it is indeed a project that was started by a spanish integrator in a portuguese factory, and now I'm tasked with doing a migration to the latest PlantSCADA.

    Thanks for your tips, I checked the variable.dbf file, and checked that no tag started with a number, I also confirmed that there where no such characters.

    Both the original and the imported projects have the same number of tags, so far so good.

    I have a new question, if you dont mind, almost all tags are greyed out, with only the last 13 being in full black text, on the left side there is also a lock symbol, but I can't find any setting about locking a tag.

    Thank you for your help.

  • Hi Eric, thank you for your time.

    That was exactly what was causing this issue, the other project had that setting in the FALSE state when I imported it.

    If you dont mind, could you give a look on my reply above?

    Best regards.

  • Hi again.

    That is not a "lock" symbol, is a "link" symbol, that means the tags are linked to an external source as  answered correctly your previous question. The same grey color also appears in the tags created by the equipment editor (this is not the case as the equipment name is empty in your image).

    If the tags are correct you can leave them as they are, it works well with grey or black color, and you still can change some fields like ranges or comments (I think) . But if you want to change something like the tag name or address or add the equipment you need to have them in black. One easy way is to select the limes you need to change (to a max of 1000 each time) and copy them like in excel (and in the end delete the grey ones.

    From your image, to remove the warnings you also need to use the hostname instead of IP in the Topology - edit - network address, and fill a few fields in the roles (the warnings are self explained). I also can see that you are using modbus, probably modnet, so probably is a Schneider PLC. Depending on the time and budget you have, and also the age of the PLC, may be interesting to think in change the communication to OFS (the address will be the PLC tag name (easy work is the citect tags already have the same name as the plc, harder otherwise) and the performance may be better, that depends of several factors, but usually is better).

    Regards

  • If IP addresses are still preferred, fill in the associated DNS names in Computers Table. This is required by the encrypted communication as the TLS certificate is bound with Hostname not IP.

  •  and  are correct about the linked tags.

    If you never want to use the external (linked) data source again and want to enable editing these tags, you can follow these steps:
    1. Make sure you have a good backup of your project(s).
    2. Make sure a 32-bit version of Excel is installed on your engineering machine and that the Plant SCADA Project DBF AddIn is installed as well.
    3. Open the Variable Tags in Excel using the AddIn.
    4. Clear all data in the 'EDITCODE', 'LINKED', and 'TAGGENLINK' fields.
    5. Save the dbf file using the AddIn.

  • As an alternative to Excel + Add-In, LibreOffice is a free download and handles .dbf files reliably without any fuss. 

  • I would not recommend LibreOffice, or OpenOffice. These applications gave me lots of problems with special characters, like degree symbols, in the past. It might be better in newer versions of course, but I would be very cautious when using that.

  • Odd, I have been using LO for this for the past two decades (and OO before that) and always found it to be more reliable than Excel. (From memory there were things that the macro didn't fix -was it field widths if you changed a column width for viewing purposes?) I'm pretty sure that even back around the turn of the millennium when I was running Citect training courses we used OO as well as Excel + AddIn - but then this is the UK with very few characters that would be affected (°C in tag units being the main one I think).

    LO lets you pick a character set when the file is opened, and I'm 90% sure OO did too. And I don't think it would ever change your character set (so even if a character looks wrong when you open a file and then save it, it'll still work just fine after saving, so for the purposes of the exercise here it shouldn't matter what character set you used.)

    As always though, caveat emptor and all that. I would recommend giving it a go at the very least, but I would agree that caution is not a bad thing!