Emerson Exchange 365

Hello,

I have the task of updating an old PLC in a plant. I have a copy of the old program, but it is absent of any names and comments. Given that the cabinet is nearly 35 years old, documentation is also scarce.

It is a somewhat simple LD program with 150 rungs. I do know what the hard-wire I/O are (thanks for wire labels!), so I have filled in those names for %I and %Q variables respectively, then using those knowns to back-fill unknown memory variables.

The existing machine is a 90-30, model 331.

In trying to decipher the old program, a few things I cannot quite wrap my head around.

• The biggest head-scratcher for me (likely because I lack old school experience) is the use of BIT_SEQ. I've read the description several times, but the concept (or perhaps the implementation here) doesn't click for me.
  • 
  • I understand the enable, reset, and direction, but the N and ST parameters escape me a bit, or at least the ones used here. N is a constant, and a large number at 393. The description says that N is "the value that the step number is set to when R is energized" and that N must be between 1 and Length, while Length's legal values are 1-256. Given this, 393 is input very specifically, but it would just default to 256 (max Length) or the Length value of 5 here, unless I'm missing something.
    • I believe the 393 is specifically linked to the start of a cluster of 5 (Length's parameter) BOOLs in %M, from 393-397, which are then linked to %Q outputs.
    • Following this, it seems that they used the BIT_SEQ to turn on the Qs via a crank-style bit manipulation vs traditional LD rung logic.
  • Second, the ST argument. When compiling the program, PAC ME gives warnings on all BIT_SEQ (4 of them) in the program, citing a type mismatch on the ST arguments, as they are all provided as BOOL, but expecting BYTE, WORD, or DWORD.
    • I'm assuming that BYTE, WORD, or DWORDs are just suggestions, and really all that matters is the numerical address provided, in this case marked by SV1_V variable, which is address %M00393 - matching the N argument.

Are my assumptions correct here? It looks like they gave the BIT_SEQ the starting address of 393, which is also the address of the ST argument. The BIT_SEQ cranks through the bits to turn on 5 BOOLs. I can understand the effective/technical result here, but I'm not sure why you would choose this method to activate coils rather than traditional rung logic? Perhaps to minimize number of rungs/instructions for sake of memory limitations?

Another question:
Several times throughout the program, a variable will be OR'd with NOT-itself. Like (if VAR1 == TRUE OR VAR1 != TRUE) THEN ....
Again, given that this, at first glance, seems obtuse, I have to assume this might be some facet/restriction of programming in times long ago that I'm not familiar with. My best guess is adding this chunk in as a sort of marker for human visualization purposes, in lieu of a comment.

Another peculiar thing I've found is the use of %Qs in addresses far above where the hard-wired inputs stop.
For example, this application's I/O cards stop at %Q00036, but there exists %Q00203, 204, and 210 in the program. I assume these are used in place of %M, but why? I do not believe %M memory was exhausted... I understand these may simply be idiosyncrasies of a rouge programmer, but curious of there might be some reason (from before I was born!) giving legitimate cause for this.

One more question: this program has pervasive use of ONDTR TENTHS instruction. I understand the purpose of a delay-on-make function, of course, but the kicker is that ONDTR (as I read it) has a cumulative timer, so that it does not reset to the specified parameter when power flow is broken - it holds its value.
I can understand the utility of this in certain applications, but I'm surprised at the exclusive use of this instruction for all timer functions in the program. A few times, the input trigger is inverted, causing it to auto-reset upon power break, or the output will be wrapped around to the Reset.
Given its exclusive use and occasional go-arounds, I can only assume that a plain delay-on-make might not have existed in this era?

Lastly, can I connect to this PLC live via PAC ME? There is some doubt with my colleagues that PAC ME cannot be connected to a 90-30 of fear that it will 'update' something in the PLC, causing it to no longer work with the old software (MS-DOS style stuff). Is there any validity this? To clarify, we (technicians) have PAC ME, the customer only has old software (LogicMaster? I believe?) so do not want to leave site causing unknown problems for customer.

Thanks for the help and tolerance of my many questions.