Compiling Tags that exist in Cicode

Hello Jared

Tag not defined is a compiling warning, not an error, so you can compile the project without the tags defined.

But you can't read or write those tags that are not defined.

Ok, thanks. That makes sense.

Jared,

There are several different things to consider here. The most important is the SCOPE of the variable. If the variable that is popping a warning on the compile is a GLOBAL variable (one that needs to be defined and communicated within the SCADA system's I/O) it needs to be properly defined in the variable database . . . as Nuno noted.

If it is a PRIVATE variable (one that is instantiated within a function when the function is called), and is never used outside of that function, it will probably work correctly, but still pop a compile warning because it is not defined in either the GLOBAL or LOCAL variable databases. From your description of what you're seeing, it sounds like this is your case.

If you want a clean compile without any warnings you can always define the variable as a LOCAL variable. However, be careful with that; because if the same private variable name is used in multiple locations and functions AND it is defined as a LOCAL variable, who knows what might happen. Try it out on a testbed system.

Ultimately, my advice would be to go with the old adage, "If it aint broke, don't fiix it.", and live with the warnings if everything is working correctly. Hopefully, one of the engineers at AVEVA will come across the post and have a better insight as to how Citect SCADA handles variables of differing scopes and can give a more authoritative answer.

Local variables and variable tags can be used from anywhere in Citect, including Cicode functions. Cicode variables can only be read/written from Cicode functions (private variables can only be accessed by functions in the same Cicode file). So, if you create a global or module scope Cicode variable with a command like INT miValue; you will not be able to read/write miValue from a graphics page. If you need to access that value outside of Cicode, you could create Cicode functions to set or return the value, like:

INT miValue;

FUNCTION SetValue(INT iNewValue)

  miValue = iNewValue;

END

INT FUNCTION GetValue()

  RETURN miValue;

END

You are allowed to create a local variable or variable tag with the same name as a Cicode variable, but that creates 2 or more different variables with the same name...which just causes confusion. The graphics would use the local variable and the Cicode functions would use the Cicode variable so they would have different values.

I can't stand having compile warnings. The problem is that if you make a project change that causes a new compile warning, it is easy to miss it if you always have compile warnings that you ignore. Then, you'll wonder why the change isn't working correctly.

I would either delete the graphics that use those tags (since they probably never worked and no one cared), or set up functions like above if you need to share the values. Also note that each PC and each Citect runtime process within the PC (report/alarm/trend/IO/client) will have its own independent copy of all Cicode variables so you need to know where the Cicode is running that writes the value or you may not see the same value in the client process. Another possible solution is to delete the Cicode variable declaration (like "INT miValue;") and create a variable tag with the same name in a memory I/O device so the same value is shared between all client and server processes.