Technical Specifications for IC695CMM002

Technical Information

Specifications:

Troubleshooting

Troubleshooting IC695CMM002

Troubleshooting information is available on IC695CMM002's website page; it also includes a datasheet user-manual and a wiring diagram.

Repair your IC695CMM002

PDF Supply can repair your IC695CMM002 in 3-5 business days. And PDF Supply stands by all of its repairs with a 1 year customer satisfaction warranty.

How to Optimize Communication With The IC695CMM002/004

Description

IC695CMM002/004 allows the RX3i to work as Master in Modbus communications. Depending on how the configuration or programming have been done, the performance of communications can be acceptable or slower.

Resolution

Some tips regarding how to optimize the communications:

• Group the information in the remote device minimizes the number of exchanges. This have two benefits:

- As the number of exchanges are limited to 64 per port, there will more exchanges available for additional remotes devices

- the communication frames take almost the same time, querying for one word than for the maximum allowed.
 

• When possible, use Read/Write Single Bit Control. This allows to manage when the program will trigger the communication frame and it is possible prioritize some exchanges. In addition, if an error has been detected in the remote station, the program can avoid to set the bit, prioritizing communications for other active devices.

• Avoid using Continuous Write/Read. The CPUs does not control this exchange. So if the remote device is off, all the other exchanges will be delayed until the Timeout error happens. Except if the remote target needs to be written every time, it does not make sense to write always if the data in the master have not changed

• As an intermediate solution Read/Write Continuous Bit-Control can be used. They allow the program to trigger or stop the exchange when needed. So it makes easier to control the exchange but it allows to stop the exchange if the remote device is off.

• If the module is expecting to receive data and it hasn't received data before this assigned timeout period, a receive timeout error occurs for the exchange being processed. Set a Timeout according to the communications system and baud rate. ie. for wiring systems 1 sec can be enough; radio systems are usually slower, so greater values should be chosen.

IC695CMM002/004 and Modbus RTU Protocol Weakness

Description

The implementation of the Modbus RTU protocol on the CMM002/004 module utilizes the specified 3.5 character silence to recognize an end of message. ; Since radio systems are notorious for dropping characters and injecting delays in the data stream, this can cause significant problems that care must be taken to avoid, when designing the system. Below is an explanation of how data can be placed into the wrong memory location due to dropped bytes and time delays injected into byte streams. See the detailed case study below:

First of all it is critical to understand that the Modbus RTU protocol is specified in such a manner that the response to a Read Holding Register request(or any other request for that matter) has no identifying information other than the Station ID, Function Code, and Data Length. This is a protocol weakness. Feel free to visit the Modbus.org website and download the protocol specification for the protocol details.

Consider this scenario:.

1. Master sends read %R101, length 100 - radio delivers in tact
2. Slave replies with 200 bytes of data (it is important to note there is no address in this response)- radio delivers in tact
3. Master moves data to %R101-200
4. Master sends read %R201, length 100
5. Slave replies with 200 bytes of data (it is important to note there is no address in this response)- radio delivers in tact
6. Master moves data to %R201-300
7. Master sends read %R301, length 100
8. Slave replies with 200 bytes of data (it is important to note there is no address in this response)- radio drops bytes and introduces 6 ms Delay thus braking the frame
9. Master sees broken frame, raises RTS, gets CTS back, clears receive buffer, logs error and sends read %R401 length 100 - radio delivers intact
10. Master sees second part of broken frame as a response to the %R401 read, sees it as an error (one could argue for length error or CRC error but either way it is seen as a bad response), master sends read %R501 length 100 - radio drops bytes or adds delay in request THEREFORE SLAVE NEVER SEES REQUEST FOR %R501, HOWEVER
11. Master almost immediately sees response (which happens to be the response to the read of %R400), and of course has no idea of the address due to the protocol limitation and correctly places the 200 bytes received into the outstanding request to read %R501 into memory.(note that the request for %R401 has already failed and been cleared and reported as an error) This is where the protocol limitation becomes an issue. This is not a GE IP issue on the CMM card at this point, because it acted appropriately given the data stream provided by the radio.
12. Master sends read %R601 length 100 - radio delivers intact
13. Slave replies with 200 bytes of data (it is important to note there is no address in this response)- radio delivers in tact
14. Master moves data to %R601-700
15. Master sends read %R701 length 100 - radio delivers intact
16. Slave replies with 200 bytes of data (it is important to note there is no address in this response)- radio delivers in tact
17. Master moves data to %R701-800

Notice that in steps 9 and 10, there are two back to back failures of the radio system in the sense that it was not able to deliver the response message intact and when the next request was made, it was not able to deliver that request intact to the slave. This is one scenario that could lead to data being placed in the wrong register memory.

Resolution

There are a couple of ways to prevent this from occurring.

1) Do not send multiple back to back requests to the same slave, of the same function code, and data length. If the data length is changed, any response with the correct data length, due to dropped bytes, would not pass the CRC check.

2) Alternate slave id's and function codes for each slave, as these will be unique identifiers contained in any response in the protocol. In other words, if the master were waiting for a response from slave x for function code x, and it sees a response from slave y with function code y, the master will recognize the slave and/or function code as being different from the outstanding request and terminate it with an error.

3) Write logic to control the master request timing, and monitor each request result in order to programmatically insure enough time has passed to prevent such a timing error, since the master should clear its receive buffer before sending a new request and thus again avoid the protocol limitation.

4) Read data into intermediate memory and provide unique identifiers in the data stream that can be used in logic to move the data to the proper location. Although this method may take the most effort, it is the most reliable way to be sure the data is placed in the correct reference memory on a response by response basis. In this case, even if the response were to a different request, your header information in the data stream could include the responding slave number and memory type and length so that your program can properly distribute the data. In fact, this method provides a form of data correction in the sense that a misinterpreted response will be placed in the correct memory location rather than being thrown away causing further delays in updating the data. Similar methods can be used to broadcast slave data as well, increasing your throughput by reducing the number of writes.

Customer Questions and Answers

• Question:  What is an IC695CMM002?  Answer:  The IC695CMM002 is a Serial Communications module from the GE Fanuc RX3i Series.
• Question:  What does IC695CMM002 do to the RX3i system?   Answer:  This module expands the serial communications capabilities of the RX3i system.
• Question:  What does IC695CMM002 provide?  Answer:  This module provides 2 independent, isolated serial ports. 
• Question:  How many modules can be located in the main PACSystems RX3i backplane?  Answer:  Up to 6 modules can be located in the main backplane.
• Question:  What can the configuration be for each port?  Answer:
  • Each port can be configured for MODBUS Master, MODBUS Slave, or Serial I/O protocol.
  • For modules that are version 1.10 or later, each port can be configured for CCM Slave protocol using Proficy Machine Edition 5.6, SIM 6 or later.
  • For modules that are version 1.20 or later, each port can be configured for DNP3 Master or DNP3 Slave protocol using Machine Edition 5.6 SIM 10 or later.
  • If any port is configured for DNP3 Master or Slave, the other ports on the module can only be configured for DNP3 Master or Slave.
• Question:  What are additional features on IC695CMM002?  Answer:
  • Port-to-port isolation and port-to-backplane isolation
  • RS-232, RS-485/422 communication, software-selected
  • Hardware handshake: RTS/CTS for RS-232
  • Selectable Baud Rates: 1200, 2400, 4800, 9600, 19.2K, 38.4K, 57.6K. 115.2K
  • Module fault status reporting (Watchdog, Ram Fail, Flash Fail)
  • Module identity and status reporting, including LED status indicators
  • Meets CE, UL/CUL 508/1604, and ATEX requirements
  • Flash memory for future upgrades
• Question:  Where must IC695CMM002 be located?  Answer:  IC695CMM002 must be located in an RX3i Universal Backplane. 
• Question:  What should I do if my IC695CMM002 is not working properly?  Answer:  Your IC695CMM002 may need repair.

For more information on the IC695CMM002 Serial Communications Module of the GE Fanuc RX3i Series, please see the Datasheet User-Manual.

Release Information

Release 2.00 is a new HW and FW architecture created to address obsolete components and ensure EU RoHS compliance.

Release History