A small question for anybody using GX IEC and local variables (something i would ultimately like to know for GX Works 2 but the logic should be the same).

Local variables are assigned to devices (M, D,...) at compilation time but the assigned device can be different from compilation to compilation. For example, if i use a local variable "test" (a bit) and use M's in the assign pool, at compilation, "test" can be coupled to M8000 and the next compilation it could be coupled to M8001 and so on. The same goes for word devices,... and even more importantly timers.

My question: to me, it seems quite dangerous to transfer programs online while the plc is running, using local variables. For example, timers that are running or that have reached their endvalue, could be assigned to different timers at compilation and then transferred online while the plc is running. Words could be given different addresses,... How do you handle online program transfers in that situation?

Also, what does Mitsubishi actually mean with local variables? In pc programming languages, local variables are usually variables that loose their value when you exit the function, program block,... Converting this logic to plc, this would mean that each local variable looses it's value when leaving the POU and therefor needs to be initiated again the next plc scan. That contradicts the ability to use timers as local variables. Assume that i have a local variable "testw" (word) assigned to a device D (for example, compiler picks D20). Let's say that i put the value 50 into it in the POU. Next plc scan, should i assume that 50 is still in my local variable "testw" or should i assume that i can't really know the value of "testw".

Hope that makes sense. In summary:
- can i count on the fact that my local variables keep their value/state/... when leaving the POU and entering the POU again the next plc scan
- how do you deal with online program transfer with re-assignment of devices to local variables

phew :)

On a last note, gx works manuals mention that you should reset your plc after transferring a compiled program. That would make sense since every local variable would get it's initial value after reset (unlatched D => value 0, timers => 0, bits false,...) but there are definately times when you can't stop the plc and need to make an adjustment while in run.

Hi.

When using online transfer, the compiler assigns the next availabe (free) device to any newly created device. This means that your existing program is not changed at all and you can safely do any kind of online transfer while the PLC is running. The compiler will never change your devices during run-time.

However if you compile your complete program (rebuild all) and transfer it to the PLC, the local variables may have been changed and therefore it's at good practice to reset the PLC after a program transfer. But this only applies when re-compiling your complete project.

Regarding PC programming you cannot compare PLC programming at all. PLC's use continous scanning while PC's normally use event driven programs. If you make an infinite loop in a PC program, the devices inside this loop will not be disposed/loose its value.

OK?

@kaare_t:

Thanks. Exactly what i needed to know.

GX-IEC assigns system variables in sequential order when you compile a program containing "local" variables. Say var1 = D1000, var2 = D1001, var3= D1002, ..., var50 = D1049. If you introduce a new local variable between the references in your code to var2 and var3 in an online change, GX-IEC has kept track of the variables already assigned (in the file SOFTCTRL.LOG) so it safely compiles the changes as var1 = D1000, var2 = D1001, varNew = D1050, var3= D1002, ..., var50 = D1049.
Whether, if you do a complete re-compile rather than an online change the software clears out the records in SOFTCTRL.LOG and starts again in order from D1000, is not predictable. Sometimes it does, and sometimes not. Haven't gotten round to figuring out when and why it does it?


In terms of scope of reference, GX-IEC local variables are local in the sense that they can only be references in the body of the POU in which they are declared. So, you can have a local variable with the same name, but holding different values, in multiple POUs.
The reason they are persistent over time (i.e. keep their values between scans) is because the variables are stored in PLC devices that happen to be persistent over time.
From my own PC programming background I tend to use local variables only for variables that could be destroyed at the end of the POU without any problems; if I need to retain the value I make it an addressed global.
This is just a matter of personal habit, it will work either way.

I think i would adopt the same strategy if i was using local variables and assume that when entering a POU, the value/state of the local variable is not known. For most cases, this will be sufficient anyway. The only exception i'd possibly like to make is timers because we use a lot of them and most of them have a scope that is within the POU. Would be nice to let the compiler decide what to pick in that case.

Btw, it's great to have finally found a forum about Mistubishi plc's