Machine 1 - Injection Molding Machine
PLC scenario - Beckhoff PLC, as an extension Mistubishi PLC (iQ-R)module also available.

Machine 2 - Andon system control panel, output devices would be TV screens, alarm lights and sirens

Communication protocol - through CC link cable between RJ61BT11 card of machine 1 to RJ61BT11N card in machine 2.

Target case - In case of any error/alarm/breakdown in machine 1, it is required for the alarm no. and alarm description to ne shown on TV connected to machine 2 via RJ71EN71.

Issues - The alarm list with alarm no., alarm descriptions and PLC tag numbers for all possible errors/alarms/breakdown have been provided by machine 1 manufacturer. But machine 2 manufacturer is insisting on PLC bit addresses from machine 1 manufacturer to start communicating.

Please suggest how to proceed with communicating the above said case

 

It sounds like your two vendors are treating the alarm data differently. #1 is expecting an alarm to be signalled/sent from within its program structure by using the tag number or alarm number. #2 is using a data array/block which is expecting the alarm initiating bit address.

Proceed by getting the alarm lists from both 1 & 2 into a spreadsheet and arrange it to show the missing data interconnects. Then get them both ina room and get them to explain how this communication will work with the gaps shown.

 

Is this CCLink protocol? I probably don't understand that application but in general I am always hesitant to use CCLink for anything. It is HUGE in Japan but hard to find here. I would worry here about maintainability. Finding someone that can diagnose problems with that system would be difficult. Is there any other option?

John Rinaldi
Real Time Automation
Author of the Everyman's Gude to Modbus
https://www.amazon.com/Modbus-Everymans-Guide-John-Rinaldi/dp/1517764688

 

I'd push both vendors to agree on a common tag mapping in a spreadsheet before wiring anything—saves endless troubleshooting later.

 

The standoff here is a vocabulary problem, not a technical disagreement — and on classic CC-Link, the Andon vendor is architecturally right.

1) On classic CC-Link there are no tags.

CC-Link (the RJ61BT11 / RJ61BT11N pair you named) is a cyclic bit/word protocol. What crosses the wire is the link devices:

- RX / RY — remote input / output bits
- RWr / RWw — remote register words (16-bit)

A "tag number" or PLC variable name is a controller-side concept — a TwinCAT symbol, an iQ-R label. It has no representation on the wire. So when machine 2 asks for bit addresses, it is not being difficult; it is describing the only thing a CC-Link peer can actually read. Asking machine 1 for tag numbers is asking for something CC-Link cannot carry.

Both vendors are therefore correct about their own side, and neither has stated the interface. That is the missing artefact.

2) What has to be agreed is a link-device map, and it has to be frozen before any code

Write down, and have both vendors sign off:

- Transmission speed (156 kbps ... 10 Mbps) — mismatch = no link at all
- Ver.1 / Ver.2 mode — determines max stations and per-station occupancy
- Station number + number of occupied stations — determines the size of the link range; a 2-station occupancy consumes 32 bits / 8 words per direction
- Which module is the master — classic CC-Link allows exactly one; two masters = dead network
- Bit/word direction convention (whose RX is whose RY) — the two vendors will otherwise disagree about it, and the link will work in one direction and not the other

Then one table, which is the actual contract:

Signal Link device Direction Notes
Alarm active RY bit n M1 to M2 one bit per alarm group
Alarm code RWw word n M1 to M2 16-bit code
Alarm table rev RWw word n+1 M1 to M2 integer / CRC
Andon ack RX bit n M2 to M1 operator acknowledge
Heartbeat RY bit n+1 M1 to M2 toggles ~1 Hz

Once that table exists, "tag number vs bit address" stops being an argument. Each vendor keeps their own tags internally; the link device is the only thing they have to agree on.

3) Do not send alarm descriptions over the link

This is the decision that will make or break it. Descriptions are text; shipping them as ASCII word arrays across a bit/word link means length management, padding rules, byte order and multi-word reads — expensive, fragile, and unnecessary. You already have machine 1's full alarm list with numbers and descriptions.

Send the alarm code only, and keep the description table on the Andon side as a lookup keyed by that code. Consequences:

- The link stays small — a handful of words whether you have 50 alarms or 500.
- Text corrections become a table edit on one side, with no re-engineering of the link or the PLC program.
- The TV/display layer (machine 2, RJ71EN71 side) does the formatting, which is where it belongs.

4) Two things injection moulding will break if they are not handled from day one

- The alarm list changes with the mould. A new tool almost always means new or renumbered alarms. Exchange a table revision number (or CRC) over the link, and have the Andon show a clear "alarm list out of date" state. A wrong description on an Andon is worse than no description — it sends the operator to the wrong place.
- Stale data on comms loss. Add a heartbeat and an explicit "link healthy" bit. On timeout the Andon must fall back to its own local indication and stop trusting the last received batch. A frozen Andon display is dangerous precisely because it looks normal.

5) Andon semantics are worth fixing up front

An Andon is not a mirror of the PLC, it is an operator-facing state machine. Specify: latch and first-out indication, acknowledge, re-flash only on new alarm or clear, and a bounded queue so a flapping bit cannot flood the TV. Otherwise you will commission a working link and an unusable display.

6) To Mr Rinaldi's point — is CC-Link the right bridge at all?

Worth a serious look before committing, because it may dissolve the problem rather than solve it. Your inventory is:

- Machine 1: Beckhoff (native EtherCAT / ADS / Modbus TCP / OPC UA) plus an iQ-R module
- Machine 2: iQ-R with RJ71EN71 — an Ethernet module

If the alarm exchange can be done directly over Ethernet (Modbus TCP or OPC UA between the Beckhoff and the iQ-R), you get named variables at both ends, standard diagnostics, and an architecture any local integrator can maintain — with no CC-Link in the path. The trade-off is a possible change order from both vendors and the loss of cyclic determinism. But an Andon link is non-safety, non-motion and tolerant of tens of milliseconds — deterministic cyclic I/O is not actually a requirement here. That makes the Ethernet route worth pricing before you commit to a CC-Link contract you will have to live with for the life of the machine.

If both vendors refuse, CC-Link it is — and then item 2 becomes mandatory rather than good practice.

Two questions that would let me be more specific:

1. Between machine 1's Beckhoff and its iQ-R module — how do those two exchange data today? That link is itself a vendor boundary, and the "tag numbers" you were given probably live there.
2. Is the Andon logic running inside machine 2's iQ-R, or in a separate controller/PC behind the TV? That determines whether the link terminates in the PLC or in software, and it changes where the description lookup should live.

 

We had a similar addressing mismatch, and using Real-Time Digital Andon System smoothed it out by handling the protocol translation and displaying alarms directly. It works across different PLC brands.