The practical answer.
Test a robot's battery interface for message freshness as well as loss of connectivity. Define the age limit for each critical input, decide which function owns the fallback, and verify the response when a message stops, repeats stale data or resumes after a reset. Record actual robot and charger behavior against a synchronized bus trace. The required transition and recovery are part of the complete robot's design.
- Give current limits and charge permission their own timing and validity rules.
- Exercise valid-looking stale data separately from a silent bus.
- Prove restart conditions with synchronized traces from the battery, controller and dock.
Separate bus activity from usable battery data
During a robot mission, an active connection can still carry data the controller should no longer use. A gateway may continue sending an old charge limit after losing its upstream source. A pack can restart while a cached permission remains in the controller. Even a perfectly valid frame can contain a value whose acquisition age exceeds what the robot needs. Ask how the system tells these conditions apart.
CAN in Automation's CANopen FD description illustrates how a heartbeat reports participant availability and network state, while a boot-up message signals initialization. That definition does not make any individual battery value fresh. Modbus serial-line documentation separately defines the client's transaction response timeout. With a poll-and-reply interface, a response can meet that timeout while carrying a value sampled earlier. Record the chosen transport, application protocol and data map as separate fields in the purchase specification.
Write a freshness rule for each decision input
List the battery values that can change robot or charger behavior. Examples include discharge current limit, permission to charge, fault status and a temperature limit used by a particular design. For each one, specify the producer, consumer, units, refresh interval, validity indicator and expiration rule. Identify whether time starts at acquisition or at reception. If a gateway repeats values, ask how it preserves the original age or invalidates a value after an upstream interruption.
Select the permitted fallback with the robot and charger owners. Driving, docking and maintenance can require different actions. A battery supplier may define its own local protection behavior, while the robot owns motion and the charger owns its output. Give each owner a way to confirm the other component actually entered the expected state.
| Decision input | Freshness evidence | Ask the system owner |
|---|---|---|
| Discharge current limit | Producer period and validity field | What load restriction applies when the limit expires? |
| Permission to charge | Unique session or current valid state, where implemented | What observable behavior confirms charging has entered the intended fallback? |
| Reported battery fault | Event state and restart behavior | Which faults remain latched, and which require a new valid report? |
| Node availability | Heartbeat or transaction timing | How is availability distinguished from data freshness? |
Check the timing budget from the last valid sample
For illustration, assume a limit message is produced every 100 ms and the receiver measures a maximum observed interval of 120 ms in the agreed loaded-network test. Suppose the project's example budget allows 240 ms from the last received valid value to completed fallback. If the controller scan can add 15 ms and the command-to-actuator response can add 30 ms, expiration would need to be detected within 195 ms of the last valid reception to fit that budget. A proposed 180 ms expiration leaves 15 ms for other identified delays under those assumptions.
That example starts at reception. If the requirement starts when the data was acquired, include acquisition and gateway delay too. Specify where an incrementing counter is generated if the system uses one. A gateway that increments its own counter while forwarding cached data can mask an upstream failure. Validate observed worst-case timing with the actual bus load, trace clock alignment and controller scheduling relevant to the system.
Exercise failures that look normal on a status screen
- Capture a reference trace while the robot and charger operate in the agreed states. Identify timestamps for values, validity and state transitions.
- On an approved test setup, suppress a selected data message while preserving node availability. Verify the value expires and the specified fallback occurs.
- Replay an unchanged sample with plausible framing where the approved test fixture supports it. Confirm the receiver's freshness checks detect the intended fault.
- Run the defined restart and reconnection scenarios. Check that new valid state is established before the affected function returns to normal.
- Record the robot command and measured response or charger current alongside the raw protocol trace. Close unexplained timing or state differences before approval.
Ask for the interface revision with the battery quotation
Jetray's custom pack materials list BMS communication options for evaluation, including CAN and RS485. Confirm the exact physical interface, message specification and firmware identity for the proposed pack. For the robot pack evaluation references below, share the controller, dock sequence and the system behaviors required when a value expires. The capacity class gives procurement a way to frame the discussion. The approved interface and its test record establish the actual behavior.
Does a valid CAN frame prove the current limit is still current?
Only if the full data path provides freshness evidence that meets the controller's requirements. Validate how acquisition, forwarding, frame reception and expiration relate for that signal.
Should charging resume on the first response after a reconnect?
Use the approved restart rule. It may require identity, valid limits, a known dock state or a new charge session. Check the specified behavior for both a short interruption and a battery reset.
Sources & further reading
- CAN in Automation, CANopen FD heartbeat and boot-up error control protocols ↗
- Modbus Organization serial-line implementation guide V1.02, transaction response timeout ↗
- Jetray robotics battery solutions and catalogue references ↗
Timing values are an illustrative interface calculation. Robot and charger acceptance criteria must be set by the responsible design team. Use a controlled fixture or approved test setup when simulating faults.
Prepared for the robotics & agv battery projects collection. General engineering guidance does not replace a model-specific datasheet or application validation. Source review: 5 November 2026.