View Full Version : Proficy: Machine Edition / Memory Areas

January 28th, 2008, 08:42 AM
I am working with Proficy: ME with a PAC RX3i controller. Normally I would map variables to a memory space on the CPU. However this controller supports "Symbolic" memory that variables are automatically assigned to if one does not specify a specific address for the data.

An excerpt from the help file:
A symbolic variable is a variable (http://../EJs/EJ_Var_Variables.htm) that you do not map to the PACSystems CPU memory or PACSystems Hardware Configuration. Machine Edition automatically handles all the mapping for a symbolic variable in a special portion of PACSystems user space memory outside %R (http://Memory_Areas_GE_Fanuc_PLCs.htm#R_memory_area), %AI (http://Memory_Areas_GE_Fanuc_PLCs.htm#AI_memory_area), %AQ (http://Memory_Areas_GE_Fanuc_PLCs.htm#AQ_memory_area), %P (http://Memory_Areas_GE_Fanuc_PLCs.htm#P_memory_area), %L (http://Memory_Areas_GE_Fanuc_PLCs.htm#L_memory_area), %W (http://Memory_Areas_GE_Fanuc_PLCs.htm#W_memory_area), %I (http://Memory_Areas_GE_Fanuc_PLCs.htm#I_memory_area), %Q (http://Memory_Areas_GE_Fanuc_PLCs.htm#Q_memory_area), %M (http://Memory_Areas_GE_Fanuc_PLCs.htm#M_memory_area), %T (http://Memory_Areas_GE_Fanuc_PLCs.htm#T_memory_area), %S (http://Memory_Areas_GE_Fanuc_PLCs.htm#S_memory_area), and %G (http://Memory_Areas_GE_Fanuc_PLCs.htm#G_memory_area) memory. In fact, if you map (http://../HowDoIs/Mapping_Variables_to_PLC_Memory.htm) a symbolic variable to one of those memory areas, you destroy its symbolic nature and it becomes a CPU-mapped variable.

Not sure when I should use this managed, symbolic variable space as opposed to regular CPU memory. Does it even matter? Once I downoad to the controller it all takes up the same amount of memory doesn't it?

January 28th, 2008, 09:43 AM
Typically, you will use CPU-mapped variables in your programs and give the variable some meaningful name to enhance readability of the program. For instance, something like Alarm_Reset could be mapped to %M00001. Then, you can configure Proficy to display the variable name, address or both.

Where I have found symbolic variables to be quite useful is when declaring variables for timers and counters. Timers and counters use three consecutive words of memory for the Current Value, Preset Value and a control word. If you use CPU-mapped variables, you have to ensure that you do not "step on" any of these words with other CPU-mapped variables or instructions that will overwrite the timer/counter data words. Symbolic variables are perfect for this. In fact, when I place a counter or timer instruction in a program, I will just type in the name of the symbolic variable that I want to use and Proficy will create the variable. The thing is that when Proficy creates the variable, it will not set the variable as retentive. When you verify the program, Proficy will display a message that it is setting all symbolic variables to retentive. If you re-verify, the message does not come back unless you have defined new symbolic variables.


Steve Bailey
January 28th, 2008, 09:56 AM
For the most part, it doesn't really matter whether you use symbolic variables or traditionally addressed variables. Ken has identified one example where symbolic addresses can prevent a frequently-encountered problem.

Use CPU-mapped variables for things that need to appear on an HMI panel, especially if the HMI uses serial communications. The serial port drivers in your HMI will be looking for traditional addresses. Furthermore, the serial port drivers are at their most efficient when you use contiguous addresses for anything displayed on the HMI. That's because the drivers read data by sending a command that says "Send me X bytes of data from memory type Y starting at address Z".