The event timer belongs to the device that transmits the PDO, so a CANopen master at transmission type 254 with a configured event time still sends its command PDO only when the mapped data changes. Hold the payload constant, capture the PDO identifier for 2 seconds, and put the timing on the producer side: the CANopen manager's documented PDO scheduling or an explicit send from a timed task.
A configured event timer can only ever schedule the device that transmits the PDO. That one rule explains the fault: your drive transmits its status PDO, so its 500 ms event timer fires and those frames arrive on schedule; the master transmits the command PDO, and the manager's producer has no timer applied to it, so it sends only when the mapped data changes. Transmission type 254 with the same value entered in both directions describes two different producers, not one symmetric setting. The way out is a bus capture filtered by the command PDO identifier, which settles the producer roles in one 2 second window, followed by producer-side scheduling: the CANopen manager's documented PDO timing, or an explicit send request from a task timed to that same interval.
The event timer belongs to the producer
In CANopen every PDO has one producer, the device that puts the frame on the bus, and one or more consumers. The CANopen communication profile places the timing that can force a transmission on the producer's transmit record: the transmission type, the event timer and the inhibit time. The event timer counts elapsed time with no transmission, and when it expires the producer sends the PDO even if no mapped value changed. That is exactly the behavior you see from the drive: its status frames arrive on its own schedule or on change, because the drive reads and applies its own transmit record.
The command frame travels the other way, so the producer is the CANopen manager in the master, and the record on the drive for that frame is a receive record. Identical values on the two records look symmetric in a configuration tool; they configure two different devices with two different send policies. A receive record on the drive has no mechanism that makes the manager transmit, so an event time entered on that side schedules nothing.
Transmission type 254 only classifies the producer's event. The profile defines 254 as asynchronous with a manufacturer-specific event, which on most drives and managers means a change of the mapped data. Choosing 254 and entering an event time on a receive-side record cannot create a periodic send, wherever the value ends up.
Symptoms and what each points to
- Command frames appear only right after a mapped value changes: the manager's producer is change-of-state, and no producer event timer is active on it.
- Status frames from the drive arrive at the configured interval or on change: the drive's producer timer is working. Use it as the reference timing in the capture.
- The identical send pattern on two different CAN adapter makes: the send policy lives in the manager software. The adapter only moves frames between the PC and the bus.
- Command frames stop appearing entirely, even on data changes: a communication state problem. Check the operational state and the manager's node status and guard time supervision, which is the documented way a silent slave gets flagged.
- The trace shows the command frame but the drive ignores it: identifier, mapping or drive operating state. That is a different fault; stop adjusting timers.
Confirm it with one filtered capture
A variable changing in your program shows only that the application updated its data. The capture is the evidence that a frame left the adapter.
- Fix the identifiers first. The profile's pre-defined connection set gives a device's first receive PDO the identifier 0x200 plus its node-ID, and its first transmit PDO 0x180 plus the node-ID. An EDS file or your manager configuration can override both, so take the active values from the EDS or read them back over SDO; the notes on CANopen SDO block transfer support and troubleshooting cover how those reads behave.
- Reach the operational state with no active communication fault, and write down the runtime, CANopen manager, adapter driver and drive firmware versions.
- Change one command value under controlled machine conditions and confirm the command frame appears. This proves the filter is on the right identifier.
- Hold the command payload constant for 2 seconds, four of the configured event times, and filter the trace by the command PDO identifier alone. Count frames from the timestamps; total bus traffic hides the missing ones. If reading PDO traces is new to you, the page on tracing CANopen heartbeats, SDOs and PDOs walks the workflow.
- Capture the drive's transmit PDO across the same window with the process held steady so its payload is constant too, and compare the two counts.
- Read the drive's active PDO communication parameters back over SDO and compare them with the offline configuration; resolve any difference before you change the sending strategy.
Worked example: a 500 ms command PDO held constant for 2 seconds
The case: a CODESYS Control Win V3 x64 runtime with its CANopen manager, a CAN adapter and a frequency-inverter slave, both PDO directions at transmission type 254 with an event time of 500 ms.
Inputs. Command PDO identifier 0x20B, from the pre-defined connection set default of 0x200 plus node-ID, with node-ID 11 taken as the example value; read your own node-ID from the drive's address setting. Event time 500 ms, the configured value on both directions. Capture window 2 s, chosen to span four event times.
Rule. In the communication profile, a transmit PDO's event timer forces one transmission per expired event time when no other event occurs. A producer that only sends on data change transmits zero times while its payload stays constant.
Arithmetic. Frames a working producer timer at that interval must show in the window: 2000 ms / 500 ms = 4.
Result. During the constant 2 s stretch, the command PDO at 0x20B shows 0 frames; the 2 frames on the trace both follow deliberate value changes. The drive's transmit PDO at 0x18B, which is 0x180 plus 11, shows 4 frames across the same window with its payload constant.
Decision. 0 command frames against 4 status frames pins the fault: the manager has no producer timer active on this PDO. Set the same producer timing on the manager side or request the send from a timed task, re-run the same window, and accept the fix at 4 frames or more per 2 s with the payload unchanged. Fewer than 4 means the schedule is still not on the producer.
The fix: schedule the send on the producer side
Commission every change below with the drive disabled and the machine in a safe state; changing command PDO timing changes when the drive acts on commands.
Work the options in order and let the re-run capture decide.
- Manager-side producer timing. The manager product documentation covers its configuration, stack diagnostics and PDO communication settings. Where your installed build documents an event timer or send interval for the manager's own PDOs, set 500 ms there, leave the mapping and the drive configuration untouched, and apply the change with the download or restart procedure your runtime requires.
- Explicit send from a timed task. Where the manager documents an explicit send request for a single PDO, call it from a task timed to the same interval as the drive's event time. Rewriting the mapped variable with the value it already holds is not a send request; your constant-payload window just showed that an unchanged payload produces no frame. Only the documented request counts, and the capture must show the 4 frames after it.
- A mapped change variable. If the drive's object dictionary offers a mappable object with no effect on drive behavior, add it to this PDO's mapping and toggle it every program cycle. The constant change becomes the producer's event. Write the new mapping, read it back over SDO, and drop this option if the write aborts or the EDS shows the object acting on the drive.
- A manager build with documented producer timing. If none of the three exists in your installed stack, the schedule has to come from the manager. The drive's event timer cannot transmit a frame the drive receives, so no drive-side value repairs this; select a manager build whose documentation states producer-side PDO timing.
Traps that keep the capture at zero frames
- Trusting symmetric settings. Identical values in both directions configure two producers with two policies. Capture each identifier on its own and the asymmetry shows in one window.
- Prodding the data to provoke sends. Toggling a command value does force a frame, and it also commands the drive. Acceptance is repeated frames with identical payloads.
- Swapping the adapter first. Two adapter makes already reproduced the identical pattern, because the policy sits in the manager software; the capture from the adapter you have is sufficient evidence.
- A project description that does not match the connected device. If the EDS in the project describes another device type or revision than the drive on the bus, configuration writes land in unexpected places; the article on a CANopen example failing when the device type is wrong covers that class of failure and its checks.
The decision
Recommendation: Before any hardware change, hold the command payload constant, filter the trace by the command PDO identifier, and record 2 seconds. Zero frames confirms that no producer timer is active on the manager. Put the timing on the producer side: set the manager's documented producer timing, or call its documented send request from a task timed to the configured event interval, then re-run the same window. Accept the fix at 4 frames or more per 2 seconds with the payload unchanged. If the installed manager documents neither facility, plan the move to a manager build that states producer-side PDO timing, and keep node supervision on so a silent master is caught quickly.
Questions
What is the difference between transmission type 254 and 255?
Both are asynchronous. In type 254 the event that triggers a transmission is specific to the manufacturer; in type 255 the device profile defines the event. Neither value schedules anything on its own. The event timer is the setting that makes a producer repeat a PDO at a fixed interval, and the transmitting device is the one that reads and applies it.
What does the inhibit time do on a transmitting PDO?
A transmitting PDO carries three timing settings: the transmission type, the event timer and the inhibit time. The inhibit time is the shortest gap allowed between two transmissions of the same PDO. It can stretch the real interval above the event timer value and suppress change-driven bursts, but it never forces a send. Check it whenever periodic frames arrive more slowly than the event time you configured.
How can I tell which device my event time value was actually written to?
Read the drive's PDO communication parameters back over SDO while the network is running and compare them with your offline project. If the configured event time appears in the drive's receive record, the manager wrote the value toward the drive, where it cannot act as a send schedule; producer timing is a record on the transmitting device. Some configuration tools also list the startup writes they generate, which shows the node and object each value went to.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.