A single internal pushbutton tag was assigned to call three C-more events, each containing 16 tag-copy actions; the reported result was that only the last two copies in the third event appeared to work. The corrective finding was to use a unique trigger bit for each event, rather than sharing the pushbutton tag across all three calls.
Check which trigger calls each event
Read the event configuration before changing timing or rewriting the copy actions. Record the trigger tag assigned to each of the three events and confirm whether all three point to the same discrete internal pushbutton tag.
- Open each event configuration and write down its trigger tag.
- Compare the three trigger assignments. If they are identical, treat the shared trigger as the first fault to correct.
- If the trigger tags are already unique, continue to the action-list check rather than adding more bits blindly.
In this setup, using one pushbutton bit for three event calls was the configuration associated with the failure, and the resolution was yes: each event needed its own bit. Separate trigger bits make the event calls independently addressable. They also let the operator or the control logic identify which event is intended, instead of asking one discrete state to represent three separate calls.
Do not treat the report as proof that every C-more event configuration behaves identically. Verify the trigger mapping in the actual project. If a shared bit is present, correct that mapping and test before considering polling or button-hold changes.
Check the action list and destination tags
Read all 16 tag-copy actions in each event and compare the intended source and destination tags against the recipe layout. The symptom was initially described as only the final two copies in event three working, but that observation alone does not identify which actions were skipped, overwritten, or never executed. Establish the actual data state after a test before diagnosing the action order.
- Check that each action copies the intended source tag to the intended destination tag.
- Look for repeated destinations when the recipe is expected to populate separate working variables.
- After a controlled call, inspect representative destination values from the beginning, middle, and end of the action list.
Use this symptom-to-check table to keep the diagnosis tied to an observation:
| Observed result | First reading | Next decision |
|---|---|---|
| All three events show the same trigger assignment | Trigger tag on each event | Assign distinct bits, then retest. |
| Trigger bits are distinct, but a copy result is wrong | Source and destination for that action | Correct the mapping or check whether a later action writes the same destination. |
| Only some values change after a call | Values at selected destinations before and after | Determine whether the event call occurred and whether each expected destination changed. |
This separates trigger dispatch from copy-data errors. Changing the trigger cannot correct a source/destination mapping mistake, and editing copy actions will not reliably fix a trigger assignment shared by several events.
Check whether polling or button duration changes anything
Do not begin by holding the pushbutton longer or adding a delay. The original troubleshooting considered slow polling and maintaining the pushbutton state for a few milliseconds. Holding the button produced the same result, so button duration did not correct this case.
A discrete trigger is a state, not a guaranteed record of how many times an event was intended to run. If several actions depend on one shared trigger, extending the time that trigger remains active does not distinguish the three event requests. First correct the trigger association; only investigate timing if the uniquely triggered events still fail under a controlled test.
- Record the current trigger assignment and observed destination values.
- Make the event triggers distinct without changing unrelated copy actions.
- Test one event at a time and inspect its intended destinations.
- Test the remaining event triggers independently, then check whether all expected values are present.
If a trigger does not appear to register, observe the trigger tag state during a controlled press using the project’s available tag-monitoring method. Check how the configured event call is initiated and reset in that project; do not invent a pulse duration or scan-time requirement without measuring the actual system behavior.
Check event sequencing before chaining calls
A proposed workaround was to have the final action in event one set a tag that calls event two. That is a different architecture from assigning a unique pushbutton bit to each event, and its result was not reported. Treat chaining as an option to test, not as the proven repair for the three-event configuration.
If the process genuinely requires ordered execution, define a separate trigger for each stage and make the transition condition explicit. Test the first stage, verify its destinations, then test the condition that starts the next stage. Confirm that a later stage cannot start unintentionally from a trigger that remains set. The project’s event configuration and tag behavior determine how to implement reset and sequencing; inspect them rather than assuming the event manager automatically queues calls.
For a manual recipe-selection workflow, independent event triggers are easier to commission and troubleshoot because a technician can call each event separately. Use chained calls only where the required operation is inherently sequential and the transition can be observed and verified.
Choose a recipe object for the variable count
The application described 16 recipes with 38–40 variables each. The existing machine setup used three screens of variables, and the intended design was to store settings in internal C-more tags by recipe number, then copy the selected recipe’s stored values into the working variables used on the screens.
A Recipe object was suggested as an alternative. The cited Single Source approach was described as writing 0–99 source tags to destination tags from a button push or write event. The stated 38–40 variables per recipe fit within that described source-tag range, but confirm the supported arrangement in the installed project and product documentation before redesigning the data layout. The recipe count of 16 does not by itself establish how the project must organize or address stored values.
Compare the two approaches against the actual operator workflow:
- Keep the internal-tag approach if the project needs recipe values stored in project tags and explicitly copied into the working variables.
- Evaluate the Recipe object if it simplifies storing and transferring the 38–40 values as a selected recipe.
- In either design, test saving one recipe, selecting another, and recalling the first. Verify that values do not leak between recipe records and that all intended working variables receive the selected values.
A Recipe object is an alternative architecture, not a necessary patch for shared event triggers. Fix and retest the event trigger mapping first if that is the failure being addressed.
Restore production with distinct triggers and verify every copy
For the reported configuration, the resolving branch is the shared-trigger branch: assign one discrete internal bit to each event call, then verify the copy results event by event. Keep the change narrow so the test identifies whether separating the calls restores the intended behavior.
- Back up the current project and record the three event-to-trigger assignments.
- Assign a different discrete internal trigger bit to each event.
- Map the operator action or control logic to the appropriate event trigger; do not reuse the same bit for all three calls.
- Call event one alone and inspect representative destinations from its 16 copy actions. Repeat for events two and three.
- After individual checks pass, run the full recipe workflow and compare every expected working variable with the selected recipe values.
The temporary restore is to select the desired event independently and confirm its data transfer before relying on a multi-event recipe operation. The permanent repair is to retain distinct event triggers in the project and document which trigger invokes each event. If the three calls still interfere after separation, stop making speculative timing changes; capture the event configuration, trigger states, and before/after destination values, then contact AutomationDirect official support.
FAQ
Why does only the last event copy data in C-more?
In the reported setup, one discrete internal pushbutton tag called three events, and only the last two copy actions in event three appeared to work. The correction was to give each event its own trigger bit.
Why does holding the C-more pushbutton longer not fix tag copies?
Holding the button produced the same result in this case. Change the shared trigger assignment first; a longer press does not identify which of three events should run.
Does each C-more event need a unique bit?
For the described three-event arrangement, yes. Assign a distinct discrete trigger bit to each event and test each event independently.
Can I call the next C-more event from the previous event?
That sequence was proposed, but its result was not reported. Use it only when ordered execution is required, and verify the transition trigger and destination values at each stage.
When should I stop troubleshooting C-more event calls?
Stop if distinct triggers still produce missing or incorrect copies after you verify each source, destination, trigger state, and before/after value. Provide those observations and the event configuration to AutomationDirect official support.