§8 xArm 6
Control, Communication and Programming Interfaces
How people and programs talk to the arm: Studio, the SDKs, ROS, Modbus and the controller's inputs and outputs.
Start Here
This section is about how people and other machines talk to the arm: the software, the network, the wires on the control box and the connector at the tool end, and how to choose between them. Read the short list below first, because one abbreviation here means something different from the rest of the site.
Studio, Python, C++, ROS
UFACTORY's programming routes1
8 CI + 8 DI
digital inputs on the control box, with 8 CO + 8 DO outputs2
30 m
longest I/O cable unless extension testing shows more works3
- UFACTORY's common specifications for the xArm 5, 6 and 7 list four programming routes: UFACTORY Studio, Python, C++ and ROS1.
- The lab uses the UFACTORY Studio desktop app, downloaded from UFACTORY and installed on the computer45. UFACTORY's manual also describes opening Studio in a web browser6.
- In the cell, the arms are currently understood to be operated manually mainly through UFACTORY Studio7.
- The control box I/O can be used with many devices, including pneumatic relays, PLCs and emergency stop buttons8.
- Here "TCP" mostly means a network protocol: UFACTORY gives the arm's protocol as "Private TCP(custom)", over Ethernet9. In "TCP offset" and elsewhere on the site, TCP stands for Tool Center Point10.
S6 in one line: S6 is a UFactory xArm 6 cobot that handles parts after processing, routing them to inspection, rework or shipping11.
Look Back
A question from earlier on, to keep it fresh. Skip it if you like; nothing depends on it.
Choose your depth
1Beginner
How You Talk to the Arm
For: Anyone with no robotics background: a visitor, a new operator, a manager
Kind of task: Recognize and recall, with plain-language explanations and pictures
In this part you learn the ways a person or a machine can tell the arm what to do, how a computer reaches it over the network, and the one wiring rule you must never break. No programming background is needed.
Four Routes
- UFACTORY lists four routes for programming the xArm 5, 6 and 7: UFACTORY Studio, Python, C++ and ROS1.
- Studio's user manual names the xArm 6 among the arms it covers12.
- Studio is the graphical route. For the others, the product page says the Python and C++ SDK (a software kit for your own programs) is open source, and ROS and ROS2 packages are available1314.
UFACTORY Studio
- Studio is a graphical application for controlling the arm. With it you set parameters, move the arm from the screen in Live Control, and build a motion by dragging and dropping Blockly blocks13.
- Blockly lets you program the arm without writing code15.
- The lab uses the Studio desktop app: download it from UFACTORY and install it on your computer45.
- To connect, enter the control box's IP address in the app's IP search field and click Connect Server, as on the xArm 85016.
- UFACTORY's manual also describes opening Studio in a web browser, at the control box's IP address followed by :18333176. The lab uses the desktop app4.
The Network
- The manual gives four ways to connect the control box. The recommended one connects it straight to your computer. The others go through a router or a network switch18.
- One of the router options puts the computer on Wi-Fi. It is not recommended, because of wireless delay and packet loss18.
- The arm's default address is in the range 192.168.1.xxx, and your computer must be on the same network segment as the control box19.
Wires to Other Machines
- Besides the network, the control box has its own inputs and outputs. There are 8 configurable and 8 general digital inputs, the same number of digital outputs, 2 analog inputs, 2 analog outputs and one RS-485 port2.
- They can be used with equipment such as pneumatic relays, PLCs and emergency stop buttons. All I/O must meet the manual's electrical specifications8.
The Tool End Has Its Own Connector
- At the tool end there is a 12-pin connector that supplies power and control signals to grippers and sensors20.
- The tool and gripper connected there must not cause danger when power is cut, such as a part dropping from the tool21.
The Rule You Must Never Break
- Never connect a safety signal to a non-safety PLC, an ordinary controller for factory machines. The manual warns that doing so may cause serious injury or death, because the safety stop function may not work22.
- Section 7 teaches the safety wiring. Whatever is wired, stay out of the arm's working area while it runs, and do not rely on a safeguard nobody has confirmed23.
Check Yourself
Answer, then check. Each option has its own feedback, and nothing is scored.
2Novice
The Routes, and What the I/O Can Do
For: Someone who will work near or with the cell: operator, trainee technician
Kind of task: Explain and sequence: put steps in order, match parts to their functions
In this part you see what each programming route offers, how the arm sits on the network, and what the control box and tool-end wiring can be set up to do. It is for someone who will work near the cell or connect a simple device to it.
What Each Route Offers
- Blockly's toolbar can convert a block program to Python code15.
- No dedicated teach pendant for the xArm 6 is documented. The sources describe Studio, the SDKs and hand teaching24.
- The Python SDK is installed from PyPI with pip install xarm-python-sdk, and only Python 3 is supported25.
- In this cell, Python will be the primary coding method27.
- The ReadMe of xarm_ros2, UFACTORY's ROS 2 package, says its quick-start instructions are based on the xArm 628.
On the Network
- Studio's Device Info page shows the arm's IP address, subnet mask, broadcast address and default gateway. If you change the IP address, the manual says to mark it on the control box29.
What the Control Box Inputs and Outputs Can Be Set to Do
- Each configurable input CI0-CI7 can be set as General Input, Stop Moving, Safeguard Reset, Offline Task, Manual Mode, Reduced Mode or Enable Robot. The general inputs DI0-DI7 support the same list except Stop Moving, Safeguard Reset and Reduced Mode30.
- Each output can be a General Output, or as a status signal: Motion Stopped, Robot Moving, Error, Warning, Collision, Manual Mode, Reduced Mode, Offline Task Running, Robot Enabled, or Emergency Stop is Pressed31.
- Three input functions act on the arm. Offline Task triggers Blockly projects, Enable Robot enables the arm, and Manual Mode lets the arm be dragged freely while the input stays low32.
- Configured functions are triggered by a low-level signal. A Blockly or SDK program may use an input freely only when it is set as General Input. For example, if CI0 is an offline task, it should not be used in any program33.
- Out of the box, the digital inputs read high, the digital outputs are low, and the analog outputs sit at 0 V, with a range of 0-10 V34.
Wiring It to Another Machine
- Digital I/O can talk to other machines or PLCs if both sides share a common GND (0 V) and the other machine uses open-drain outputs. An I/O cable to other equipment must not be longer than 30 m unless extension testing shows a longer one works3.
The Tool-End Connector in Detail
- The connector's pins: +24 V on pins 1-2, GND on 3-4, a user RS-485 pair on 5-6, tool outputs TO0 and TO1 on 7-8, tool inputs TI0 and TI1 on 9-10, and analog inputs AI0 and AI1 on 11-1235.
- Studio's End Effector IO page shows the tool I/O and refreshes at 5 Hz36.
Stopping from the Screen Is a Software Stop
- Studio's STOP button stops the arm at once and clears all cached commands. It is a software stop, and power stays on37.
- This project's advice: do not count a software stop as an emergency stop or safeguard in the cell's risk assessment, a concern Section 7 takes up38.
The Simulated Arm Is Not a Separate Arm
Check Yourself
Answer, then check. Each option has its own feedback, and nothing is scored.
3Intermediate
Modes, Electrical Detail and Error Handling
For: Someone who will set up, program or maintain the arm: technician, student engineer
Kind of task: Apply: work through written scenarios that need a decision (which mode, which setting, what to do about this error), with feedback on each choice
In this part you follow a Python command to the arm, learn the modes and states that decide whether it moves, the electrical limits of the wiring, and the codes the arm sends back when something goes wrong. It is for someone who will set up, program or maintain the arm.
How a Python SDK Command Reaches the Arm
- Your program creates an XArmAPI object, imported from xarm.wrapper, and passes an IP address as its port parameter42.
- The control box is in mode 0, position control, by default after start-up. Setting state 0 clears the error code, and the reported state then switches to 2, ready43.
- In mode 0, set_servo_angle makes point-to-point joint moves and set_position makes straight-line Cartesian moves44.
- The call returns a code, and 0 means success45.
- The SDK's configuration sets its control port to 502 and its report ports to 30001, 30002 and 3000346.
- The Python SDK and Blockly use degrees for joint angles and for roll, pitch and yaw, while the communication protocol uses radians. X, Y and Z are in millimeters in all three47.
Modes and States
- The controller has 7 motion modes and 6 states, which correspond to the SDK calls set_mode() and set_state()48.
- Mode 1 is servo mode: set_servo_angle_j moves to each joint target at the fastest speed, with no buffer, running only the latest target received49.
- Mode 2 is manual mode, for dragging the arm to teach it. A request for mode 2 from any other non-zero mode first switches to mode 0, and takes effect only on a second command50.
- State 3 pauses a motion and state 0 resumes it. State 4 stops the arm and ends any execution at once; the arm then takes no new command until it is set back to STANDBY. The controller also switches to state 4 by itself when any error occurs51.
- State 5 is entered by itself when a critical setting changes, such as the mode, payload, TCP offset or collision sensitivity, and the arm takes no command until state 0 is set. State 6 is a decelerated stop52.
- The sources name state 2 differently: the SDK's list calls it "sleeping", while the Studio manual says the arm is ready to receive and execute commands53.
Other Ports on the Same Controller
- Studio's Modbus TCP page sends standard Modbus TCP commands to the controller's IP address on port 502, which cannot be changed54.
- The Developer Manual gives the automatic report rates: port 30003 at 100 Hz, and ports 30001 and 30002 at 5 Hz55.
Electrical Limits of the Control Box I/O
- The digital I/O runs from the internal 24 V supply by default, which gives 23-30 V at up to 1.8 A. An external supply for more current must give 20-30 V, up to 3 A56.
- The digital outputs are NPN: an output that is on pulls its terminal to GND. Each is rated up to 100 mA, with no current protection, and going past the specified values may cause permanent damage57.
- The digital inputs have a weak pull-up, so an unconnected input reads high. An input is ON at 0-5 V and OFF at 15-30 V58.
- The analog I/O works at 0-10 V with 12-bit resolution, and each analog output can supply up to 20 mA59.
Electrical Limits of the Tool I/O
- The tool connector supplies 20-30 V at up to 1800 mA60.
- Tool inputs work the other way round from the controller's: a pull-down makes an unconnected tool input read low. Logic low is at most 1.0 V and logic high at least 1.6 V6158.
- Tool digital outputs are NPN open-collector, sinking up to 100 mA, with no current protection. A protection diode is strongly recommended for inductive loads62.
- The manual's tool connector has two digital inputs, TI0 and TI1, two digital outputs, TO0 and TO1, and two analog inputs, AI0 and AI1, beside 24 V, ground and one RS-485 pair35.
- The sources also disagree on the end-effector protocol: one manual table says Modbus TCP, while the Developer Manual says Modbus RTU63.
When Something Goes Wrong
- Errors and warnings are not pushed to you: they come back in the reply to your next command. After an error the arm stops at once, drops its cached commands, and the error must be cleared by hand64.
- UFACTORY's recovery through the SDK is three calls: clean_error(), then motion_enable(true), then set_state(0)65.
- API code -1 means the arm is not connected and -2 that it is not ready. Codes 1 and 2 mean uncleared errors or warnings, and 9 that the state is not ready to move45.
- Studio prefixes codes: C for control box errors, S for joint servo errors and A for Python SDK codes. Controller error code C1 is the control box emergency stop button and C3 the three-state switch's emergency stop. C2 is also an emergency-stop code: the Studio manual as read on 2026-10-13 says an emergency stop button is pushed in, where until that date it said the control box's emergency I/O had been triggered6667.
- C22 is a self-collision, C23 a joint past its limit, C24 speed past its limit, C35 the safety boundary and C37 abnormal motion in manual mode6869.
Check Yourself
Answer, then check. Each option has its own feedback, and nothing is scored.
4Expert
Choosing an Interface
For: Someone who designs, integrates or changes the cell: integrator, engineer, agent developer
Kind of task: Analyze and decide: weigh trade-offs, resolve contradictions, critique a configuration
In this part you weigh the interfaces: how fast each is, who else must reach the arm, what each lets you read back, and how firm the evidence is. It is for someone who designs, integrates or changes the cell, including an agent that will drive it.
The Candidates
- Studio and Blockly: the graphical application, for parameters, Live Control and Blockly programs13.
- Python SDK: its XArmAPI class takes an IP address as its port parameter, and its control port is 5024246.
- The private protocol underneath: the Developer Manual calls it "Private Modbus-TCP", on default TCP port 502, with 0x00 0x02 as its only protocol identifier for now72.
- ROS 2: the xArm 6 driver is started with ros2 launch xarm_api xarm6_driver.launch.py robot_ip:=<controller IP>, and its services and topics sit under a hardware namespace that defaults to xarm73. MoveIt launch files exist for a simulated xArm 6 and for the real arm74.
- Modbus TCP: standard Modbus TCP commands on port 502 at the controller's address54.
- Discrete I/O: the control box's wired inputs and outputs, whose input functions include Offline Task and Enable Robot32.
Rate and Latency
- In servo mode, mode 1, set_servo_angle_j runs only the latest target received, with no buffer, at the fastest speed of 180°/s. The control box accepts up to 250 Hz and loses commands sent faster. UFACTORY suggests smoothed, interpolated points, preferably at 100 Hz or 200 Hz, and warns not to give a distant target at once49.
- For reading state, the Developer Manual gives port 30003 at 100 Hz and ports 30001 and 30002 at 5 Hz55. The 100 Hz report carries the motion state and mode, the number of cached commands, joint angles, the arm's position and attitude, and joint torque75.
- Queued commands behave differently. By default set_cgpio_digital puts an output change into the motion queue, and sync False applies it at once, from firmware 2.4.10176. Warning 11 means the command queue is full77.
Who Else Must Talk to the Arm
- Not this cell's primary method: stored Blockly projects are started over Modbus TCP by writing up to 16 holding registers from address 0x30 with function code 0x10. Each value picks a project by number, and the projects run automatically in order78.
- The same can be done with wiring: an input set as Offline Task triggers Blockly projects, on CI0-CI7 or DI0-DI741.
- Over Modbus TCP, coils and discrete inputs 0-31 are the controller's digital outputs and inputs, and 32-39 the tool's79.
What Each Route Lets You Read Back
- Over Modbus TCP, holding registers 32 and 33 hold the robot mode and state, and input registers 32 and 33 the error and warning codes80.
- Over the SDK, get_err_warn_code() returns the current codes, and with reporting on, a callback runs when either code changes81.
- The SDK's get_tgpio_digital and get_tgpio_analog read the tool inputs, and set_tgpio_digital sets the tool outputs82.
How Firm the Evidence Is
- Every Modbus TCP register and function-code record here is Inferred. The ModbusTCP manual they come from names no robot model; the Studio manual, which lists the xArm 6, says the controller accepts standard Modbus TCP on port 502, and the UFACTORY sources written for the xArm 6 do not give the register map8354.
- Reading those registers on a real controller would confirm them80.
- The xarm_ros2 quick-start instructions are based on the xArm 628.
A Worked Selection for an Agent
An agent driving the arm needs a path for its commands, one for signals from the other stations, and one for safety. Advice this project gives is marked as this project's, not UFACTORY's.
The Agent's Commands: Python SDK, Position Mode
- In this cell, Python will be the primary coding method27.
- This project's advice: command motion through the Python SDK in mode 0, rather than streaming servo-mode targets, and read state from its automatic reports84.
- The project's reasoning: in mode 0, joint and straight-line moves are complete commands, so each can be checked before it is sent8444.
- The cost: servo mode, which runs only the latest target at the fastest speed, is not used8449. Errors come back only in the reply to the next command, so state is best read from the report ports6484.
- The project infers that an agent driving the SDK could change collision sensitivity, including to 0, which disables collision detection, and also collision rebound, reduced mode and the safety boundary. Under the manual's warning, that would make a new system whose risk assessment must be updated85.
- The calls exist: set_collision_sensitivity takes 0 to 5, and save_conf() keeps settings across a restart86. set_reduced_mode and set_reduced_tcp_boundary need firmware 1.2.0 or above, and set_fence_mode and set_collision_rebound 1.2.11 or above87.
- This project's advice: deny the agent those calls, or gate them behind human approval88.
Signals from Other Stations
- The documented pieces: an input read by a program must be set as General Input33, wired digital I/O needs a common GND and open-drain outputs on the other side3, and starting projects over Modbus TCP relies on an Inferred register map78.
Safety: Hardwired, Outside the Agent
- This project's advice: treat collision detection, the safety boundary and reduced mode as configurable controller functions, not validated safeguards. They must not replace risk-assessed protective devices wired to the EI and SI inputs89.
- UFACTORY provides two fixed safety inputs, an emergency stop input and a protective stop input, in redundant pairs kept in two separate branches26. It warns never to connect a safety signal to a non-safety PLC22.
- The UFACTORY sources do not say whether the software safety functions are enforced independently of the motion-command path90.
- The SDK's emergency_stop() is set_state(4), then motion_enable(True), then set_state(0), and it does not clear errors. Studio's STOP is a software stop, and power stays on37.
- The control box's emergency stop button, by contrast, removes the arm's power within 300 ms71.
- This project's advice: never count a software stop as an emergency stop or safeguard in the cell's risk assessment38.
Sources Disagree
- On C31 and C33: the Studio manual calls C31 abnormal current in the arm and C33 a controller IO error; the SDK calls 31 a collision-caused abnormal current and 33 a controller GPIO error; the Developer Manual calls C31 collision-caused and C33 abnormal current.91.
- On state 2: the SDK calls it sleeping, the Studio manual ready53.
- On the end-effector protocol: Modbus TCP in one manual table, Modbus RTU in the Developer Manual63.
Simulation Is Not a Substrate
- This project's advice: do not use Studio's simulated arm as the simulation substrate for agent work. It needs a real arm connected, its settings apply to the real arm, and its unlock-joint button unlocks the real joints92.
Check Yourself
Answer, then check. Each option has its own feedback, and nothing is scored.
Not settledOpen Questions · 20
What the sources do not settle for this section. Nothing here is papered over with a plausible number.
- Kind: Gap
No dedicated teach pendant for the xArm 6 is documented in the xArm manual or the product page: they describe programming through the browser-based UFACTORY Studio, the SDKs and hand teaching.
See reference 24 - Kind: Contradiction
The Python SDK and the Studio manual name state 2 differently: the SDK's state list calls it 'sleeping', while the Studio manual says the robot is ready to receive and execute commands.
See reference 53 - Kind: Contradiction
Sources disagree on the xArm end-effector communication protocol: the online xArm manual's common specification table (and its Gripper table) say Modbus TCP, while the xArm Developer Manual's common specifications and gripper table say Modbus RTU, and the online manual's own Tool RS485 section configures standard Modbus RTU devices.
See reference 63 - Kind: Contradiction
UFACTORY's sources give two readings of controller error 2 (Studio's C2). The Studio manual until 2026-10-13, and the Python SDK's code list, say the Emergency IO of the Control Box is triggered; the manual's fix was to ground the 2 EIs of the Control Box and click 'Enable Robot'. The Studio manual as read on 2026-10-13 says the Emergency Stop Button is pushed in, and to release it and click 'Enable Robot'; it no longer mentions the Emergency IO or grounding the EIs. No fetched source says the two describe the same event, or which Studio and firmware versions show which text.
See reference 67 - Kind: Gap
No fetched UFACTORY source says whether the software safety functions (collision detection, safety boundary, reduced mode) are enforced independently of the motion-command path. Studio's description of the safety boundary mentions only the tool center point, and no source says whether the arm's links or the tool body are checked against it.
See reference 90 - Kind: Contradiction
Sources disagree on controller codes C31 and C33. UFACTORY Studio's manual calls C31 'Abnormal current in the robotic arm' and C33 'Controller IO Error'; the Python SDK code list calls 31 'Collision Caused Abnormal Current' and 33 'Controller GPIO error'; the xArm Developer Manual calls C31 'Collision Caused Abnormal Current' and C33 'Abnormal current in the robotic arm'.
See reference 91 - Kind: Gap
No Ethernet connection, camera port, force-torque sensor interface or user button at the xArm 6's tool end is described in the xArm manual or the product page; the product page lists the end-effector I/O as 2 DI, 2 DO, 2 AI and 1 RS-485.
See reference 97 - Kind: Gap
The IP address of the xArm 6 control box at S6, and how the S6 network is laid out (direct PC link, router or switch), are not in the sources; the manuals give only the default range 192.168.1.xxx and the reset address 192.168.1.111.
See reference 98 - Kind: Gap
Which hardware version the S6 xArm 6 is has not been recorded. The online xArm manual's Preface and Hardware Installation chapter state they apply to models XF1305, XI1305 and XS1305, so the sources do not settle whether the manual's descriptions fit the S6 arm.
See reference 99 - Kind: Gap
What tool inputs TI2-TI4 and outputs TO2-TO4 are on the xArm 6 is not documented: UFACTORY Studio lists TI0-TI4 and TO0-TO4, but the xArm manual's tool connector defines only TI0, TI1, TO0 and TO1.
See reference 100 - Kind: Gap
Whether the xArm 6 has an Ethernet connection at the end flange is not answered by the sources fetched: the xArm manual's Robotic Electrical Interface chapter has an 'End Flange' heading with no text, and its tool I/O pins carry no Ethernet.
See reference 101 - Kind: Contradiction
UFACTORY's sources list different sets of tool digital outputs, and none says which the xArm 6 has beyond TO0 and TO1. The product page gives the end-effector I/O as 2 digital outputs, and the xArm manual's tool connector pin table defines TO0 and TO1. UFACTORY Studio's End Effector IO page, which is not written for one model, lists TO0, TO1, TO2, TO3 and TO4. Studio's 'Clear the IO output when the robot is stopped' option names TO0/TO1/TO3/TO4 as the page read on 2026-10-13 (TO0/TO1 on 2026-09-21). No source says what TO2, TO3 and TO4 are on the xArm 6 (iface-564).
See reference 102 - Kind: Contradiction
UFACTORY's documents disagree on the range of the control box's analog inputs AI0 and AI1. The 850 and xArm hardware manuals say the analog interface sets or measures 0-10 V. The Studio manual's Blockly chapter, as read on 2026-10-13, says the Get AI block returns 0–3 V, and gives 0–10 V for AO0 and AO1. Neither says the other is wrong.
See reference 103 - Kind: Contradiction
UFACTORY's documents give one page of UFACTORY Studio two names. The xArm manual says a standard Modbus RTU end effector is debugged under 'Settings-Externals-Modbus RTU'. The Studio manual's Settings chapter, as read on 2026-10-13, heads its section 7.2.5, under 7.2 Externals, 'RS-485'; until that date the section was headed 'Modbus RTU'. UFACTORY's release note for Studio V2.8.2 names the page 'Settings - Externals - RS-485'; no fetched source says from which Studio version the page carries that name.
See reference 104 - Kind: Contradiction
UFACTORY's documents and the lab give different ways to open UFACTORY Studio for the xArm 6. The Studio manual says Studio is reached through a browser without installing any software, by entering the control box's IP address followed by :18333 (iface-504, iface-505), and UFACTORY's xArm product page calls it web-based software inside the control box, with no installation needed (comp-535, res-512). As reported on 2026-10-23, the lab opens Studio with the desktop app, which learners download (ops-712), and, as seen with the xArm 850, connects it with the app's IP search field and its Connect Server button (ops-711). For operating the arm in the lab, the desktop app is current. The manual's and the product page's records are not superseded: they still say what UFACTORY's documents say.
See reference 105 - Kind: Gap
The physical I/O that will carry signals between S2 and S4 (and the other stations) is not defined. It may differ from the simulation's signals.
See reference 106 - Kind: Gap
What S2 publishes to the other agents or the hub is not defined: placement confirmations, S3 slot updates, faults and error codes, its own ready or busy state, and whether any work-order or traceability data passes through S2. IntelliMake says this will be developed as the simulation is created.
See reference 107 - Kind: Gap
Whether camera C1's or S11's output reaches S2 or the shared hub, and in what form, is not documented, and IntelliMake does not yet know.
See reference 108 - Kind: Contradiction
UFACTORY's Studio manual has given two readings of controller error C24. Until 2026-10-13 the row was titled 'Speed Exceeds Limit' and said to check whether the xArm is at a singularity point, or to reduce the speed and acceleration values. As read on 2026-10-13 it is titled 'Joints Speed Exceeds Limit', shows the joint and its speed, and says to check whether the robot is out of its working range, or to turn on 'Use Approximate Solution' under General > Advanced Settings; the row no longer names a singularity or reducing the speed and acceleration, though the manual's Settings chapter describes 'Use Approximate Solution' as using an approximate solution to pass singularities. The Python SDK's code list gives 24 as 'Speed Exceeds Limit', a title only. The manual does not say the earlier handling no longer applies, and no fetched source says which Studio versions show which text.
See reference 109 - Kind: Contradiction
Sources disagree on the xArm's end-effector communication protocol: the manual's common specification table says Modbus TCP, but the product page says Modbus RTU over RS-485, and the manual's own Tool RS485 section configures standard Modbus RTU end effectors. The manual's Gripper table likewise pairs RS-485 communication with a 'Modbus TCP' protocol.
See reference 110
ProvenanceReferences · 110
Each number in the text points here. Every entry states its confidence class in words and keeps its evidence one click away. How to read the labels.
Key to the badges
- Confidence: Verified
- A manufacturer or IntelliMake document says so, or it was observed directly. It does not mean anyone measured it at S6.
- Confidence: Inferred
- Reasoned from Verified facts. The reasoning is printed with the record.
- Confidence: Assumed
- Plausible but untested. The record says how it would be checked.
- Kind: Gap
- Not known. No figure or answer is given in its place.
- Kind: Contradiction
- Sources disagree. Both sides are shown, and the site does not pick one silently.
- Kind: Recommendation
- Project advice drawn from the records it cites. Not a fact about the machine and not a confidence class, so the filter never hides it.
- Awaiting cell access
- Awaiting cell access: could be confirmed or corrected once the physical S6 cell can be observed.
- This project's simulation and agent design, not the physical cell
- This project's simulation and agent design, not the physical cell.
Image Credits
- 3D model: © 2018 UFACTORY Inc., BSD-3-Clause, from UFACTORY Inc. (xArm-Developer/xarm_ros2). License text · Source
Sources for This Section
- IntelliMake Phase 1 Factory: Autonomous Production Demonstrator (infographic) · IntelliMake.org (IntelliMake)
- Owner statements from 2026-09-24 onward (verbatim; S40 and later) · Derek Stringfellow (project owner)
- Owner statements, 2026-09-21 (verbatim) · Derek Stringfellow (project owner)
- UFACTORY 850 Hardware Manual (online), 3. Controller Electrical Interface · UFACTORY (manufacturer)
- UFACTORY ModbusTCP User Instructions (xArm-Python-SDK doc/UF_ModbusTCP_Manual.md) · UFACTORY (manufacturer)
- UFACTORY Release Note v2.8.2 · UFACTORY (manufacturer)
- UFACTORY Studio product and download page · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 1. Preface · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 10. Robotic Arm Motion Mode and State · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 12. Error Handling · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 2. Glossary · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 3. Connection · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 4. Live Control · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 5. Blockly · UFACTORY (manufacturer)
- UFACTORY Studio User Manual (online), 7. Settings · UFACTORY (manufacturer)
- UFACTORY Studio User Manual, 12. Error Handling, as it read until 2026-10-13 (publisher's repository, commit 533b75d) · UFACTORY (manufacturer)
- UFACTORY Studio User Manual, 7. Settings, as it read until 2026-10-13 (publisher's repository, commit 533b75d) · UFACTORY (manufacturer)
- UFACTORY xArm Hardware Manual (online), 1. Safety · UFACTORY (manufacturer)
- UFACTORY xArm Hardware Manual (online), 2. Hardware Installation · UFACTORY (manufacturer)
- UFACTORY xArm Hardware Manual (online), 3. Controller Electrical Interface · UFACTORY (manufacturer)
- UFACTORY xArm Hardware Manual (online), 4. Robotic Electrical Interface · UFACTORY (manufacturer)
- UFACTORY xArm Hardware Manual (online), 8. Technical Specifications · UFACTORY (manufacturer)
- UFACTORY xArm Hardware Manual (online), Preface · UFACTORY (manufacturer)
- UFACTORY xArm product page · UFACTORY (manufacturer)
- xArm 850 S2 Project: Open Questions for IntelliMake, Batch 01 responses · IntelliMake.org (IntelliMake)
- xArm Developer Manual V2.0.1 (PDF) · UFACTORY (manufacturer)
- xArm-Python-SDK API code description (doc/api/xarm_api_code.md) · UFACTORY (manufacturer)
- xArm-Python-SDK API documentation (doc/api/xarm_api.md) · UFACTORY (manufacturer)
- xArm-Python-SDK example 0000-template.py · UFACTORY (manufacturer)
- xArm-Python-SDK README · UFACTORY (manufacturer)
- xArm-Python-SDK source, xarm/core/config/x_config.py · UFACTORY (manufacturer)
- xarm_ros2 ReadMe (humble branch) · UFACTORY (manufacturer)
IntelliMake diagrams are redrawn as native figures, © IntelliMake.org. UFACTORY does not endorse this platform.