M Variable usage

[Tom Rathbun]

This should be a simple one. Using a TurboPMAC you can "undefine" an M variable like this:

M100->*

I can still assign a value to M100 , I assume a 24bit Integer? and use it in my programs. It works fine.

In looking through the manual there is a section that talks about making additional timers and it says I need to assign my M variable to "An open memory location"

 

From the User Manual:

If more timers are needed, use memory address X:$0. This 24-bit register counts up once per servo cycle.

Store a starting value for this, then each scan subtract the starting value from the current value and

compare the difference to the amount of time to wait. By subtracting into another 24-bit register, possible

rollover of X:$0 is handled gracefully.

Define the following M-variables with on-line commands:

M0->X:$0,24 ; Servo counter register

M85->X:$0010F0,24 ; Free 24-bit register <=====

M86->X:$0010F1,24 ; Free 24-bit register <=====

Then write as part of the PLC program:

M85=M0 ; Start of timer

M86=M0-M85 ; Time elapsed so far

WHILE (M86

M86=M0-M85 ; Time elapsed so far

ENDWHILE ; Exit PLC program here when

 

Here is the question,why do I need the 2 marked steps, why can't I just use

M85->*

M86->*

 

The reason I ask is that I normally just find an unused M variable then do the

Mnnnn->* and use it like a P variable. After reading this in the manual I am afraid I am going to get into trouble doing what I am doing.

[mbalentine]

The issue is your assumption of a self directed Mvar being 24 bit unsigned.

The Mvar definitions are located in 48 bit registers, and when self directed contain a signed value of -2^35 to +2^35-1 (see pp 353 & 512 in SRM)

The servo counter takes on positive values only from 0 to (2^24-1), while a self directed Mvar is defined quite differently.

So what...?

For rollover handling I believe you should use 24 bit unsigned variable

Here's a very likely scenario:

M85=M0; capture start time BUT M0 is only 100 counts away from rollover (random chance)

M86=M0-M85 ; Time elapsed so far

This step will only be accurate if no rollover has occurred in M0 OR if M86 roll over width (and type) matches M0. You definitely do not want to subtract and get a negative value in M86. You could use a self directed Mvar for M85, but I think that would be confusing and risky.

Not sure I explained this very well

At any rate, also keep in mind that max delay is 2^24 counts unless you cascade your logic.

[Tom Rathbun]

Ok that makes scene, so no problem using the self defined M variables for general use. What about when I want to compile the PLC. Do I need to do anything special? Would my PLC's execute faster if I some how forced them to be 24 bit?

Thanks

[mbalentine]

Just for clarity let's make sure to differentiate between the 'normal' interpreted PLC and the compiled PLCC.

 

If speed is the need, a PLCC will run tremendously faster than a PLC because it is compiled into machine code before downloading.

For 24 bit integers you can use Lvars (kinda like an Mvar, but the pointer only references 24 bit integers).

Fvars are 48 bit either floating point or signed integer depending on how they're defined. Again, sorta like an Mvar in that they are numbered.

AND, you can use actual arrays! sort of. (instead of indexing one Mvar with another)

Take a look at pp375-382 in the User Manual for details.

 

More direct answer to your question - Mvars have a lot of overhead no matter how they are defined, but are powerful in the way and scope of memory access. Pvars are more efficient, but cannot do most of the things an Mvar can.

I have written many programs that overuse Mvars and have not had throughput issues; it just depends on overall complexity and number of axis, servo interrupt, commutation, etc.

 

Both PLC or PLCC programs need no particular attention to download, the compiler for a PLCC will run automatically so you really don't need to get into the whole compiler settings, link, build thing. Just observe some basic rules as laid out in the user manual and the PLCC programs execute really fast.