LogicMaster 90 NickNames and blocks

I'm developing logic for a machine that has several identical zones. The logic for each zone is identical, with only the addresses being different. I intend to program each zone into its own block and then call each block from the Main ladder. I've pretty much finished the logic for the first zone block, complete with nicknames (and annotations). I intend to use the same nicknames within all of the zone blocks, since the functions of the instructions are identical within each zone.
So, my question is: is there a way to copy my logic into the remaining blocks so that the nicknames stay the same, and the addresses will automatically update to what the names are referencing in the new block's variable declaration table? Or, am I stuck manually re-addressing every instruction on every rung in every block?

Here's what I've tried:
I've been importing nicknames/annotations from .csv
I write my block to a file
I go to my new block and import the file and the variable declarations (I've tried one first and then the other - and vice-versa)
LogicMaster always imports the addresses (and not the names) from the file, and since the names from the original block are out of scope, only the raw addresses (from the original block) are shown.

Thanks in advance for any tips - I have a lot of manual editing (and chances for errors) coming up if there's no way around this.

First, there a lot more options for managing your variables if you use Proficy Machine Edition instead of Logicmaster.

Under Logicmaster, "Nicknames" are tied to a specific address. You can use the nickname interchangeably with the address. Consequently, there is no way to assign the same nickname to two different addresses. The reference description is not subject to the same restrictions as the nickname. The same reference description could be assigned to multiple addresses.

Also remember that the "Cut" / "Paste" and "Write" / "Include" capabilities work within the variable declaration tables just as they do for ladder logic. You might be able to make use of that capability.

It might be easier if you assigned a block of addresses for each zone and just write a single block of logic. Prior to calling the block for a given, use MOVE instructions to copy the zone's addresses to the references used by the block. Following the CALL statement, use MOVE instructions to copy the new states and values established by executing the block logic back to the zone's addresses. Lather, rinse, repeat for each zone.

Oversimplified example: A zone uses 16 inputs %I0001 - %I0016 and 16 outputs %Q0001 - %Q0016. Your block logic uses %M0001 - %M0016 for the inputs and %M0017 - %M0032 for the outputs. Second zone uses inputs %I0017 - %I0032 and outputs %Q0017 - %Q0032.

         _________         ___________       _________

        |         |       |           |     |         |

        |MOVE_WORD|       |CALL BLOCK |     |MOVE_WORD|

--------|         |-------|           |-----|         |

        |         |       |___________|     |         |

        |  LEN=1  |                         |  LEN=1  |

        |         |                         |         |

%I0001--|         |--%M0001         %M0017--|         |--%Q0001

        |_________|                         |_________|

 

         _________         ___________       _________

        |         |       |           |     |         |

        |MOVE_WORD|       |CALL BLOCK |     |MOVE_WORD|

--------|         |-------|           |-----|         |

        |         |       |___________|     |         |

        |  LEN=1  |                         |  LEN=1  |

        |         |                         |         |

%I0017--|         |--%M0001         %M0017--|         |--%Q0017

        |_________|                         |_________|

You've got to be careful about about timers, one-shots and latches when using an approach like this.

I like that approach, but my zone blocks are pretty timer intensive - even if I copy all three words of each timer somewhere and put them back next time it's that zone's turn, I can see where it would be somewhat unpredictable.
I'll try playing with the file that it writes out when I do a write and see what I come up with....

What I wouldn't give for a bit of indirect/indexed addressing right now...

ogimoj said:

What I wouldn't give for a bit of indirect/indexed addressing right now...

Click to expand...

How about the price of upgrading from LM90 to Proficy ME?

What I wouldn't give for a bit of indirect/indexed addressing right now...

Click to expand...

I assume that means you're using a 90-30 and not a 90-70. The closest thing to indirect addressing available on the 90-30 platform are the ARRAY_MOVE and ARRAY_SEARCH instructions. The 90-70 supports indirect addressing.

BTW, RussB's comment is simply a bit of whimsy. Upgrading from Logicmaster to Proficy ME, while advisable, will not add any new capabilities like indirect addressing to an existing 90-30.

You could use the technique I outlined with the timer registers. As long as you called the program blocks for each zone every PLC scan there should be no problem.

The reason is that the third of three timer registers contains the 'fractions' of timer increments. As an example, consider a timer with 100 mSec resolution (TMR_TENTHS) operating in a PLC with a scan time of 9 mS. Each scan when the timer is evaluated, the function adds the elapsed time since the last scan (9 mS) to the value in the third register. If the result of that addition is greater than 100 mS, the function adds 1 to the value in the first register (the accumulator) and subtracts 100 mS from the number in the third register. If you don't evaluate the timer every scan you'll get inaccurate results.

Steve Bailey said:

BTW, RussB's comment is simply a bit of whimsy. Upgrading from Logicmaster to Proficy ME, while advisable, will not add any new capabilities like indirect addressing to an existing 90-30.

Click to expand...

What it adds is the logic 'linking' through the Toolchest that makes 'identical' logic very quick and easy. by handling the timer/counter problems.

I'm stuck with LogicMaster - at least for the project I'm currently working on. Yes, I am dealing with a 90-30. I was assuming that the third word of a timer included the mechanism for keeping track of how much time had passed (in addition to the state bits), so thank you for verifying that. It's easy enough to call the block each scan for each zone - so it looks like the timers should work. You also mentioned that oneshots and latches could be tricky.

It would seem to me that the latches will take care of themselves. If I ---(S) a bit inside the block, that will get copied to a %M somewhere in the MOVE after returning from the block. In the next scan, I'll move that word back in to the memory area that is used by the block, and then call the block. inside the block, unless I have an ---(R) somewhere, there's nothing that ever resets that bit low.

I don't recall using any oneshots in the block, but if i do, then there's another issue:
in other PLC's that I'm accustomed to, the programmer explicitly specifies where the memory for a oneshot is stored - so that on scans following the initial transition (false to true or true to false - depending on which type of oneshot) the plc will "remember" that the oneshot has already triggered. So on these other PLCs, a oneshot has two addresses associated with it - a memory, and an output that actually does the one-scan "shot". In the 90-30, only a single address is specified - the address that will trigger for one scan. How does it remember that a onshot has already triggered on a previous scan?

The 90-30 maintains a 'transition table' for discrete memory. For one shots and latches the CPU can use the status of the bit in the transition table in addition to the logic controlling a coil instruction to determine what to do.

Example of a latch: Starting with the transition table value false. In the rung with the -(S)- coil, if the logic preceeding the coil is true, then both the 'normal' and the transition table status will be true. Subsequently, when the logic preceeding the coil is false, but the transition table status is true, the normal table status will also stay true. The transition table status won't go false until the -(R)- coil logic is true.

Example for one-shots: Starting with transition table status false. When the logic preceeding the -(P)- coil is true, set both the transition table and the normal table status true. In subsequent scans, as long as the logic preceeding the -(P)- coil remains true, keep the transition table status true, but make the normal table status false. When the logic preceeding the coil goes false, set the transition table status false.

I think you're probably right about the latches. Before committing to the approach, I would do a little experimenting with various scenarios to make sure I fully understand all the fine points.

From the 90/30 Instruction Set Manual (referring to the MOVE instruction):

...
If data is moved from one location in discrete memory to another, (for example, from %I memory to %T memory), the transition information associated with the discrete memory elements is updated to indicate whether or not the MOVE operation caused any discrete memory elements to change state.
...
For the BIT type there is another consideration. If a BIT array specified on the Q parameter does not encompass all of the bits in a byte, the transition bits associated with that byte (which are not in the array) will be cleared when the MOVE_BIT recieves power flow.

Click to expand...

So, that confirms the conclusion that we came up with: oneshots would break. Of course, it's easy enough to "roll your own" oneshot with a %M bit to hold the transitional data.

Thanks for the interesting conversation. I've decided to keep separate blocks for the different zones, simply because the blocks are only 15 to 20 rungs long, and the I/O will not be wired contiguously. (Zone 1 uses inputs 17, 23, 29, etc.; Zone 2 uses 18, 24, 30, etc...)
By the time a got everything lined up into the right spot before calling each block, I will have created almost as much logic before and after the call as I have in each block to start with.
But... I have the same situation on another machine in which each block will have a byte of contiguous input and a word of contiguous output. It's just begging to have this trick implemented