- Home
- Custom & OEM
- Controller & API Integration
Custom & OEM · Host software, controllers and the interface between them
Motion platform controller and API, written here rather than licensed in.
Most platform builders integrate somebody else’s controller and pass your questions along to it. The master stack, the kinematics, the washout, the calibration tool and the host software on this page were written in this company — which is why “can that be changed?” has an answer here that is not always no.
Already running a third-party controller? A retrofit is an engineering review before it is a quotation — the legacy section lists the six things we need to see before anyone can say whether it is worth doing.
Six commanded poses, six achieved leg lengths, motor torque and drive status — on one screen, logged to CSV, on the machine that ships.
The question behind every integration enquiry
Whoever wrote the controller decides what can be changed later
Integrators do not really ask which protocols a platform supports. They ask a harder question in a polite way: when this thing does something we did not expect at two in the morning three years from now, is there anyone who can open it?
That answer is set at the beginning and cannot be improved afterwards. A platform builder who buys a finished controller can configure it, cable it and support it, and can do nothing at all about what happens inside it. Every awkward request — a different command layer, a washout parameter exposed, a fault reported differently, a coordinate frame moved onto the workpiece — becomes a request to somebody else’s roadmap.
We are on the other side of that line. The EtherCAT and CANopen masters, the forward and inverse kinematics, the velocity planner, the interpolator, the washout filter, the safety limiter, the calibration tool and the host software are all things this company wrote and maintains. As of the 2024 product manual that work is registered as 45 software copyrights and 8 software products, alongside 99 granted patents from 127 applications.
None of that makes us the right supplier on its own. What it changes is the shape of the conversation: the answer to a request is a schedule and a price, or an honest no with a reason — not a shrug pointed at a vendor.
Anyone can integrate a controller. The useful question is who can modify one.
Have a requirement your current supplier keeps calling a limitation? Describe it and we will say whether it is a limitation or a decision →
cscmotion control interface with live pose and leg curves
Choose the layer before the packet format
Four places a host can attach, and the choice changes who owns the maths
Integration enquiries usually open with a protocol name. The protocol is the easy half. What matters is how far down your software reaches, because that decides who solves the kinematics, who owns the cue, and whose name is on a performance figure.
The 4-Point Attachment Map What you send, what we solve, and what changes for you
| Attachment point | What your host sends | What the controller solves | Suits |
|---|---|---|---|
|
Host application TCP / UDP over RJ45 | A pose — Euler angles or quaternion — at your update rate, with state returned | Everything: kinematics, planning, interpolation, limits, washout if enabled | Most projects. Your software stays above the motion problem entirely |
|
SDK in your code C++ / C# / MATLAB / LabVIEW | Calls from inside your own application, with pose returned by forward kinematics | The same stack, reached as a library rather than as a socket | Test benches, laboratory rigs, anything already written in MATLAB or LabVIEW |
|
Fieldbus EtherCAT / CANopen | Cyclic data at the bus level, either into our master or from your own | Depends on the split agreed — our master, or your TwinCAT or CoDeSys project | Machine builders with an existing automation architecture |
|
Serial RS-232 / RS-485 Modbus | A command frame, at a modest rate | Everything, as at point 01, with a slower and simpler link | Legacy integrations, simple sequences, and equipment already on a serial bus |
Point 01 covers most of what we ship, and it is worth saying why rather than treating it as a default. A host that sends a pose is insulated from every mechanical decision underneath it: change the leg geometry, change the actuator, re-calibrate the machine, and the host code does not change. A host that sends leg lengths has taken on the kinematic model and inherits every consequence of altering the mechanism.
One thing does not move between the four. The hard-wired stop circuit and the mechanical limits sit outside all of them. The control link can report status and request an orderly stop; it is not the safety chain and no attachment point makes it one.
Not sure how deep your software actually needs to reach? Send what your host already outputs and we will name the attachment point →
What happens between a commanded pose and six moving legs
The 9-Module Control Stack
A pose arrives. Nine things happen to it before an actuator moves, and each one is a place where a platform is either well behaved or is not. They are listed here because an integrator evaluating two suppliers deserves to know what is actually in the box, and because the answers differ more than datasheets suggest.
| Module | What it does | Why an integrator should care |
|---|---|---|
| Kinematics | Inverse solution from pose to six leg lengths; forward solution from encoder feedback back to pose | The forward solution is what lets the controller tell you where the platform actually is, rather than where it was told to go |
| Coordinate transform | Moves the motion centre from the platform’s upper plate to a point on your workpiece | Without it, a payload mounted high above the plate translates when you asked it only to rotate |
| Closed-loop control | PID with a linear extended state observer and a differential tracker to suppress overshoot and estimate disturbance | Fewer parameters to tune than a non-linear observer, which matters when the machine is commissioned on site |
| Velocity planning | S-curve acceleration and deceleration between velocity break points, with the path length computed for each segment | Jerk is bounded rather than incidental, which is what keeps a payload and a person comfortable |
| Interpolation | Densifies the trajectory — linear, circular and NURBS interpolation depending on the curve | Decides whether a commanded path is followed or approximated between points |
| Look-ahead | Detects a discontinuity in the trajectory before it arrives and decelerates in time to take it | A parallel mechanism cannot change speed instantly; without look-ahead a sharp road spectrum becomes a fault |
| Washout | Returns the platform toward centre between manoeuvres, using the states human perception is sensitive to | The reason a machine with finite stroke can produce a cue that feels longer than the stroke allows |
| Road excitation | Generates road spectra by white noise, Poisson process, AR model or harmonic superposition | Lets a rig produce a defensible surface input when no measured record exists for that road class |
| Safety limiting | Four avoidance cases: singularity, leg-length limit, joint-angle limit and external obstacle | A commanded pose can be unreachable for reasons belonging to no single axis, and it should be refused with a reason rather than attempted |
Modules 06 and 09 are the two that separate a controller from a motion library. Look-ahead is what allows a high-rate road or sea spectrum to be replayed without the trajectory tearing at every discontinuity; safety limiting is what turns an impossible command into a refusal with a stated cause instead of an alarm nobody can interpret. Both are invisible on a specification sheet and obvious within an hour of commissioning.
Dynamic Model of the Stewart Parallel Robot
Finite Element Analysis of Core Components Such as Servo Electric Cylinders and Articulating Parts
Fifth-order modes of the Stewart parallel robot
Evaluating two controllers and unsure what to compare? Send the other supplier’s module list and we will map it against this one →
The tools that ship with the machine
Seven pieces of software, and only one of them is the thing that moves the platform
A controller on its own is not usable. What makes a platform commissionable by somebody who did not build it is the set of tools around the controller: something to calibrate it, something to watch it, something to model it, and something to write against. These were developed alongside the hardware over successive product generations, which is why they use the same parameter names as the firmware does.
Operate
RuleLab — platform control software
The screen the machine is run from. Motion modes, trajectory configuration, live curves for every axis and every leg, and a recording of the whole run.
Configure
CaliLab — calibration and configuration
Where the machine is described to itself: joint coordinates, cylinder stroke and lead, reduction ratio, PID and planning parameters, pose correction, washout settings and access rights.
Analyse
LocLab — pose and simulation analysis
Forward kinematics from encoder feedback, so the achieved pose can be reported and compared against the commanded one rather than assumed to match it.
The Software Tool Family What each one is for, and when an integrator meets it
| Tool | What it does | When you meet it |
|---|---|---|
| RuleLab | Platform control interface: motion modes, trajectory configuration, live curves for pose, leg length, motor speed, torque and drive status, with data recorded to file | Commissioning, and every day afterwards |
| CaliLab | Parameter calibration and configuration: mechanical parameters, communication settings, planning and PID values, pose correction, permission levels, firmware download | At build, at installation, and after any mechanical change |
| LocLab | Forward kinematic solution and simulation analysis — achieved pose, linear and angular velocity and acceleration | Whenever a figure has to be reported rather than claimed |
| WashLab | Washout filter configuration, with the filter parameters exposed so different frequency bands can be tuned for a scenario | Simulator projects, during cue tuning |
| PowerLab | Dynamics analysis: actuator force, motor torque, speed and power across the working envelope | At sizing, before anything is ordered |
| MathLab | Motion-file capture, editing and format conversion, including conversion between leg-length and pose files | Where the platform replays authored or recorded motion |
| ThinkLab | SDK and real-time measurement: commands and status from inside your own application, with logging | As soon as your software drives the machine directly |
There is an eighth family — playback and show-control software for entertainment installations. It exists, it is part of the same codebase, and it is not what this page is about. Industrial, research and professional simulator projects use the seven above.
Working against it before hardware exists
Demo projects, not a header file and good luck
An SDK that arrives as documentation gets read once. What ships instead is a set of small working projects — sending leg lengths, sending Euler angles, driving from a USB HID device, and a UDP example that takes flight data from a third-party simulator — in both VB and VC, so an integrator can open one, point it at an IP address and watch something respond.
That matters most before delivery. A host application written against a demo project and tested on a loopback is a host application that works on commissioning day, which is the difference between a week of integration and an afternoon.
Interfaces are not proven by documentation. They are proven by somebody else’s code running against them.
Where it meets the tools you already use
The toolchain, for teams that already have one
The hardware the software runs on
Four controller families, and five ways to be an EtherCAT master
Controllers are developed in families rather than as one product, because a compact platform driven over serial and a bus-connected machine in an automation cell do not need the same board. What is common across all of them is the host protocol: the same commands, the same parameters and the same status, whichever board is underneath.
The 5-Variant EtherCAT Master Set Five hardware routes, one host protocol
| Master variant | What it is | Why it exists |
|---|---|---|
| TwinCAT master | The Beckhoff PC-based master, with our motion stack running inside the customer’s automation project | The plant already runs TwinCAT and the platform has to live inside it rather than beside it |
| SoC master | A Zynq-7000 system-on-chip implementation | Where logic and processor have to sit on one device, usually for integration reasons rather than performance |
| Single-board master | A Raspberry Pi implementation | Teaching rigs, laboratory work and prototypes where cost and openness matter more than hardening |
| Cortex-A8 master | An application-processor implementation running under an operating system | Where a richer local environment is wanted on the controller itself |
| Dual-core M7/M4 master | Our own board, running the master stack bare-metal at a 500 µs interpolation cycle | The default: hardware and software both ours, so a specific requirement can be answered rather than routed |
The useful part of that table is not the list of five. It is the sentence all five share: one host protocol across every one of them. Parameter configuration, command sending and status reading are identical whichever master a project ends up on, so a host application written against one is not rewritten if the hardware route changes. That is a deliberate design decision and it costs us flexibility internally; it is worth it the first time a customer changes architecture mid-project.
ACB7xx
EtherCAT master
Bus-connected electric platforms · the current flagship family
The top of the range runs a dual-core 32-bit Arm Cortex-M7 and Cortex-M4 device at up to 480 MHz, with an open-source EtherCAT master stack ported to run without an operating system underneath it, at a 500 µs interpolation cycle.
On the board
- Two 10/100M RJ45 ports, one CANopen port, RS-232 and RS-485
- Six isolated inputs and four low-side driver outputs
- TF card, 256 Mbit flash, 256 Kb EEPROM, DC 9–36 V supply
- Hardware-level clock synchronisation across the bus
Chosen when: the machine is bus-connected, the axis count is high, or synchronisation across devices has to be tight.
ACB6xx
CANopen master
CANopen architectures · DS402 profile
A CANopen master built on an STM32 device under a real-time kernel, supporting SDO and PDO operation under the DS402 drive profile, for distributed control of the servo axes without a PC in the loop.
What it covers
- CANopen master with SDO and PDO under DS402
- TCP and UDP client for host communication and data upload
- Runs the same parameter set and status model as the rest of the range
- Suits installations where CANopen is already the plant standard
Chosen when: the site standard is CANopen, or a CAN bus already exists and adding a second network is unwelcome.
ACB5xx
Pulse and analogue control cards
Electric platforms · broad servo compatibility
Purpose-built cards for electric platforms, carrying the three and six degree-of-freedom platform models internally: they receive attitude data from the host and compute each cylinder’s extension on the board.
What it covers
- Platform model and algorithms resident on the card, so the host sends a pose
- Euler angle and quaternion communication protocols
- Works with most mainstream servo systems — Siemens, Schneider, Yaskawa, Mitsubishi, Panasonic, Delta, Inovance, Estun and others
- Serial parameter interface for tuning speed, smoothness and stiffness with CaliLab
Chosen when: the drives are pulse or analogue commanded, or the customer’s servo brand is already fixed.
ACB4xx
Valve control cards
Hydraulic and pneumatic · outside the electric range on this site
Solenoid and proportional valve driver cards developed for hydraulic and pneumatic platforms, with high per-channel drive current so an external amplifier is not needed.
Worth stating plainly
- Every platform sold through this site is servo electric
- These cards exist because the company also builds hydraulic and pneumatic machines
- They are listed here for completeness rather than as an offer
- Where a project genuinely needs hydraulic force density, we will say so
Chosen when: rarely, on this side of the business. Electric vs hydraulic covers why.
Automation architecture already chosen and non-negotiable? Name it and we will say which master variant the project uses →
The document that prevents a week of arguments
Which way is positive, written down before anybody writes code
Two engineers can agree on a protocol, a rate and a command set, and still build a rig where the platform rolls the wrong way. Sign conventions are the thing everybody assumes is obvious because inside their own company it has been obvious for years.
So the company maintains a written coordinate specification for its parallel platforms, covering two, three, six and seven degree-of-freedom machines, and it is issued with the interface document rather than discovered during commissioning. Four things in it settle most of what goes wrong.
The 4-Part Coordinate Specification What is fixed, and what it prevents
| Part | What it fixes | What it prevents |
|---|---|---|
| Zero and mid position | Zero is every cylinder extended 5 mm from its shortest length; mid position is half the maximum platform height | Two parties quoting travel from two different starting points and both being right |
| Position reference frame | Origin at the centre of the upper joint circle, XY in that plane at mid position, Z vertically up. It stays fixed while the platform moves | Translation figures that drift depending on where the platform happens to be |
| Attitude reference frame | A second frame that follows the platform in translation and does not follow it in attitude rotation | Rotation and translation contaminating each other in the numbers you read back |
| Sign of every axis | Sway positive right, surge positive forward, heave positive up; pitch positive nose-up, roll positive right, yaw positive to the left; the seventh rotary axis over ±180° | The whole class of fault where a rig works perfectly and reads backwards |
Where a customer already has a convention — and vehicle and aerospace customers usually do — theirs wins. Ours is a default and a starting document, not a condition of sale. What is not negotiable is that one of the two gets written down, signed by both sides, and checked channel by channel on the day the host is first connected. That check takes an afternoon; finding the same fault six months later usually means it has already been compensated somewhere else.
Have a convention document of your own? Send it and we will map ours onto it before quoting →
The behaviour nobody specifies and everybody discovers
Two offsets, one timeout, and what happens when your software stops talking
Integration specifications describe what the platform should do while everything is working. The interesting engineering is in the other cases: a dropped frame, a host that crashes, a command outside the envelope, an operator who walks away. Those are configuration decisions, they are made once, and they are made better before manufacture.
Offset one
Run offset
The pose the platform treats as its operating centre. Calibrated rather than assumed, saved in the configuration file, and adjustable without touching firmware.
Offset two
Initial offset
The pose the platform returns to when it has nothing to do. A boarding position, a lowest position, or a deliberate attitude — whichever the installation needs.
The timeout
Roughly five seconds
After about five seconds without a command from the host, the platform moves to the initial offset rather than holding a stale pose indefinitely.
The API can report a fault and request an orderly stop. It is not the safety chain, and no amount of software makes it one.
Writing the fault-handling half of your host application? Ask for the state and fault list before you start →
From a host architecture to a working link
Five stages, and the fourth one happens before the machine exists
Integration goes badly in a predictable way: the interface is settled by email, the platform arrives, and two teams meet for the first time in a room with a deadline. These five stages exist to move that meeting forward by several months, to a point where it costs nothing.
The 5-Stage Interface Bring-Up What each stage produces, and who needs it
ST 01
Read the host
What your software already outputs, in which units and frame, at what rate, over what link. One second of real output answers more than a specification does.
ST 02
Choose the attachment
Which of the four attachment points the project uses, and therefore who solves the kinematics and who owns any performance figure that follows.
ST 03
Freeze the contract
Command set, coordinate convention, sign of every channel, units, update rate, offsets, timeout, fault list and logging. Signed by both sides.
ST 04
Bench-run it
Your code against a demo project and a controller on a desk, before the mechanism exists. The link is proven while changing it is still free.
ST 05
Interface acceptance
On the delivered platform at the delivered load: commands, refusals, faults, timeout behaviour and logging, run against the signed document line by line.
Programme schedule already fixed around a delivery date? Ask for these five stages with your dates written against them →
Where our software stops and yours begins
What we deliver, what stays yours, and what gets quoted separately
Software scopes go wrong more often than mechanical ones, because software feels infinitely adjustable and therefore feels free. These four zones go into the proposal so the boundary is visible while it is still a paragraph.
Ours
- The controller, its firmware and the motion algorithms in it
- The API, the SDK and the demo projects that come with it
- RuleLab, CaliLab and the configuration tools
- The interface document, and the acceptance run against it
- The calibration and configuration record for the delivered machine
Never ours
- Your host application, and whatever it models or scores
- The content, scenario or test sequence the motion serves
- Your network, its topology and its security
- The decision to run, continue or stop an operation
- Any conclusion drawn from what the machine did
Outside our class of work
- A certified functional safety system as a product
- Control retrofits on machines we did not build, without a review first
- Industrial PCs, servers and IT infrastructure
- Certification or regulatory work of any kind
Signed by both
- The attachment point and the command level
- The coordinate convention and the sign of every channel
- Update rate, and behaviour on lost frames and on timeout
- The fault list, and what gets logged and where
Software feels free to change, which is exactly why the boundary has to be written before anyone starts changing it.
Drafting a software scope for a subcontract? Send the draft and we will mark what is standard and what is extra →
Retrofits and third-party controllers
An old platform with a dead controller is an engineering review, not a part number
A recurring enquiry: a working mechanism, an obsolete or failed controller, and a supplier who has stopped answering. Sometimes this is a good project and the machine gets another decade. Sometimes the honest answer is that the mechanism is the problem and the controller was only the symptom.
Which of the two it is cannot be decided from photographs. It is decided by six things, and every one of them changes the answer.
What comes back from the review is a direct position: a scope and a price, a shorter scope with the parts we would not touch named, or a recommendation not to proceed with the reason. The third outcome is more common than a supplier would normally admit, and it is cheaper for both of us than a retrofit that ends up costing more than the machine is worth.
A retrofit that costs more than the platform is worth is not a saving. We would rather say so in the review than at the invoice.
Have a platform sitting idle because its controller failed? Send the six items and we will say whether it is worth doing →
The 6-Item Retrofit Review What has to be on the table before anybody quotes
| Item | What it decides |
|---|---|
| Platform identity | Architecture, axis count, maker and age — whether a kinematic model for it already exists |
| Mechanical baseline | Joint coordinates, cylinder stroke and lead, reduction ratio, and the current condition of the load path |
| Drives and feedback | Motor and drive types, encoder or sensor arrangement, and whether any of it is still supported |
| Electrical and safety | Cabinet, supply, stop circuit and limit arrangement — usually the part that decides the price |
| Current software | What runs today, what documentation survives, and what the operator actually uses |
| Change objective | What has to be different afterwards. A retrofit to restore is a different project from a retrofit to extend |
The fourth row is the one that surprises people. Replacing a controller is often straightforward; bringing a twenty-year-old cabinet, stop circuit and limit arrangement to a state anybody will sign for is where the work is.
The decisions around this one
Reference reading before a controller specification
Four pages that answer questions this one raises and deliberately leaves to them: what the motion is for, why the machines are electric, what the trade-offs cost, and what the words mean.
Applications
What the controller is being asked to do
Six applications, sorted by what has to be convinced — an instrument, a method, a person or a sensor. The answer changes what the interface has to carry.
Actuation
Electric or hydraulic
Why every platform sold through this site is servo electric, what that means for the controller, and the small number of cases where it is the wrong answer.
Trade-off
Payload, stroke and acceleration
Why raising one of the three lowers the others, and why the duty profile changes a sizing answer more than a peak figure does.
Vocabulary
Motion platform glossary
Motion reference point, gross moving load, washout, forward and inverse kinematics — one definition each, so an interface document means the same thing in two companies.
This page sits under Custom & OEM, which covers how a machine gets drawn around a constraint rather than selected from a range. If the mechanism is settled and only the controller is in question, this page is the right one; if the geometry is still moving, start there.
Asked before an interface is specified
Controller & API integration FAQ
Which host interfaces and SDK environments are available?
Host link over TCP or UDP on RJ45, RS-232, RS-485 with Modbus, and fieldbus by EtherCAT or CANopen. Pose can be sent as Euler angles or as a quaternion. The SDK is supplied for C++, C#, MATLAB and LabVIEW, with small working demo projects rather than only a header file and documentation — sending leg lengths, sending Euler angles, driving from a USB HID device, and a UDP example taking data from a third-party flight simulator. Which combination a project uses is fixed at the interface review, because it changes the controller configuration rather than only the cabling.
What update rate does the interface run at?
Two different numbers get confused here, so both are worth stating. The interpolation cycle on the dual-core EtherCAT master is 500 µs — that is what happens inside the controller. The rate your host actually commands at is a separate figure, decided by the attachment point, the link and what your software can sustain, and it is agreed at the interface review rather than assumed. If a project has an end-to-end latency requirement, we itemise the budget: your model step, your network, our command interval, our solution and the servo response, with the parts that are ours separated from the parts that are not.
Who owns the kinematics and the motion cueing?
Whichever attachment point the project uses, and it should be an explicit choice. Send a pose and the controller owns the kinematics, the planning, the limits and the washout if it is enabled — one party is then responsible for how the machine behaves. Send leg lengths and you have taken on the kinematic model, which means a later change to the mechanism becomes a change to your software. Run your own master over the bus and more moves again. All three are things we build; the expensive answer is leaving it undecided until commissioning.
Does the API replace the machine safety system?
No, and this is the one answer on the page with no nuance in it. The control interface can report status, raise faults and request an orderly stop. The hard-wired stop circuit, the mechanical limits and the workspace protection sit outside the control link at every attachment point, and they stay outside it whichever way the rest of the architecture is arranged. We do not supply a certified functional safety system as a product, and the safety case for an installed machine belongs to whoever owns the installation.
Can we run our own control law, or our own EtherCAT master?
Yes to both, and each has a consequence worth agreeing in writing first. Running your own master — a TwinCAT or CoDeSys project, typically — puts the cyclic behaviour in your hands and means our motion performance figures describe a configuration you are not using. Putting your own control law inside the loop does the same thing more sharply. Where a project needs either, acceptance runs against our configuration first, that record becomes the reference, and your work starts from a known machine rather than from an argument.
Can you upgrade a third-party or legacy controller?
Sometimes, and it starts as a review rather than a quotation. Six things decide it: the platform identity, the mechanical baseline, the drives and feedback, the electrical and safety arrangement, what software runs today, and what has to be different afterwards. The electrical and safety row usually decides the price — swapping a controller is often easy, and bringing an old cabinet and stop circuit to a state somebody will sign for is not. Where a retrofit would cost more than the machine is worth, that is what the review says.
What is included, and what gets quoted separately?
Included: the controller, the standard API and SDK with demo projects, the configuration and calibration tools, the interface document, and the acceptance run against it. Quoted separately when a project needs them: a bespoke protocol adapter for a format we do not already speak, a host application written to your specification, on-site integration support beyond the days in the contract, and re-issuing the interface document into your own document template. None of these are unusual and none of them are free, so they are priced at the start rather than discovered at the end.
Why is your quotation higher than a supplier offering the same axis count?
Usually because of what is on this page rather than what is in the mechanism. Ask the other supplier who wrote their controller, and what happens to a change request that their vendor declines. Ask whether an SDK exists and whether working demo projects come with it. Ask whether the coordinate convention is a document or a conversation, whether the timeout and fault behaviour are configurable and stated, and whether an interface acceptance is included or is called commissioning support. Those five account for most of the gap, and all five are cheap to ask about and expensive to discover.
Commercial questions — lead time, payment terms, spares, installation — are answered in the full FAQ.
Send your host architecture. The first reply names the attachment point.
What your software already outputs, at what rate, over what link, and what the platform has to do with it are enough for a first pass. If the right answer is that your existing controller should stay and only the tooling around it needs work, that is what you will hear back.
What comes back first
- Which of the four attachment points the project uses, and what that decides about who owns the maths
- Which controller family it lands on, and why that one rather than the others
- A draft interface contract — commands, units, signs, rate, offsets, timeout and fault list
- What is standard in the price and what would be quoted separately, itemised