Tag a CLICK counter value on a C-more Micro panel

Why does the C-more Micro reject my CLICK counter tag?

The panel rejects the tag because a CLICK counter accumulator is not a plain register address. The C-more Micro carries the counter value under its own device name, CTDx, and expects the tag's data type to be Signed Int 32. Address spellings copied from ordinary registers fail for that reason.

A counter in the CLICK holds its current count in an accumulator. The panel's device list exposes that accumulator as a selectable device in its own right. A tag built on a data register address or on typed text is refused as an invalid address at creation. Both settings have to be right at once: the type Signed Int 32 and the device CTDx. Miss either one and the editor refuses the tag. That is why a counter that behaves perfectly in the CLICK software can still throw the rejection. C-more panels reject device tags for a few other address-shaped reasons as well, and the page on why C-more rejects B3:0/0 and how to fix device tags covers that wider pattern.

What data type and device does a CLICK counter tag need?

Set the data type to Signed Int 32 and pick CTDx as the device, with x matching the counter number: CT1 takes CTD1, CT2 takes CTD2. The panel then accepts the tag and shows the accumulator's live value.

In the tag editor, choose Signed Int 32 first. Then open the device list and select CTD1. Pick the device from the list instead of typing an address, because typed spellings are what produced the rejection. Confirm the tag in the editor before binding it to any screen object. If the list shows no CTD devices at all, check that the panel project's controller connection is set to the CLICK, because the counter devices appear only under that connection. The order in which to fill the tag's fields is the same order used to set an HMI tag device and PLC address without guessing. If the data type field itself will not change, fixing a greyed-out HMI tag data type is a separate editor problem with its own article.

Recommendation: Set the tag's data type to Signed Int 32 and select CTD1 from the device list for counter CT1, CTDx with the counter's own number otherwise. Fall back to the CPY-and-DD-register copy only when the editor still rejects the counter device, because the direct device stays the simpler one to maintain.

Why signed and not unsigned for a counter that only counts up?

Choose the data type from the device the panel lists, not from what the counter counts. CTDx pairs with Signed Int 32, a 32-bit signed span of −2,147,483,648 to +2,147,483,647 counts. The unsigned 16-bit guess tops out at 65,535 counts.

The guess comes from habit with smaller PLC families whose registers are 16 bits wide. A four-digit count fits there with room to spare. CTDx is not one of those registers: the panel's device list binds it to the signed 32-bit type, so the unsigned selection is what fails. The arithmetic behind the span: 32 bits hold 2^32 = 4,294,967,296 patterns, split evenly either side of zero, which gives the two limits quoted above. The CLICK trips other data-type mismatches on this panel family too, another being BCD values against Unsigned Int 16, worked through on the page resolving C-more Micro HMI BCD versus Unsigned Int 16 on CLICK PLC. And when a mismatched type does get through and the panel prints large positive numbers, the repair is the signed decimal data format described in the article on an HMI that shows large positive numbers.

What do the symptoms tell you before you change anything?

A rejected tagname on a counter that counts and resets correctly in the CLICK software is an HMI-side address problem. Work this list from the top before touching counter logic.

• Tag creation fails with invalid address and the counter behaves correctly in CLICK: wrong type or device. Set Signed Int 32 and pick CTDx.
• CTD1 does not change in the CLICK software while the machine cycles: the fault is upstream of the panel, in the count input, the reset logic or the counter rung. Fix the PLC side first.
• Tag accepted but the screen number sits frozen at one value: the tag is probably fine and the screen object is bound wrong. Check the object's numeric value field.
• Tag accepted but the panel prints large positive or nonsense numbers: data format mismatch. Set the signed format.
• Tag accepted but the count follows a different machine or jumps oddly: the tag points at the wrong CTDx number. Recheck that x matches the counter number.

How do I display the count when the panel still rejects CTD1?

Copy the accumulator into an unused DD register with a CPY instruction in the CLICK program. Tag that register with Signed Int 32. The panel then reads the copy with the same width and sign the direct CTDx tag would have used.

The copy works because a DD register is an ordinary device the panel's list accepts. Put the CPY on a rung that executes every scan while the machine runs, so the copy tracks the accumulator. A CLICK scan runs in the low milliseconds, so a machine cycling at 120 counts per minute gives the copy dozens of updates between counts, and the panel never shows a stale number. The source operand is the counter accumulator, the CTD1 value itself, not the set-point or another counter field. Pick a DD address nothing else in the project uses, take it from the project's register allocation, and record it so the tag and the logic stay aligned. Before trusting the panel, watch CTD1 and the DD register together in the CLICK software through a few counts and one reset: the two numbers must match at every step. Then point the tag at the DD register with Signed Int 32 and bind the screen object's numeric value to that tag.

Example: one counter from tag to screen

In this scenario a single counter, CT1, counts production cycles with its set-point at 9,999 counts, and the machine runs at 120 cycles per minute. The C-more Micro tag takes data type Signed Int 32 and device CTD1. After 2,500 cycles the CLICK accumulator, the tag and the screen all read 2,500 counts.

The arithmetic behind the type: 32 bits hold 4,294,967,296 patterns, and the signed split gives a highest positive value of 2,147,483,647 counts. The 9,999-count set-point uses 9,999 ÷ 2,147,483,647 ≈ 0.0000047 of the positive span, about 0.0005%. The type is never the limit on this counter. The reset interval follows from the rate: 9,999 counts ÷ 120 counts per minute ≈ 83 seconds, so the operators see the screen return to 0 about every 83 seconds. One reset runs like this: CTD1 climbs 9,997, 9,998, 9,999 counts, the rung logic resets the counter, and the accumulator, the tag and the screen return to 0 together. In the copy variant, the CPY rung moves the same 2,500 counts into the chosen unused DD register on every scan, the DD tag reads 2,500, and the reset takes accumulator and copy to 0 on the same scan. Where that number sits on the screen and how tall the digits print is a layout question, covered in displaying a PLC counter value where operators can see it.

How do I check the tag before calling the display fixed?

Operate the machine through several counts and one reset; at 120 cycles per minute, 15 minutes of running covers about 1,800 counts and roughly two full resets. Then compare three values at each step: the live CTD1 in the CLICK software, the tag's live value in the panel software, and the number printed on the screen. All three must change together.

A tag the editor accepts and a screen that shows the count are two separate configuration steps. Bind the screen object's numeric value field to the tag: an object configured only as an indicator state will sit at one value while the tag moves under it. Watch one full reset too, because a panel that holds its last count after the PLC returns to 0 sends operators back to the counter rung for nothing. For the DD-copy route, add the register as a fourth value in the comparison. If the tag value moves and the screen does not, the object binding is the fault. If the tag value does not move, the type or the device is.

What does the 9,999 set-point actually do?

The set-point is the threshold your CLICK rung logic acts on, not a tag setting. At a 9,999-count set-point, whether the counter resets, stops or keeps counting is decided by the rung, so watch the accumulator reach the set-point once and note what your program does.

A count-up counter compares its accumulator with the set-point and raises a done output when the accumulator reaches it. What happens from there, reset, stop or keep counting, is whatever the rung does with that output. In the setup described here the program already counts and resets correctly, so the threshold logic works and needs no change. Keep the two problems apart while you work: the invalid address is fixed by Signed Int 32 and CTDx, and any behavior you want different at the threshold, an earlier reset or a second output for example, is a change to the rung. Changing the set-point will not make a rejected tag valid.

Questions