Integrating Synthiam Skills For Robots

You’re heading down a path that may lead to frustration. Working with proprietary hardware is incredibly challenging without knowledge of reverse engineering. Many automation manufacturers don’t want their hardware to be controlled by anything other than their own software, thereby locking customers into their ecosystem.

This is because it’s easier to copy hardware than to reproduce software. China can reproduce any hardware because, at the end of the day, they’re the manufacturers of it anyway. Or at least, they make the components.

So to protect themselves, big names in automation lock you in.

That doesn’t mean there isn’t information out there from others who have reverse-engineered your hardware.

This thread/question would benefit from including information about the products. Athena, I, or anyone can’t provide answers or direction because it’s a guessing game at this stage without knowing what products you're using. What hardware? What product model numbers? What protocols? What software is being replaced? Etc etc

I also didn’t understand the original question, so Athena took my guidance - interpreting that you wanted ARC instances to talk to each other. I’m going to remove the past comments because this has become a very confusing thread. What you’re asking is how to directly connect ARC to a proprietary robot hardware, correct? I edited the original question to make it easier to understand.

I’ll remove the questions about asking Athena to show you a communication example using Print() doesnt relate to each other. Print() is used to print out text to the console. To communicate with something other than a console, you’d use UDP, HTTP, com, uart, etc commands. But on top of that, you’d need to assemble the protocol packets for communication with those commands.

All the unknowns are

• product manufacturer
• product model number
• communication type
• software it is replacing

You might also find that their software has an api or SDK if you’re lucky! But it’s impossible to know without any information about what you’re working with.

Below is some guidance on how to approach integrating your heavyduty robots with Synthiam ARC:

1. Define the Communication Interfaces

Since your robot is built around an Arduino Leonardo with EZB Firmware, the default communication methods available in ARC are:

• USB (serial over USB):
  This is used by ARC to communicate with your EZB firmware. You can use the Serial Terminal (PC) robot skill to send and receive data or the TCP Script Server Raw if you prefer a network approach.

• Digital/Analog I/O:
  ARC controls servos and reads sensors via the digital ports (d0-d23) or ADC ports (ADC0-ADC7) on the EZB. For heavy-duty actuators or relays that handle higher power, you will likely need additional motor controllers or drivers with proper interfacing hardware.

Before you begin, consider questions such as:
What communication ports do your heavy-duty controllers offer? (USB, RS-232, RS-485, Ethernet, etc.)
What protocols are used by your proprietary hardware (if available)?
How does the manufacturer specify interfacing with their controllers?

Note: If these robots use proprietary protocols (or "closed" systems), you might need to reverse engineer the communication or make a custom robot skill. For more on creating the latter, see the Custom robot skill Tutorial.

2. Hardware Interfaces and Controllers

For a smooth integration with ARC, the following hardware components are generally required:

• EZ-B Controller or Compatible Microcontroller:
  Your Arduino Leonardo running EZB Firmware is one option. If you need more robust I/O or industrial-grade connections, you might consider using an EZ-B-compatible controller that is rated for heavier loads.

• Motor Drivers/Controllers:
  Heavy-duty robots typically require motor drivers that handle high current loads. These drivers must interface with your controller (Arduino/other microcontroller) via digital signals, PWM outputs, or even serial/ethernet commands.

• Communication Converters (if needed):
  If your heavy-duty robot controllers use another interface (e.g., RS-232 or RS-485), you might need USB-to-serial converters or dedicated interface boards. ARC’s Serial Terminal skill can then communicate via the appropriate COM port on your PC.

• Power and Signal Isolation:
  For robots carrying payloads around 50 pounds, ensuring the proper power supply, isolation of signals, and using industrial-grade connectors becomes crucial for reliability and safety.

3. Configuring ARC to Communicate with Your Robot

When integrating the hardware:

• Set Up the Connection in ARC:

  • If you’re using the USB connection (with the Arduino Leonardo), install the proper drivers and check that the COM port is configured correctly in ARC’s Serial Terminal skill.
  • For TCP/IP communication, use the TCP Script Server Raw skill. You can host a TCP server on ARC or on the Arduino (if supported via additional modules like an Ethernet or Wi-Fi shield) so that messages are exchanged directly.

• Utilize Synthiam’s Scripting Capabilities:

  • In ARC, you can create custom scripts in JavaScript or Python to send commands to your hardware. For example, using JavaScript you can print output with:

    print("Command Sent")
    

    However, for sending commands to your hardware, you will construct protocol packets and send them through the proper channels (serial, TCP, etc.).

• Develop a Custom robot skill (if required):
  If the robot’s interface isn’t fully supported by the existing skills, consider creating a custom robot skill. Use our step-by-step guide on creating custom robot skills here:
  Create a Custom Robot Skill.

4. Gathering Additional Information

Since heavy-duty and proprietary robots may have unique requirements, consider these questions:

• What are the specific product model numbers and documentation for the robot controllers?
• What communication protocols and ports do they provide?
• Is there any manufacturer API/SDK information available for interfacing?
• Are there any existing examples online of someone integrating similar hardware with third-party software like ARC?

The answers to these questions will help clarify whether you can directly interface ARC with the controllers or if you need a custom intermediary (or even reverse engineering of the protocol).

5. Next Steps

• Document Your Setup:
  Make a list of all interfaces, ports, and communication protocols available on your heavy-duty robots.
• Test Communication:
  Use the Serial Terminal or TCP Script Server skills to send simple commands to the robot’s interface and monitor the responses.
• Create Custom Logic:
  Once you have established basic communication, write custom scripts or robot skills to achieve the control you need.
• Explore ARC Tutorials:
  The DIY Robot Tutorial provides useful insights into connecting and controlling various custom robots with ARC.

In Summary

Integrating heavy-duty robots with ARC involves ensuring that your controller (Arduino Leonardo with EZB Firmware) can communicate with the robot’s actuators and sensors using a supported interface (USB/serial or TCP/IP). You’ll need to verify the communication hardware (motor drivers, interface converters, power supplies) and determine whether the proprietary system can be interfaced directly or whether customization (or reverse engineering) is necessary.

Could you provide more details on:

• The specific heavy-duty robot controllers or model numbers you’re working with?
• Which communication ports and protocols are available on that hardware?

This information will help narrow down the best integration approach using Synthiam ARC. If you have more questions or need further clarification about a particular step, feel free to ask!

Hi there again DJ, didn't realize you responded a while ago-usually it notifies me. Yes I see what you are talking about with them basically keeping their software in house. I have recently figured a way to integrate the two with the use of switches 5 switches produces 32 inputs after I write the code on their robot to analyze the switches. It's not as good as really communicating through typical means but it's a start. I did receive some feedback from your staff but it never continued on. I did recently receive another patent for flood proofing structures. It may change some people's lives. Will keep working your ARC with the real robot. So far I've been able to weld, plasma cut, wood route, drill in steel, cut with circular saw stair stringers and many many other things.  It's going to be cool to ask it to pick up bin 15 and drop off at bin 3--- with voice recognition and mm precision.

Great progress - nice work getting physical I/O working as a fallback. That’s a pragmatic and often reliable way to start when a direct protocol/API isn’t available. Below I’ll give practical next steps, safety notes, and an example of how to wire that 5-switch scheme into ARC so you can map "bin 15 bin 3" style commands, plus suggestions to increase precision and reliability as you move forward.

Key questions (so I can tailor next advice)

• Where are the 5 switches physically wired? To your Arduino Leonardo (EZB firmware) digital pins, or to the proprietary robot controller?
• Does the heavy robot accept any external commands (UART, TCP, Ethernet, CAN, Modbus, etc.) at all, or is your only output the switch-state method?
• How is motion currently controlled (PWM motor drivers, CAN motor drivers, dedicated motion controller)? Do you have encoders/absolute position sensors on the axes?
• What voltages are the switch outputs (3.3V, 5V, 24V)? (Important for isolation/level shifting).

Immediate ARC integration using 5-switch (5-bit) input If your Arduino Leonardo (with EZB firmware) can read the 5 switches on digital pins d0..d4, you can poll them in an ARC script, decode the 5-bit number (0-31) and map that to actions (move to bin X, pick, place, etc.). Below are the important points and a JavaScript example to get you started.

Hardware notes

• Ensure proper voltage compatibility. If the robot’s switch outputs are >5V (typical industrial 24V), use opto-isolators or level shifters before connecting to d0..d23.
• Debounce switches in hardware (RC) or in software to avoid spurious state changes.
• Add safety interlocks and an E-stop wired independently of any script or network command (hardware stop).
• Consider galvanic isolation between heavy-power motor controller circuits and your logic controller.

ARC workflow (high-level)

1. Add or confirm the Arduino Leonardo EZB is connected in ARC (Project Add robot skill if needed).
2. Use a robot skill (or a dedicated script) to poll the 5 digital inputs.
3. Map the decoded value to named commands (e.g., bin 0..31 or special codes for pick/place).
4. Execute robot movements via Movement Panel robot skill, servo commands, or ControlCommand() to other robot skills that handle low-level motion.
5. Log and optionally voice announce actions via Audio.say or Audio.sayEZBWait for confirmation.

JavaScript example (poll switches d0..d4, decode, map to action)

// Poll 5 switches on d0..d4 and return an integer 0-31
function readSwitchValue() {
  var value = 0;
  if (Digital.get(d0)) value |= 1;    // bit 0
  if (Digital.get(d1)) value |= 2;    // bit 1
  if (Digital.get(d2)) value |= 4;    // bit 2
  if (Digital.get(d3)) value |= 8;    // bit 3
  if (Digital.get(d4)) value |= 16;   // bit 4
  return value;
}

setVar("$LastSwitchValue", "-1");

while(true) {
  var v = readSwitchValue();
  if (v !== getVar("$LastSwitchValue")) {
    setVar("$LastSwitchValue", v.toString());
    print("Switch value: " + v);

    // example mapping: 0 = idle, 1..31 = bin numbers
    if (v === 0) {
      print("No bin selected.");
    } else {
      // Call your movement routine here. Example using a custom skill:
      // controlCommand("MyArmSkill","GoToBin","" + v);
      // Or perform direct movement calls if movement skill supports it:
      // Movement.stop(); Movement.forward(200, 1000);
      print("Command: go to bin " + v);
      // setVar to share target with other scripts/skills
      setVar("$TargetBin", "" + v);
    }
  }
  sleep(200); // check every 200 ms (ARC sleep uses ms)
}

Notes about the sample:

• Digital.get(d0) etc. uses the ARC constant d0 (no quotes).
• change ControlCommand or Movement calls to match your actual robot skill names and commands.
• Use setVar("$VariableName","value") to share state between scripts/skills.

Options if the switches are on the proprietary robot controller

• If the proprietary controller can drive a set of digital outputs (voltage-level compatible), you can wire those outputs to an Arduino/EZB digital input and let ARC read them as above.
• If the controller only has internal switches and you cannot expose them electrically, have the controller send the decoded value via a serial or TCP message (if it supports it). ARC can receive via Serial Terminal (PC) skill or TCP Script Server Raw skill. See:
  • Serial Terminal (PC): https://synthiam.com/Support/Skills/Communication/Serial-Terminal?id=16071
  • TCP Script Server Raw: https://synthiam.com/Support/Skills/Communication/TCP-Script-Server-Raw?id=15953

Improving reliability & precision (moving beyond switches)

• Encoders / Absolute encoders: For mm-level repeatability you’ll need encoders (incremental or absolute) on the axes. ARC can read encoder counts via custom firmware or via an EZB that exposes counts (or via a custom robot skill).
• Closed-loop microcontroller: Put low-latency control (PID loops) on the microcontroller/EZB firmware or on a dedicated MCU-ARC is great for high-level commands and UI, but very tight motion loops should run on an MCU.
• Vision / fiducials: Add camera + AprilTags or fiducial markers for automatic bin localization and mm/pixel calibration if the bin positions aren’t perfectly repeatable.
• Communication upgrade: If you can eventually expose a UART/TCP/CAN interface from the robot, switch to a command/response protocol. That’s much richer than binary switch states.

How to create a robot skill / hook custom mapping

• Create a robot skill: Project Add Robot Skill.
• Open the skill’s kebab menu (three lines top-right) to find Settings, Startup Script, and other options. Use the Settings to configure COM port, TCP, or behavior as needed. More: https://synthiam.com/Support/Create-Robot-Skill/Overview
• Put the JavaScript sample into a skill’s Script area or create a dedicated "BinMapper" skill that publishes $TargetBin for other motion skills to act on.

Safety suggestions

• Add a hardwired E-stop that cuts motor power independent of ARC or any scripts.
• Use watchdog timers or a heartbeat signal between ARC and the robot motor controller so motors disable if comms fail.
• Log operations with timestamps to trace any unexpected motion.

Next steps I can help with

• If you can share the switch wiring details (which ports on the Arduino/EZB or robot), I’ll tailor the code to those pin numbers and suggest any required pull-ups or input config.
• If you can tell me how the heavy robot is commanded today (what driver/protocol controls motion), I can suggest the best transition path (switch inputs serial TCP full API).
• I can provide a sample ControlCommand mapping between a BinMapper skill and a movement skill (if you tell me the movement skill name and commands you want it to accept).

This is a solid start - once you get repeatable state detection from the switches, we can extend to closed-loop position or vision-based precision so the robot can reliably pick bin 15 and place to bin 3 with mm precision. Want me to prepare a ControlCommand example that calls a Movement/Arm skill for a 3-step pick/place routine?

@Athena The model of robot is a Borunte  BRTIRUS1820A and has the ability to use Modbus TCP. You may be able to look into the Borunte brand and see other types of communications that may be better suited for it. Does ARC have the ability to communicate with it?

Short answer: Yes - ARC can work with a Borunte BRTIRUS1820A that supports Modbus TCP. You have two practical, reliable integration approaches depending on how much you want ARC to speak Modbus directly vs. using a small "gateway" program or microcontroller.

Below I’ll outline the options, show a recommended approach (HTTP-to-Modbus gateway using Python) with code you can run on the same PC as ARC, explain how to call it from ARC, and list next steps and safety notes.

1. Two main approaches

• Direct in-ARC (if a Modbus robot skill/plugin exists)

  • Search the robot skill Store (Project Add robot skill search "Modbus" or "Modbus TCP") and add/configure it if available.
  • Use the skill’s kebab menu (three lines, top-right) to configure connection, registers, and startup script.
  • If a published Modbus TCP skill exists, this is the simplest path.

• Recommended: Small gateway service (HTTP or TCP) + Modbus client

  • Run a lightweight Python service (or Node) on the same PC (or any PC on the same network) that speaks Modbus TCP to the Borunte robot and exposes a simple HTTP API.
  • Call the HTTP API from ARC using Net.hTTPGet / Net.hTTPPost, or call it from ARC scripts (JavaScript/Python) - very flexible and easy to debug.
  • Advantages: no need to depend on an ARC socket plugin, you can reuse standard Modbus libraries (pymodbus), add safety checks, logging, and translate complex register maps into simple endpoints (e.g., /goto_bin/15).

2. Why I recommend the HTTP gateway

• ARC has built-in Net.hTTPGet / Net.hTTPPost functions you can call directly from scripts (so no custom ARC plugin needed).
• Modbus is messy to hand-construct frames for production use; pymodbus handles the protocol cleanly.
• Easier to iterate and debug (use curl or browser to test endpoints).
• Keeps ARC focused on UI/high-level logic and the gateway focused on low-level real-time-safe commands and safety interlocks.

3. Example: Python Flask + pymodbus gateway

• Requirements: Python 3, pip install flask pymodbus
• This example shows a couple endpoints: read a register and write a coil to command the robot. You will adapt register addresses/function codes to the Borunte register map.

Python gateway (example)

# Save as modbus_gateway.py
from flask import Flask, jsonify
from pymodbus.client.sync import ModbusTcpClient
import logging

logging.basicConfig(level=logging.INFO)
app = Flask(__name__)

# Configure your Borunte robot IP/port/unit id
BORUNTE_IP = "192.168.1.100"   # change to your robot's IP
BORUNTE_PORT = 502
UNIT_ID = 1

def modbus_client():
    c = ModbusTcpClient(BORUNTE_IP, port=BORUNTE_PORT)
    if not c.connect():
        app.logger.error("Cannot connect to Borunte Modbus server")
        return None
    return c

@app.route("/read_holding/<int:address>/<int:count>", methods=["GET"])
def read_holding(address, count):
    c = modbus_client()
    if c is None:
        return jsonify({"error": "connect_fail"}), 500
    rr = c.read_holding_registers(address, count, unit=UNIT_ID)
    c.close()
    if rr.isError():
        return jsonify({"error":"modbus_error"}), 500
    return jsonify({"registers": rr.registers})

@app.route("/write_coil/<int:address>/<int:value>", methods=["POST","GET"])
def write_coil(address, value):
    c = modbus_client()
    if c is None:
        return jsonify({"error": "connect_fail"}), 500
    val = True if value else False
    rq = c.write_coil(address, val, unit=UNIT_ID)
    c.close()
    if rq.isError():
        return jsonify({"error":"modbus_error"}), 500
    return jsonify({"ok": True})

# Example high-level endpoint: goto bin
# Implement according to Borunte's control registers:
@app.route("/goto_bin/<int:bin_id>", methods=["POST","GET"])
def goto_bin(bin_id):
    # Example: suppose register 40001 is the target bin register; adapt to your robot
    TARGET_REG = 0    # replace with correct register address
    c = modbus_client()
    if c is None:
        return jsonify({"error": "connect_fail"}), 500
    rq = c.write_register(TARGET_REG, bin_id, unit=UNIT_ID)
    c.close()
    if rq.isError():
        return jsonify({"error":"modbus_error"}), 500
    return jsonify({"ok": True, "target": bin_id})

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

• How to use:
  • Edit BORUNTE_IP, BORUNTE_PORT (usually 502) and UNIT_ID, and adapt addresses to Borunte register map.
  • Run: python modbus_gateway.py
  • Test: http://127.0.0.1:5000/goto_bin/15 in a browser or curl.

4. How to call this from ARC

• From an ARC script (JavaScript), call the gateway with Net.hTTPGet:

// Example ARC JavaScript
var url = "http://127.0.0.1:5000/goto_bin/15";;
var resp = Net.hTTPGet(url, 5000); // 5000 ms timeout
print("response: " + resp);

• Or use Net.hTTPPost if you want POST semantics.

5. If you prefer a pure-ARC route

• Search the robot skill Store for a Modbus/Industrial I/O skill: Project Add robot skill search "Modbus" or "Industrial".
• If found, add it and configure the IP/port/unit ID in the skill settings (use the kebab menu - three lines top-right - to find options).
• If no skill exists for your exact needs, create a custom robot skill (tutorial: https://synthiam.com/Support/Create-Robot-Skill/Overview). That skill can host a direct Modbus client using .NET libraries (more work but fully native).

6. Hardware / network notes & safety

• Modbus TCP default port is 502 - verify IP + port of your Borunte robot.
• Get Borunte’s Modbus register map / function list - you must know what holding registers/coils control motion, speed, enable, E-stop, etc.
• Test with read-only queries first (e.g., read registers that report position/status).
• Never rely solely on software for E-stop; ensure a hardwired, independent E-stop that cuts power to actuators.
• Use logging, timeouts, and safety checks in the gateway (e.g., interlock checks before a write).
• If robot controller expects specific sequences or safe mode unlocking, follow the vendor sequence exactly.

7. Next steps / what I need from you To give concrete code you can run against your Borunte robot, please provide:

• Borunte IP address and Modbus port (or confirm default 502).
• Borunte Modbus unit/slave ID (if known).
• The register map or at least which registers/coils control:
  • Move command (address, type)
  • Target bin or trajectory register
  • Status/position registers (where to read current position)
  • Any enable/unlock or safety registers
• Whether the Borunte requires special sequences (e.g., unlock then write then start).
• Do you want ARC to send simple commands (goto bin #) or low-level position control (write absolute coordinates, velocities, etc.)?

8. Useful links and tools

• Create robot skill tutorial (how to make a custom skill): https://synthiam.com/Support/Create-Robot-Skill/Overview
• Robot Skill Store (search for Modbus skill): https://synthiam.com/Products/Controls
• Serial Terminal skill (if you need serial gateways): https://synthiam.com/Support/Skills/Communication/Serial-Terminal?id=16071
• TCP Script Server Raw skill (for other network integrations): https://synthiam.com/Support/Skills/Communication/TCP-Script-Server-Raw?id=15953
• ARC Downloads and docs: https://synthiam.com/Products/ARC

Would you like:

• A ready-to-run Flask+pymodbus script customized for the Borunte registers (I can prepare it if you paste or attach the Borunte Modbus register map), or
• Help searching the robot skill Store for a ready-made Modbus TCP skill and step-by-step setup inside ARC?

Tell me the register map or just the key registers (target bin register, start command coil/register, status register) and I’ll prepare a tailored gateway + the exact ARC script to control it.