- Home
- Solutions
- Controller & API Integration
Host-to-platform interface engineering
Motion Platform Integration
Define what your host sends, what the platform returns, when each command is valid, how faults behave and how the interface will be accepted—before either team reaches commissioning.
Project scope: integration is normally delivered with a CSCmotion motion-platform project. Existing CSCmotion configurations and third-party or legacy systems require a documented engineering review before compatibility, price or schedule can be confirmed.
First engineering response
What you get from the first review
- A likely project route: new platform, configuration change or legacy feasibility review.
- A recommended command boundary for your host architecture.
- The missing inputs and interface risks that must be closed before quotation.
- A clear distinction between standard project scope and separately quoted work.
Which Integration Situation Matches Your Project?
The same request—“connect our software to the platform”—has three very different engineering and commercial meanings. Identifying the route early prevents a configuration discussion from becoming an undefined retrofit promise.
New CSCmotion platform project
The controller, platform geometry, drive configuration, host boundary and acceptance plan are developed as one platform subsystem.
- Define the host command level
- Confirm the project-specific interface route
- Contract the ICD and interface acceptance cases
Existing CSCmotion system
A new host, message set or command level is reviewed against the controller, firmware, parameters and documentation delivered with the system.
- Identify model, serial or project reference
- Recover the delivered configuration baseline
- Define the change and revalidation scope
Third-party or legacy platform
A controller-only replacement cannot be confirmed until the retained mechanics, drives, feedback, wiring, geometry and safety circuits are reviewed.
- No compatibility commitment from photos alone
- May require cabinet or subsystem replacement
- Price and schedule follow feasibility review
A Project-Specific Interface, Not a Protocol Checklist
CSCmotion controller and software materials cover several network, fieldbus, serial and SDK routes. The route available to your project depends on the named controller, platform configuration and contracted software scope.
| Platform side | Controller, drive coordination, feedback, platform kinematics and platform-side limits remain within the approved platform configuration. |
|---|---|
| Possible routes | Project configurations may use TCP/UDP, EtherCAT, CANopen or serial/Modbus routes. The quotation names the approved connection and hardware. |
| SDK / API | Message definitions, SDK format and available language wrappers are confirmed for the selected controller and software scope—not assumed from another project. |
| Command level | Normally platform pose, trajectory/profile or application-derived motion input. Direct actuator commands are exceptional and require a separate protection review. |
| Status returned | Operating state, accepted/rejected command status, limits, faults and configured feedback values are defined in the command and status dictionary. |
| Timing | Update period, jitter tolerance, timestamp convention, heartbeat and missed-frame response are fixed for the approved project route. |
| Acceptance | Representative commands, state transitions, limits, timeouts, fault cases and recovery are converted into testable interface acceptance cases. |
What Makes the Interface Scope Verifiable?
A protocol name is not evidence of compatibility. The review becomes actionable when the controller baseline, interface package, data meaning and acceptance record can all be tied to the same approved project configuration.
Named controller and software revision
The quotation identifies the applicable controller, firmware, platform parameters and interface-document revision instead of borrowing assumptions from another project.
Approved transport and SDK scope
The project confirms the physical connection, transport, message definition and any available SDK format or language wrapper for the selected configuration.
Command and status dictionary
Fields, units, coordinates, rotation convention, valid ranges, states, faults, timeouts and rejected-command behaviour are controlled in one interface baseline.
Repeatable interface test cases
Representative commands, state transitions, timeouts, fault recovery and version checks are converted into recorded FAT or agreed integration evidence.
What Should Your Host Command?
The strongest interface keeps application logic on the side that understands the application and platform-protection logic on the side that understands the platform. The correct boundary depends on what your host already computes.
Send the motion the platform should reproduce
Your host sends the agreed translational and rotational pose or trajectory. Platform kinematics, coordinated actuator control and platform-side limits remain inside the controller.
Send vehicle, vessel or flight-derived motion
Use this route when motion cueing or another application-specific transformation is included in the agreed platform-side software scope. Ownership and tuning responsibility must be explicit.
Coordinate profile playback, I/O and operating state
Use an agreed command set for profiles, start/hold/stop, sequence coordination and status when the application does not need a continuous pose stream.
Your host normally owns
The application meaning of the motion and the sequence around the wider simulator, test rig or machine.
- Vehicle, vessel, flight, test or training model
- Scenario, visual and operator workflow
- Application-specific data preparation
- Complete-system sequencing outside the platform
The platform controller normally owns
The coordinated platform response within the approved controller and mechanical configuration.
- Platform kinematics and actuator coordination
- Configured travel, speed and command limits
- Drive and platform-state reporting
- Platform-side fault and recovery logic
Define the Motion Platform Interface Contract
The interface control document is the engineering baseline shared by the host and platform teams. It converts “we support the same protocol” into agreed data meaning, valid states, fault behaviour and acceptance evidence.
| Contract item | What must be defined | Risk if left open | Acceptance evidence |
|---|---|---|---|
| Data meaning | Command and status fields, types, valid ranges, scaling and invalid-value handling. | Valid packets with incompatible meaning. | Approved command/status dictionary and boundary-value cases. |
| Units & coordinates | Reference frame, origin, signs, units, rotation sequence and transform owner. | Correct magnitudes in the wrong direction or frame. | Positive/negative axis checks and representative combined poses. |
| Timing | Update period, timestamps, jitter tolerance, heartbeat and reconnect sequence. | Intermittent faults that appear only under real network conditions. | Nominal, delayed, dropout and reconnect cases. |
| Missed frames | How missed or stale data is detected and the approved hold, neutral or stop response. | An undefined response when the command stream is interrupted. | Injected data loss with recorded state and platform response. |
| States & commands | Connected, ready, enabled, active, hold, stop, fault, reset and preconditions. | A valid command sent in a state where it must not execute. | State-transition matrix with accepted and rejected commands. |
| Limits & workspace | Configured platform limits and representative multi-axis motion inside the combined envelope. | Repeated limit events caused by treating single-axis maxima as simultaneous capability. | Representative command sequence reviewed against the approved configuration. |
| Version baseline | Controller, firmware, API/SDK, platform parameters and document revision. | An accepted interface becomes an undefined moving target after a software change. | Release record and controlled configuration baseline. |
States, Faults and the Safety Boundary
A useful interface describes more than normal motion. The host must know the platform state, which commands are valid, how a timeout is handled and what is required before recovery.
The API is not the safety chain
Invalid command
Define whether it is rejected, clamped or causes a state change, and which diagnostic information returns to the host.
Heartbeat or data timeout
Define the timeout basis, the platform response, how the host is notified and the controlled restart sequence.
Limit reached
Define whether the command is limited, held or rejected and how the event is distinguished from a drive or safety fault.
Fault and reset
Define recoverable faults, acknowledgement ownership and the physical checks required before reset or re-enable.
Version mismatch
Define how incompatible software, interface and configuration revisions are detected and prevented from running together.
What the Review Produces—and What the Project Accepts
A preliminary review should help you make the next decision without pretending that an unnamed controller, timing guarantee or custom software deliverable has already been contracted.
Feasibility direction
Based on the architecture and objectives you send, the first response identifies the likely route and open decisions.
- Recommended command boundary
- Missing technical inputs
- Major interface and legacy risks
- Next engineering or commercial step
Interface deliverables
The approved quotation and technical specification define the exact items delivered with the platform project.
- Interface control document
- Command and status definitions
- Units, frames, states and fault rules
- Configuration and version baseline
- Interface acceptance cases
Custom engineering
Requirements outside the approved standard route are estimated after the technical boundary is understood.
- Custom protocol or message format
- Customer host development
- Third-party sensor or equipment integration
- On-site commissioning or SAT support
Interface FAT
Factory acceptance cases are selected for the contracted project configuration and agreed evidence format.
- Representative commands and returned status
- State transitions and rejected-command cases
- Configured limit and timeout behaviour
- Fault indication, acknowledgement and recovery
System SAT
Site acceptance adds variables outside the platform subsystem: the real host, site network, payload, guarding, facility services and wider-machine sequence.
- Define whether CSCmotion attends or supplies cases
- Name the complete-system acceptance owner
- Keep regulatory and facility approval outside the API promise
Legacy Controller Upgrades Require Engineering Review
Replacing only the controller changes the behaviour of retained drives, feedback, limits, brakes, wiring, mechanics and safety circuits. A credible review starts with the retained subsystem, not just the controller model.
The review may support a bounded configuration change, identify a wider cabinet or subsystem replacement, or conclude that the available records and retained equipment do not support a responsible upgrade.
Platform identity
Mechanical baseline
Drives & feedback
Electrical & safety
Current software
Change objective
Where to Go Next
A delivery route is one of four decisions. Which platform architecture, what physical job it has to do, how the engineering works and what it costs are answered in their own sections — so nothing here repeats what belongs there.
Motion Platforms
Compare 3DOF, 6DOF and Stewart architectures, electric drive, high-payload and compact configurations, and the motion control system that runs them.
Applications
Industrial testing, research, driving and flight simulation, motion compensation and maritime motion — each brings its own load, duty cycle and validation method.
Technology
Stewart geometry, hexapod kinematics, motion cueing, safety architecture, and how payload, stroke and acceleration constrain each other.
Resources
Buying guides on choosing a platform, budgeting a project, comparing manufacturers and deciding whether to build or buy.
Case Studies
Delivered projects with the requirement, the engineering decisions, the interfaces we owned and the measured validation behind them.
Company
A 20,000 m² production base in Nanjing with in-house servo cylinder and controller manufacturing, ISO 9001 / 14001 / 45001 and documented acceptance testing.
Controller & API Integration FAQ
These answers describe the normal review process. The approved quotation, technical specification and interface control document determine the exact project configuration and responsibility.
Which host interfaces and SDK environments are available?
Possible project routes include network, fieldbus and serial interfaces. CSCmotion controller and software materials cover routes such as TCP/UDP, EtherCAT, CANopen and serial/Modbus for different configurations. The exact transport, message format, SDK language and software deliverables are confirmed for the named project configuration.
What update rate does the motion-platform interface use?
It depends on the controller route, command level, host architecture, network conditions and required fault response. Update period, jitter tolerance, timestamps and missed-frame behaviour are defined together in the project baseline rather than inferred from a protocol name.
Who owns the kinematics and motion-cueing logic?
The normal boundary keeps platform kinematics, actuator coordination and platform-side limits inside the controller. Motion cueing can sit in your host or in an approved platform-side software scope. The interface control document names the owner and the accepted command level.
Does the API replace the machine safety system?
No. The API can report status and request an orderly stop, but it does not replace emergency-stop circuits, guarding, interlocks, travel limits, safe-energy behaviour or the complete-machine risk assessment.
What is included, and what may be quoted separately?
A contracted platform project may include the interface control document, command and status definitions, coordinate and state rules, a configuration baseline and interface acceptance cases. Custom protocols, customer host development, third-party sensors and on-site work are scoped separately when required.
Can you upgrade a third-party or legacy controller?
Only after engineering review. We need the retained mechanical, drive, feedback, electrical, safety, geometry and software baseline. The outcome may be a bounded controller change, a wider cabinet or subsystem replacement, or a recommendation not to retain the existing equipment. See motion platform retrofit support.
Interface feasibility review
Send Your Host Architecture and Success Criteria
Tell us what generates the motion, what you intend to send and what must work at the end. Our first response will identify the likely command boundary, the information still missing and the next engineering step.
Complete moving load, centre of gravity and available CAD
Required axes and one representative motion profile
Installation, mounting, power and environment
Host interface and safety responsibilities
Prototype, first article or expected repeat quantity
FAT, documentation, country and target schedule