Migrating from an IC693RTM705 to an IC695CMM002

Recently, I had the opportunity to assist a customer in migrating their 90-30 to a PACSystems RX3i controller.  Machine Edition made quick work of converting the hardware config and code, however 1 particular module posed a problem; this customer was using a Horner HE693RTM705 Modbus Master.  The RX3i does not support this module and its functionality has been replaced by the IC695CMM002.  Looking over the code for this, the conversion appeared daunting at first, but with a couple of handy resources and a spreadsheet or two, the conversion was relatively painless.

Before getting started on the conversion, it is imperative you have the following materials at your disposal:

• Users Manual for the HE693RTM705
• IC695CMM002 Manual (Login Required)
• Lots of Coffee, or other similarly caffeinated beverage
• Good ol’ Microsoft Excel

The first step in our conversion process is to determine what our RTM705 is actually doing.  This is probably the most time consuming process and will require a lot of cross-referencing.  Make sure your spreadsheet is ready and your coffee topped up.

The RTM705 uses a communication request to handle all of it’s communications.  If you are not familiar with this instruction I highly recommend a quick read of the Machine Edition help to brush up on how it works.  To find where this instruction resides in the code, do a quick search and in the search dialog box type “COMM_REQ”, this will search through your entire program and give you a list of all of the communication request instructions in your feedback zone.  Double click on a search result to jump to that portion of logic in the editor.

Step 1: The COMM_REQ

Example COMM_REQ Instruction

The COMM_REQ instruction has 4 inputs to it, the enable, IN, SYS and the TAS.  The enable input is what triggers the COMM_REQ to execute, this is typically delayed by a small timer as the RTM module takes a little bit of time to come online when the PLC first starts up.  The IN input will have an address assigned to it, this is where the brunt of our configuration resides and where our spreadsheet will come in handy.  Jot down the address for future use.  The SYSID input lets us know the rack/slot location of our RTM module, this will be in the format 16#0R0S (hexadecimal, rack/slot).  This lets us know where on the RX3i this module must reside, in our example we have a SYSID of 3, meaning the module is located in Rack 0 Slot 3.  Go ahead and add the CMM002 to the hardware config in this location.  Lastly we have the TASK, this will be one of either 16#65 (port 1) or 16#66 (port 2), this may also be expressed as a decimal 101 (port 1), or 102 (port 2).

In my customers scenario, there was only 1 COMM_REQ function as they were only using port 1 (see example, TASK is 101), other situations may have multiple COMM_REQ functions, 1 for each port.  In that case these instructions would have to be followed for each COMM_REQ.

Now comes the hardest part.  Determining exactly what the COMM_REQ actually does.  In order to do this, we need to dissect the address of our IN (%R471 in our example).  These series of registers actually sets up our COMM_REQ and tells it how to behave (baud rate, number of slaves, etc), so our next step is to search through our Machine Edition software for instances where %R471 is being used.  If we are lucky it should be used in a block move statement (BLKMOV_WORD).  Double click on this in the feedback zone to jump to that location in logic, and hopefully you will see something like this:

Example COMM_REQ Setup

According to the Horner manual (pg 27), the addresses equate to the following:

Several important pieces of information need to be extracted from these registers.  The first is our port configuration, we see from Address + 6, Address + 13 and Address + 14 that our port is configured as RS232, 19200, 8/Even/1.  This information can be added to our Port 1 configuration of the CMM002.

Step 2: Slave Control Blocks (SCB)

Next, we need to determine how many devices we are talking to, as well as their configuration setup (node ID etc).  From our COMM_REQ, we see that we have 1 SCB (slave configuration block), which makes sense as we are using RS232 communication, so we would only expect to see 1 slave.  In the event of RS422 or RS485 communication, there may be multiple SCB’s, 1 per slave.

To determine the setup of our slave, we look to %R295.  Notice that our SCB pointer offset is 294.  As this is an offset from 1, our SCB starts at %R295.  Examining the contents of our SCB yields the following:

The configuration of Dial Strings using the CMM002 is out of the scope of this HOWTO, so the primary things to take note of is Address + 3. This is our slave ID, and as mentioned before, there may be several of these in sequence, be sure to jot down each slave ID we will be working with. Our example only has a single slave using ID 1.

We now have our port configuration, as well as a list of all of our slaves, it’s time to take a nice break and enjoy some of our coffee before we continue on to the last part of our HOWTO, the MCBs.

Step 3: Message Control Blocks (MCBs)

This is where excel will come in to play heavily.  Looking at our COMM_REQ setup, Address + 10 tells us how many MCBs we have (how many distinct reads/writes we will be performing).  As you can see from our example, we are using 28 distinct read/writes (this is not uncommon in larger programs, those with multiple slaves may have many many more).  Address + 11 and Address + 12 tell us the series of addresses where our MCBs begin, in our case %R501.  As with the SCB from earlier, note that our value is 500 which is an offset in the register domain from base address 1, thus giving us a final address of %R501.  Using the Machine Edition search and searching for usage of %R500 yields logic that looks a little something like this:

An Example MCB Configuration showing 3 MCBs

This, like most of the other information, needs to be cross referenced against the Horner manual to determine exactly what it is saying.  Analyzing MCBR1 against the manual on page 24 yields the following:

As with all of our other configurations, notice that the RTM705 uses an offset, so we need to add 1 to get the actual address.  This MCB tells us that we are taking the values in %R300 – %R304 and writing them to slave ID 1, into the address space 40201 – 40205.  As your system probably has many MCBs which could be writing to 1 or more slaves, you can see why excel is a very, very good idea here.

Once we have this information it is quite trivial to transpose this into the CMM002.  When the hardware config portion of the CMM002 was designed, the MCB structure was taken into account, so you will see that the CMM002 needs to know whether we are reading or writing, to what address space, the address, the PLC address to write from/read to, as well as a length.  The figure below shows several entries based on the MCB from above.

Example CMM002 Port Data

Step 4: The Finishing Touches

We’re almost there!  Hopefully you still have some coffee left as we are not quite done.  Once we have setup our Data Exchanges it’s on to the physical changes.  The RTM705 used a rather large 25 pin connector which hung off the unit and routinely got caught, pulled, or ripped out.  The CMM002 uses a much sleeker RJ45 connector, allowing you to plug the cable directly into the unit and easily run it through your existing wireway.  The downside to this is that you will need to make new cables.  The CMM002 manual on page 26 has an excellent pinout diagram that will assist you in creating RS232, or RS422/RS485 cables.

Last but not least is to modify your logic.  If your existing program was executing reads/writes as fast as possible with no on/off control, you merely have to disable this logic (we recommend a normally open contact with %S8 to disable it instead of deleting it, at least until we have tested), however if you have conditional reads and writes, we are on to the bit control.

You will notice while setting up the data exchanges that the operation has a total 0f 6 available options, this allows you to fine tune your communications.  If your communications media is not always available, you can use bits to control when to perform each read and write.  In our example reads and writes were being performed as fast as possible all the time so bit control was not required, however for those of you who do require bit control, the settings tab lists the IO addresses being used for bit control.  You will notice there are 128 bits in the Port 1 Data Control section, this allows us to enable/disable each Data Exchange individually.

In our example our Port 1 Data Control is set to %Q385, so if we wanted to conditionally enable or disable our Data Exchange 1, we would set it’s operation to Bit Control Write Continuous, instead of write continuous.  This would cause Data Exchange 1 to write continuously as long as %Q385 was logic true, if %Q385 was logic false, we would not write at all.

There are a lot of additional status and control bits available in the CMM002 that allow you to tailor your application to suit your needs, however to describe them all is beyond the scope of this HOWTO.  The CMM002 manual has an excellent writeup on all their functions starting on page 89.

Final Thoughts, Cautions and Considerations

Overall, the transition from the RTM705 to the CMM002 was rather smooth for my customer, having spent a couple of hours transposing the information and re-cabling the module (this included several coffee breaks), however each installation is quite different so I highly reccomend you have the aforementioned manuals available when you do the transition.  Also there are a couple of gotcha’s and considerations I will note here:

• The RTM705 supports up to 1024 MCBs.  This is an extremely large amount of data, the CMM002 will only support 64 Data Exchanges per port.  You may need to consider consolidating Data Exchanges, or alternately moving slaves to a different port to balance the Data Exchanges.
• The RTM705 uses an offset addressing structure, the CMM002 does not.  When reading an address in the code for the RTM705, remember that is an offset from address 1.  If you read 299, it actually means 300.  When transposing this to the CMM002 you will need to put in 300, otherwise your code will not work as expected.
• Status words/bits are your friend.  We didn’t really touch on the status words, but they provide a wealth of information and are the first place you should go if your data transfers are not working as expected.
• If at first you don’t succeed, you either need more coffee or perhaps a bigger hammer, however I personally wouldn’t recommend the hammer.