HEXAFORCE CAN FD PLANNING GUIDE
Check six-axis payload fit and bus demand. CAN FD hardware and firmware require configuration review.
Estimate traffic and payload fit. Hardware timing remains unverified.
One node: 13.9%. Other traffic is excluded. Values above 100% indicate impossible demand.
Nominal: 35.0 µs; data: 103.8 µs. Includes intermission, not waiting or retries.
Cycle 1000.0 µs minus all sensor frames. 50% budget rate: 3602 Hz/node; not a guaranteed control rate.
Local loop: 150 ns. Cable round trip: 30 ns (assumes 5 ns/m). Review TDC with the controller manual. SSP cannot be derived from these inputs.
Torque: 0.000001907 N·m. Numerical encoding only; sensor noise, accuracy and dynamic range remain unknown.
75.0% used; remainder padding. Layout is illustrative and little-endian, not a released HexaForce protocol.
| Offset | Bytes | Field | Type | Units | Purpose |
|---|---|---|---|---|---|
| 0–1 | 2 | StatusWord | uint16 | bitfield | Illustrative status flags; vendor definitions unconfirmed |
| 2–3 | 2 | SequenceCount | uint16 | counter | Modulo 65536; compare with restart and timeout state |
| 4–7 | 4 | TimestampUs | uint32 | µs | Proposed ADC timestamp; epoch, reset and clock synchronization must be agreed |
| 8–11 | 4 | Fx | float32 | N | Proposed little-endian signal; integer scales agreed per axis |
| 12–15 | 4 | Fy | float32 | N | Proposed little-endian signal; integer scales agreed per axis |
| 16–19 | 4 | Fz | float32 | N | Proposed little-endian signal; integer scales agreed per axis |
| 20–23 | 4 | Mx | float32 | N·m | Proposed little-endian signal; integer scales agreed per axis |
| 24–27 | 4 | My | float32 | N·m | Proposed little-endian signal; integer scales agreed per axis |
| 28–31 | 4 | Mz | float32 | N·m | Proposed little-endian signal; integer scales agreed per axis |
| 32–33 | 2 | TemperatureInternal | int16 | 0.01 °C | Illustrative telemetry, not a released sensor feature |
| 34–35 | 2 | SupplyVoltageMv | uint16 | mV | Illustrative telemetry, not a released sensor feature |
| 36–47 | 12 | Padding | uint8[] | raw | Reserved; zero fill by agreement |
Original browser capture, November 4, 2026: the default single-node example uses 1,000 samples/s, 1,000 kbps nominal and 5,000 kbps data rates, Float32 encoding and a 48 B payload, with both timestamp and auxiliary telemetry enabled. Required fields occupy 36 B. The model returns 138.8 µs/frame and 13.9% sensor demand, excluding other traffic.
Remaining defaults: 3 m trunk, 0.1 m stub, 150 ns local loop delay, split termination and common-mode choke proposed; example spans ±1,000 N and ±30 N·m. These context values do not certify the topology or sensor accuracy. To reproduce, select Reset defaults in the planner and review calculated results; inspect the bit-budget method below.
Six Float32 values, status and sequence require 28 B; adding a timestamp needs 32 B, and 4 B auxiliary telemetry needs 36 B, rounded to a 48 B wire payload.
Source basis: Linux CAN frame length model — include/linux/can/length.h. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Float32 is a numerical format, not a sensor accuracy claim. Integer examples need an explicit signed range, scale and offset for every force and torque axis.
Source basis: Oracle Numerical Computation Guide — IEEE Arithmetic, single format. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
The planner budgets stuffing and intermission. Arbitration waiting, competing traffic, retries and host delays still need measurement and response-time analysis.
Source basis: Linux CAN frame length model — include/linux/can/length.h. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Cable round-trip propagation is separate from local TXD-to-RXD delay. Without the controller clock and bit segments this page cannot recommend an SSP register value.
Source basis: Bosch M_CAN user manual, revision 3.3.1 (2023), sections 3.1.4–3.1.4.2. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Use terminated trunk ends and short branches as a starting point. Split termination and chokes are design options, not automatic proof of operation at a selected rate.
Source basis: TI — CAN physical layer (2019). Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
A payload timestamp can describe acquisition time only when its capture event, wrap, reset, epoch and clock relationship are agreed. Arrival time is a different event.
Source basis: Linux kernel documentation — SocketCAN. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Record kernel, driver, adapter firmware and load. Socket options and a real-time scheduler do not establish a portable microsecond latency bound.
Source basis: Linux kernel documentation — SocketCAN. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
A proposed raw CAN FD layout or DBC does not establish CANopen FD interoperability, a compatible ROS driver or released product firmware.
Source basis: CiA — Standardized higher-layer protocols. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Compare acquisition architecture and verification cost before choosing a bus. These are decision criteria, not measured protocol latency or price rankings.
Compare complete acquisition paths, not unmeasured protocol latency.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Raw CAN FD | Up to 64 B payload | Application schema and tooling must be agreed | Request firmware-matched protocol evidence |
| Classical CAN | Up to 8 B payload | Six Float32 values alone need three frames | Use a sample counter and reassembly timeout |
| Existing EtherCAT system | May fit an existing controller workflow | No cross-protocol cycle-time benchmark supplied | Review the released device description and master compatibility |
| Analog acquisition | Can reuse a qualified DAQ | Needs channel timing, noise and grounding review | Compare complete acquisition-chain cost |
Source basis: Bosch M_CAN user manual, revision 3.3.1 (2023), sections 3.1.4–3.1.4.2 · Linux kernel documentation — SocketCAN. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
One CAN FD frame can carry a coherent wrench record. Transport atomicity does not prove simultaneous ADC sampling. The following proposed little-endian layout is illustrative, not a released protocol.
Without auxiliary fields the 32 B proposal fits. Not a released protocol.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Status + sequence | 2 B + 2 B = 4 B | Status flags are unconfirmed | Agree bit definitions and modulo 65536 sequence |
| Six Float32 axes | 24 B, following the 4 B header | Fx/Fy/Fz in N; Mx/My/Mz in N·m by agreement | Confirm units, signs and sensor reference frame |
| Timestamp | Optional 4 B at offset 4 | Header + timestamp + axes = 32 B | Confirm capture event and clock mapping |
| Auxiliary telemetry | Optional 4 B after axes | 36 B total with timestamp; select 48 B, not 32 B | Planner withholds the map when any requested field cannot fit |
Source basis: Linux CAN frame length model — include/linux/can/length.h · Bosch M_CAN user manual, revision 3.3.1 (2023), sections 3.1.4–3.1.4.2. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Use transport quantization to check representation loss. This does not replace measured noise, calibration uncertainty or overload limits. The tool’s spans are examples; actual scale factors are per axis.
Numerical spacing is separate from sensor accuracy and dynamic range.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Float32 near 1000 N | Adjacent-number spacing ≈ 0.000061035 N | Spacing changes with exponent; accuracy remains unknown | Reject NaN/Inf and confirm conversion behavior |
| Int16 at ±1000 N | ±32000 counts: 0.03125 N/count | Illustrative headroom policy, not full signed range | Verify rounding, clipping and scale version |
| Int24 at ±1000 N | ±8000000 counts: 0.000125 N/count | Three-byte packing and sign extension must match | Test positive, negative and saturation vectors |
| Int32 at ±1000 N | ±2000000000 counts: 0.0000005 N/count | More numeric precision does not recover ADC information | Validate host conversion and usable sensor noise floor |
Source basis: Oracle Numerical Computation Guide — IEEE Arithmetic, single format. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Model v2, reviewed 2026-11-04: ISO CAN FD, 11-bit ID, BRS enabled, one frame per sample per node. For payload L bytes: nominal allowance = 35 bits; data allowance = (5 + 8L) + ceil((5 + 8L)/4) + C − 1, where C = 28 for L ≤ 16, otherwise 33. T = 35/Rnom + data/Rdata, with rates in Mbit/s and T in µs.
11-bit ISO CAN FD, BRS on; includes intermission, excludes waiting and retries.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Nominal allowance | 17 header + 5 stuff + 1 delimiter + 12 ACK/EOF/IFS = 35 bits | Separately rounded stuffing deliberately over-budgets transitions | Do not treat it as a decoded bitstream |
| CRC field | C includes fixed stuffing and delimiter; delimiter charged at nominal rate | ISO CAN FD only; no original non-ISO compatibility claim | Confirm controller ISO mode |
| 32 B at 1 / 5 Mbit/s | 261 dynamic bits + 66 stuffing + 32 CRC = 359 data bits; T = 106.8 µs | No retries, competing traffic or software delay | Compare with an analyzer trace on target hardware |
| 48 B at 1 / 5 Mbit/s | 389 + 98 + 32 = 519 data bits; T = 138.8 µs | Conservative allowance, not average latency | Use this default when timestamp and auxiliary fields are enabled |
Source basis: Linux CAN frame length model — include/linux/can/length.h · CiA — Cyclic redundancy check in CAN frames. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Demand (%) = rate × sensor count × frame allowance (µs) / 10000. Values are not capped: demand above 100% cannot be scheduled. The 30/50/70% color bands are editorial review prompts, not standard-defined limits or safety acceptance criteria.
Demand above 100% cannot fit. Headroom does not guarantee a deadline.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Default 1 node × 1000 Hz | 48 B at 1 / 5 Mbit/s: 13.88% sensor demand | All other traffic excluded | Add commands, diagnostics and their priorities |
| 2 nodes × 2000 Hz | 24 B at 1 / 4 Mbit/s: 41.9% sensor demand | Wire-only cycle balance = 290.5 µs | Check blocking, bursts and worst-case delivery |
| Over 100% demand | Frames require more than the available second | Queues grow even without retransmissions | Reduce rate or payload; split buses if needed |
| Low average utilization | Still permits blocking by an ongoing frame | No zero-jitter or emergency-stop guarantee | Analyze response times and validate the separate safety path |
Source basis: Linux CAN frame length model — include/linux/can/length.h · Linux kernel documentation — SocketCAN. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Estimate sensor wire demand for up to 16 nodes on a shared trunk. Add other network traffic and analyze message priorities separately before assigning control deadlines.
A selected bit rate does not validate an assembled network. Keep an evidence register for actual part numbers, revisions, loading and environmental limits. The planner records geometry but does not certify topology.
Actual voltage and timing margins require device-specific validation.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Controller | Exact peripheral and reference clock | Bit-segment and oscillator limits unknown | Record achieved nominal/data rates and SJW |
| Transceiver | Actual CAN FD device and supply | Delay variation across voltage and temperature unknown | Use rated delay and symmetry data, then measure |
| Cable | Planner assumes 5 ns/m one-way propagation | Actual impedance, capacitance and connectors unknown | Obtain cable data and inspect end-node waveforms |
| Other nodes | FD-capable and ISO-mode confirmation | Classical-only nodes may disrupt FD traffic | Validate every attached node or use isolated segments |
Source basis: Bosch M_CAN user manual, revision 3.3.1 (2023), sections 3.1.4–3.1.4.2 · TI SLLA270 — Controller Area Network Physical Layer Requirements (2008). Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
TDC compensates local transmitted-bit observation. A local delay longer than one data bit is not by itself evidence that TDC is non-functional. The planner deliberately reports SSP settings as unknown.
Cable propagation is analyzed separately. No register setting is generated.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Local loop delay | TXD-to-RXD path at the transmitting node | Not the remote cable round-trip delay | Measure or bound from device data |
| Cable propagation | 2 × length × 5 ns/m in this planner | Not substituted into the TDC register | Include real propagation in network timing analysis |
| Bosch M_CAN example | SSP uses measured local delay plus TDCO | Revision 3.3.1 has controller-specific range limits | Read section 3.1.4 and use actual controller clock quanta |
| Missing inputs | Clock, prescaler, segments and TDC limits | No universal 70–80% SSP or mandatory 2 Mbit/s rule | Have firmware engineering validate the register configuration |
Source basis: Bosch M_CAN user manual, revision 3.3.1 (2023), sections 3.1.4–3.1.4.2. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Standard end termination and split termination are both design options. Changing a capacitor or adding a choke changes the circuit and requires validation; neither guarantees suppression of differential ringing.
Neither split termination nor a choke automatically eliminates ringing.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Trunk ends | Nominal 120 Ω at each physical end | Internal node terminators may create excess loading | Confirm two end terminations with power removed |
| Split option | Two nominal 60 Ω resistors plus selected midpoint capacitor | Capacitance and ground connection depend on design | Use the transceiver reference circuit and EMC test plan |
| Common-mode choke | Optional common-mode filtering | Parasitics, saturation and delay can affect edges | Compare candidate parts and bypass configuration on the bench |
| Protection and isolation | Selected TVS, reference and isolation concept | Added capacitance and delay not modeled | Qualify signal integrity and transient behavior together |
Source basis: TI — CAN physical layer (2019) · TI SLLA270 — Controller Area Network Physical Layer Requirements (2008). Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Short branches and a controlled return/reference path are useful starting points. The old 0.3 m high-speed CAN stub guideline is used only as a review trigger here; FD performance depends on the whole topology.
0.3 m is a review trigger, not universal FD topology certification.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Topology record | Trunk length, every stub and node location | No universal maximum FD cable length computed | Draw the actual network including adapters |
| Motor routing | Separate noisy power and signal routes where practical | Shield bonding depends on chassis and ground strategy | Review the complete installation with EMC engineering |
| Moving harness | Bend radius, strain relief and connector retention | Electrical qualification does not prove flex life | Test the representative motion cycle |
| Long cable option | Try lower data rate or a nearer interface gateway | No guaranteed rate/length conversion table | Recalculate demand and remeasure waveforms |
Source basis: TI SLLA270 — Controller Area Network Physical Layer Requirements (2008) · TI — CAN physical layer (2019). Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
A timestamp field helps identify when data was acquired only if firmware captures the agreed event. Sensor, adapter and host clocks are distinct. A timestamp does not itself synchronize sensors or remove network delay.
A 32-bit microsecond timer wraps after 4294.967296 seconds.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Acquisition event | Proposed capture at ADC completion | Multiplexed axes may still have acquisition skew | Request channel timing and filter-delay evidence |
| 32-bit µs timer | Wrap after 4294.967296 s (about 71.6 min) | Reset can resemble wrap; rate drift remains | Track sequence, boot identity and clock offset |
| Host receive time | Timestamp of a different event | Hardware timestamp availability is adapter/driver dependent | Record event semantics and measured clock mapping |
| Multi-sensor fusion | Common trigger or clock synchronization plus drift limits | Independent counters cannot be directly compared | Measure inter-sensor alignment over temperature and time |
Source basis: Linux kernel documentation — SocketCAN · Bosch M_CAN user manual, revision 3.3.1 (2023), sections 3.1.4–3.1.4.2. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Communication recovery and permission to resume force control are separate decisions. Agree fault behavior with the machine controller; the transport planner cannot validate a safety function.
Communication restart is separate from permission to resume motion.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Missing or duplicate record | Sequence and age watchdog | Sequence alone cannot detect a frozen producer | Invalidate stale wrench data and notify the controller |
| Bus-off | Capture interface state and error counters | Immediate repeated restart may hide wiring faults | Preserve logs and diagnose the physical/configuration cause |
| Restart policy | Linux supports configurable automatic or manual restart | No universal restart-ms value recommended | Use a bounded recovery policy in the system state machine |
| Control re-entry | Require healthy recent data and application authorization | Link recovery alone is insufficient | Inject disconnect/reconnect faults on a controlled bench |
Source basis: Linux kernel documentation — SocketCAN. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Status and telemetry are proposed fields, not confirmed HexaForce capabilities. The following acceptance worksheet is an original commissioning method; numerical limits must come from the application.
Set application-specific acceptance limits before testing.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Protocol match | Known positive/negative/zero test vectors | Byte order, scale, sign and validity flags unconfirmed | Archive firmware, schema version and decoded vectors |
| Traffic test | Required rates and realistic competing messages | Worst-case age and deadline are application specific | Measure max age, gaps and error counters under load |
| Physical test | Representative cable, supply, temperature and motor noise | No network qualification results supplied | Save waveforms and controller error logs |
| Fault test | Loss, frozen sequence, timestamp wrap and bus-off | Safe response and recovery criteria unconfirmed | Approve limits before test; archive observed behavior |
Source basis: Linux kernel documentation — SocketCAN · CiA — Cyclic redundancy check in CAN frames. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
This is an API checklist, not tested driver code. No Linux, adapter, firmware or ROS release has been qualified by this page. Pin deployment versions and measure under representative CPU and I/O load.
No target Linux, adapter or ROS release was qualified by this guide.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Enable FD reception | Check CAN_RAW_FD_FRAMES and each API return | Not every interface supports FD mode | Verify MTU and achieved interface bit timing |
| Decode received records | Distinguish CAN_MTU and CANFD_MTU | Received frame type and payload length must be checked | Reject unexpected IDs, lengths and invalid numerical values |
| Timestamp and queues | Identify capture source; monitor receive loss | Buffer size is not a portable frame-count or latency guarantee | Measure age distribution, overflow and sustained throughput |
| Control handoff | Bounded queue, latest valid sample and watchdog | Priority settings do not guarantee a microsecond deadline | Benchmark the complete acquisition-to-control path |
Source basis: Linux kernel documentation — SocketCAN. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
A database describes a chosen signal layout; it does not supply a higher-layer protocol implementation. Request the actual firmware-matched schema before integrating a decoder or a ROS bridge.
A DBC does not implement or certify CANopen FD compatibility.
| Decision / item | Known or illustrative basis | Limit / unknown | Next action |
|---|---|---|---|
| Default layout proposal | Status 0–1; sequence 2–3; timestamp 4–7; axes 8–31 | Auxiliary values 32–35; padding 36–47 in the 48 B default | Agree little-endian encoding and float metadata with the chosen decoder |
| Integer mapping | Same order, different channel widths | Per-axis factors and sign extension not in a generic byte offset | Use versioned reference vectors in both host and firmware |
| CANopen FD | CiA 1301 higher-layer protocol | Raw CAN FD frames do not demonstrate stack/profile support | Confirm object dictionary, profile and release compatibility |
| End-to-end protection | Sequence, age and optional application CRC by agreement | No CRC-8 field is reserved by this illustrative layout | Define coverage, polynomial and failure response if an E2E scheme is required |
Source basis: CiA — Standardized higher-layer protocols · CiA — Cyclic redundancy check in CAN frames. Tables, bit calculations, and framing architectures are original engineering interpretations. Sources support the stated mechanisms, not measured HexaForce performance or product compatibility.
Planning examples for collaborative robots, dual-arm teleoperation, humanoid biped walking, and subsea ROVs. These are reproducible planning examples, not observed customer results or qualified product configurations.
Operational Premise: Illustrative 1 node, 1 kHz, Float32, timestamp and auxiliary telemetry, 1 / 5 Mbit/s.
Bus Configuration & Technical Discovery: 36 B of fields require a 48 B payload. Model allowance is 138.8 µs/frame and demand is 13.88%.
Decision & Remaining Validation: Wire capacity is plausible; collect actual arbitration, acquisition age and physical-layer evidence before commissioning.
Operational Premise: Illustrative 2 nodes, 2 kHz, Int16, timestamp and auxiliary values in 24 B at 1 / 4 Mbit/s.
Bus Configuration & Technical Discovery: 24 B fits exactly. Frame allowance is 104.75 µs; sensor demand is 41.9%; wire-only balance is 290.5 µs/cycle.
Decision & Remaining Validation: Compare 0.03125 N/count at an example ±1000 N span with measured sensor noise; measure delivery deadlines.
Operational Premise: Illustrative four sensors at 500 Hz, Float32 with timestamp and telemetry, initially 32 B.
Bus Configuration & Technical Discovery: Requested fields total 36 B, so no valid map exists. Increase to 48 B; at 0.5 / 2 Mbit/s the allowance is 329.5 µs.
Decision & Remaining Validation: Demand becomes 65.9%. Redesign traffic or split trunks if application response-time analysis fails.
Operational Premise: Illustrative 25 m trunk, one node at 250 Hz, Float32 plus timestamp; disable auxiliary values to fit 32 B.
Bus Configuration & Technical Discovery: At 0.5 / 1 Mbit/s the model allowance is 429 µs and demand is 10.725%. Record real cable and transceiver characteristics.
Decision & Remaining Validation: This is a test candidate, not proof that the cable works. Qualify waveform margins and common-mode conditions.
Operational Premise: Illustrative 4 nodes at 4 kHz, 48 B, 0.5 / 2 Mbit/s.
Bus Configuration & Technical Discovery: 329.5 µs/frame gives 527.2% demand and a −1068 µs wire-only cycle balance. The display must retain the uncapped demand.
Decision & Remaining Validation: The schedule cannot fit. Reduce rate/node count, redesign payload or provide separate buses before bench testing.
Operational Premise: Illustrative two 2 kHz ankle streams with independent 32-bit microsecond counters.
Bus Configuration & Technical Discovery: Record acquisition events, offset and drift against a common reference; test wrap after 4294.967296 s and sensor reset.
Decision & Remaining Validation: A shared frame format does not prove synchronized samples. Establish alignment tolerances before using fused contact estimates.
No. This planner offers 16, 24, 32, 48 and 64 B payload lengths. Choose a supported length that fits all requested fields; these are byte lengths, not raw DLC codes.
Six Float32 values plus status, sequence, timestamp and 4 B auxiliary telemetry total 36 B. The next supported length is 48 B. Disable auxiliary telemetry to fit 32 B.
No. Binary32 precision describes number representation. Sensor noise, usable resolution, calibration and dynamic range need separate measurements.
The example uses ±span at ±32000 counts with zero offset. That policy is illustrative; agree actual per-axis scales, clipping and units with firmware engineering.
The record arrives atomically at transport level. Simultaneous acquisition depends on ADC architecture, capture timing and filtering.
No. It is an illustrative little-endian layout. Request a firmware-matched specification and verify the host decoder against known vectors.
No. It is a conservative wire-time allowance for an 11-bit ISO CAN FD frame with BRS on and intermission. The method and worked numbers are shown in section 4.
Yes, a conservative separately rounded dynamic-stuffing allowance and the fixed CRC-field stuffing. It does not construct actual payload bits or model transition sample points exactly.
It represents requested sensor traffic. More than 100% means the requested frames cannot fit even before other traffic and retries. Capping the value would hide the amount of overload.
No. The 30/50/70% bands are planning prompts. Deadline guarantees require message priorities, blocking analysis, competing traffic and measured platform delays.
No. It subtracts sensor wire allowances only. ADC, filtering, queues, arbitration and controller execution still consume time.
No. CAN FD with equal nominal/data rates retains FD framing. A Classical-only controller is not made FD-compatible by using the same rate.
None. It records lengths and shows propagation using an assumed 5 ns/m. Actual limits depend on components, loading, timing, cable and environment.
This planner uses 0.3 m only as a review trigger from legacy high-speed CAN guidance. Shorter branches can also fail; validate the actual FD topology.
No universal requirement is established here. Both standard and split termination need selection and testing in the actual transceiver and network design.
No such guarantee is justified. Chokes target common-mode interference and have parasitic effects. Select and qualify the actual component rather than inductance alone.
No. It lacks controller clock, prescaler, segments and range limits. Use the actual controller manual and measured local TXD-to-RXD delay.
TDC observes the transmitting node’s local TXD-to-RXD path. Network cable propagation has a separate role in timing analysis and is not a substitute for that measurement.
No. Define the capture event, shared epoch or synchronization method, offset and drift bounds before comparing independent counters.
Every 4294.967296 seconds, about 71.6 minutes. Track wrap and reset explicitly; modular subtraction alone cannot distinguish all resets or long gaps.
No deployed kernel, adapter firmware, ROS distribution or driver has been qualified here. Record exact versions and run the commissioning worksheet.
No portable bound is established. Benchmark the actual hardware, driver, CPU load and control path; socket priorities and buffers are only part of that system.
No automatic control-resume policy is implied. Diagnose the fault, apply controlled communication recovery, and require valid recent data plus application authorization.
Provide controller and firmware versions, rates, node count, traffic/priority list, topology, required units/scales, timestamp semantics and acceptable data age. Copy the planner memo as a starting point.
Authored and reviewed by HexaForce Metrology & Robotics. Technical integration guide formally established ; public sources rechecked and planning model reviewed . Next scheduled review: , or sooner when the framing model, source APIs or configuration release evidence changes. Public publication date has not been independently verified.
References below were checked on November 4, 2026. The scope is ISO CAN FD framing, controller-specific TDC guidance and public acquisition APIs. This page does not establish compliance with a current standards edition or qualify hardware, firmware, Linux or ROS releases. The calculator is a conservative planning model, not a bit-accurate simulator or a control-safety assessment. CAN FD remains a HexaForce engineering configuration target: request the actual firmware, DBC and pinout before commissioning. The proposed status flags and telemetry are unconfirmed.
Primary implementation reference for field sizes and stuffing allowance. The planner adds a conservative phase split; it is not the Linux algorithm verbatim.
Explains ISO CAN FD CRC fields and incompatibility with the original non-ISO format.
Controller-specific reference for local transmitter delay measurement and SSP limits. Not proof of the controller used in a HexaForce configuration.
API reference for CAN_RAW_FD_FRAMES, frame lengths, error monitoring and recovery. Living documentation; deployment kernel and driver were not tested here.
Legacy high-speed CAN wiring and termination fundamentals. Its cable-length examples are not CAN FD topology certification.
Explains transceivers and optional external protection/filtering components. Select actual parts using their data sheets and EMC measurements.
Primary format explanation for binary32 significand precision and special values; does not establish sensor measurement performance.
Distinguishes higher-layer protocols including CANopen FD (CiA 1301) from the underlying CAN transport.
Fieldbus integration connects with multi-axis calibration and coordinate transformations. To verify coordinate sign polarities and right-hand rules, visit 6-axis force sensor sign convention verification, or explore analog readout alternatives with the analog output acquisition calculator.
Send us your robot controller model (e.g. ROS 2, Beckhoff TwinCAT, Keba, or custom Linux RT-PREEMPT), required update rate, and cable drag-chain length. Request a configuration-specific review of firmware availability, CAN FD timing, DBC definitions and wiring. Deliverables and compatibility require confirmation for the proposed hardware.
Related engineering resources: digital interfaces & mounting kits, cable force compensation modeling, or all engineering resources.
