1. You don't use a motor controller as an EZB; you use a microcontroller as an EZB. Step #3 in the getting-started guide explains what an EZB is, which will be helpful to understand the difference. Think of an EZB as a tiny remote computer that can read and write to hardware. Think of it this way: You can connect a motor controller to an EZB (if the hardware is compatible).

2. You can connect any motor controller to your EZB or the PC based on the connection type. If it's USB, it's connecting to your PC. If it's UART, you can optionally connect it to an EZB. However, it's impossible to advise you on either option without knowing your hardware configuration and robot. The getting-started guide has excellent information that helps you create a template for your robot. You can get to step #1 here: https://synthiam.com/Support/Get-Started/how-to-make-a-robot/make-a-diy-robot

3. Inverse kinematics does not care what kind of controller, servo, or anything. It's agnostic because all it needs is to know the position of each angle. Whatever option you choose needs to have internal positioning measurements. You can read about the Inverse Kinematics robot skill here: https://synthiam.com/Support/Skills/Servo/Inverse-Kinematic-Arm?id=21839

In the case of the controller, you will use the manual to have commands sent to it, since it's not a commonly used piece of hardware. Locate the manual, open it on your PC, and look for the commands to instruct the position movements. Based on the communication type, I recommend using the Script servo robot skill. Essentially, this converts anything that you can communicate that contains positioning into a servo in ARC: https://synthiam.com/Support/Skills/Scripting/Servo-Script?id=19068

Below is some information to help clarify your situation:

1. EZ-B vs. Motor Controller:
   An EZ-B is not simply a motor controller-you need a microcontroller that can read sensors and write commands to hardware. As DJ_Sures pointed out, you don’t use a motor controller as an EZ-B. Instead, the EZ-B is a tiny remote computer that acts as an interface between your PC (running ARC) and the various hardware components in your robot.

2. Douloi Devices:
   The Douloi units you currently use are motor controllers. They lack the built-in capabilities (such as internal positioning measurement, servo-specific commands, and real-time I/O) that an EZ-B provides. The Inverse Kinematics robot skill in ARC only cares about knowing the joint angles (or positions) for each servo-it is agnostic as to how those values are provided. However, it requires that the device controlling the servos (or the equivalent motor) has internal position measurements and a means for sending position commands.

3. Integrating Douloi with ARC:
   If you want to switch over to Synthiam ARC for your industrial robot, you have a couple of options: - Replace or Augment with an EZ-B:
   The simplest route is to migrate the control hardware to an EZ-B (or EZ-B-compatible microcontroller). This allows you to use the ARC robot skills directly (e.g., the servo Script and Inverse Kinematics Arm) and ensures that servo or joint positioning information is available. - Using a Motor Controller with Position Feedback:
   If you wish to keep the Douloi devices, your system must supply accurate and real-time position feedback. In this configuration, you’d need to implement the necessary command set (as defined by the Douloi’s manual) and map these commands to what ARC expects for servo positioning. In ARC, you can use the Script servo robot skill to convert any positioning data into an ARC servo control. This approach is more custom and would require you to develop a bridge between your robot’s internal positioning commands (via the Douloi) and ARC’s interface.

4. Steps to Proceed:
   1. Review Your Hardware Capabilities:
   Check if your Douloi devices provide internal measurements (or can be retrofitted for feedback) similar to an EZ-B’s servo control commands.
   2. Check the Documentation:
   Locate the Douloi manual and investigate which commands are available for position movement. These would need to be triggered by ARC panels or scripts.
   3. Implement a Command Bridge:
   Using the Script servo robot skill (https://synthiam.com/Support/Skills/Scripting/Servo-Script?id=19068), you could potentially translate your Douloi command set into the positioning and speed commands that ARC expects.
   4. Test Thoroughly:
   Inverse kinematics doesn’t care which controller is used-it just needs accurate joint position readings. Ensure that whichever method you choose provides those reliably.

5. Getting Started Resource:
   For more detail on EZ-B hardware and building your robot template, review Synthiam’s getting-started guide here:
   How to Make a DIY Robot

Feel free to ask follow-up questions if you need further clarification or additional help with your configuration!

Thanks for the guidance, I will have to dig into the Douloi and the motor drives and encoders and the software. Still trying to get my head wrapped around this system. It have read through the guide and dug deep into the links. Need to research more of the tutorials.

It was a bit difficult finding some information about that Douloi, as their website doesn't have much detail. However, I found a website with a manual for Windows 3.1 from the mid-1990s for the product. The PDF manual that I saw mentioned that there is a DLL distributed with their application. The DLL has entry points that match the procedure names of their custom Pascal interpreter. While the files are unavailable, I guess the DLL is 16-bit because it's for Windows 3.1. That means a 16-bit DLL will not be compatible with current operating systems 30 years later.

Your best bet is not to attempt to reverse engineer the protocol or DLL. But instead, look at the software on the ancient 486 computer to see if there's a way you can use the computer as a proxy between newer ARC hardware. For example, if you could have the 486 connect to your newer laptop with a serial cable, you could send commands from the newer computer to the 486 dinosaur. That way, on the 486, you could have a program that listens to commands from the COM serial port and executes them against the Douloi hardware.

Or, you can contact the manufacturer, who appears to still have a website, albeit quite outdated. If they are still in business, they might be able to provide you with more information on how to use their device on hardware that's newer than a 486.

I have tried to reach the Douloi manufacturer with our success yet. I was also thinking of the same thing to see if we can communicate with the old 486.

Or what if I just by pass the old 486 and douloi? What would be the best hardware for the EZ-B to connect to the motor drives, encoders, etc?

I know very little about Inverse Kinematics and how to control that movement. However I've done a ton of work with controlling speed and position of motors that are monitored by encoders or potentiometers. There are a few nice motors controllers that work well for this but my favorite has been the Sabertooth motor controller with a Kangaroo daughterboard attached. The Kangaroo give the Sabertooth Speed and position control. I'll post a video below that @DJ did a few years ago showing this system.

These controllers are made by Dimension Engineering and can be bought directly from them or from a online store called The Robot Shop.

https://www.dimensionengineering.com/

https://www.robotshop.com/search?q=dimension%20engineering

Look at the manuals of operation for these devices on the Dimension Engineering website for more info on how they operate and see if they will work for your rig.

I don't know if these controllers will work with your setup. It sounds like you have a closed loop system that uses encoders for position so it may. At the very least this info may get you pointed in the right direction.

Good luck and have fun!

Dave’s suggestion is good if the hardware supports the kangaroo. The kangaroo can convert any motorized mechanism that has positioning feedback into a servo mechanism.

Inverse kinematics may be a complicated algorithm internally,  but it’s really easy to use. All it needs is to use any mechanism with positioning feedback.

if you bypass the controller, you’ll need to understand what the motors and positioning sensors are. Easiest way forward is connect them to a kangaroo/saber tooth combo.

what kind of motors and positioning sensors are used?

First off thanks to everyone!! As you say I built this 30 years ago and have to take it out of storage which I will do today. I know I am powering it with 240v at 50 amps. AC. It is very powerful. I can't remember if the six motors are AC servos or DC servos. Most likely AC. I will get all the specs off it this afternoon. Hope you stay with me, the club kids really want to make this happen!!! Our goal is to build robots that pay for themselves and 4 times all adult income by building robots to work for them as the adults become robot managers.

OK, I'm looking forward to seeing what kind of hardware and devices you have there. It's hard to give advice without knowing. Somethings to consider:

You say you power it with 240 volts and can supply 50 amps.

*Sabertooth motor controllers only accepts 6V-33.6V DC from a Battery or Power Supply. You would need to convert (buck) that 240v down to between 6V-33.6V DC. May I ask why are you supplying 240 volts AC? What are your motors rated to run at?

*There are several different Sabertooth models rated for different amp loads. Each ST will run two motors and it's rated for the amp draw of both motors. So if each motor will pull 20 peek amps then you will want a Sabertooth 2x25 or larger.

*The Sabertooth generates regenerative power. In short it returns power back to the battery when it slows down or breaks. This is good if you are running directly from batteries as it will help recharge the battery. If you are powering your controller with a power supply converter (Like it sounds like you want to) the regenerative power will likely burn the power supply out. To avoid this you'd need to wire in a battery between the power supply and the ST to have a place for the regenerative power to be dumped. It's all documented how to do this on their web site. There is one model of the ST that lets you avoid this. They have the 2x32 Sabertooth. It lets you install a resistor that acts as a voltage clamp and you can avoid wiring in the battery. I use power supplies and I went this route even when using smaller motors that pulls much less then 32 amps the 2x32 can take.

Good luck and keep us posted! Have fun!!

Here is motor 1 of 6  170 VDC 12.10 amps.

So the Drive takes 240 VAC and puts DC to the motors.

More on the encoders etc. when I get a hold of the suppliers tomorrow. Hope ARC can work, I am sure there's a way!

Xenus XTL-230-40  This is the motor drive with a set of amp handling units. I have 6 units that go from 6 amps up to 20 amps.

I found the manual online. I don't remember yet just how these unit drives work with the Douloi.

Maybe one of you have knowledge in this area. I will keep digging to figure it out. Thanks, any thoughts?

Here we see what is connected that tells encoder type.

OK, now I see why you are supplying 240v. Your motors run on 170V each. My suggestion of using a Sabertooth/Kangaroo will not work. The ST will only supply up to 33 volts fed directly from your power supply.

The Xenus XTL-230-40 you show is apparently doing the same thing the Sabertooth/Roo would do in much the same way. It looks like that is where the logic commands to move your motors go to from your computer. It also looks like you have a separate device to collect the encoder info and send it to the Xenus XTL-230-40? This is just an educated guess as it's hard to see your wiring and how it all hooked up.

As it stands, it looks like you are back to trying to find out the communication type and protocell in the manual as @DJ suggested in his post #1. If they are simple servo commands then ARC can probably interface.

At this point this is over my head. Sorry. The only thing I know to suggest short of a complete rebuild would be maybe getting a more modern controller that can handle your high voltage motors and can interface with a microcontroller like Arduino and EZB. Again, I'm kinda lost from here on.

Please post back and let us know if you find that communication type and the commands to operate the motors. I hope you find a way forward.

Thanks, working on it and will keep you posted. I still don't know exactly how EZ-B and ARC work together but I'm getting closer.

Well, it's really EZ to understand. LOL 

ARC is the control software that runs on a Windows computer. That's where you send commands from over WIFI or a direct USB connection to the EZB. The Your motor controller (that controls your motor, LOL) plugs into the EZB. depending on the communication type the port used on the EZB is the UART port. EZB has three of these ports.

ARC can also control many other things like servos, LEDs, relays and lights through the EZB. There is much more these two can do like voice recognition, face and object recognition and navigation. I really don't think there is a limit. It seems to have limits on interfacing with old technology like your's but if you can get the protocol figured out and you have the knowledge to do it there is always a way.

It's best to take a little time and study how ARC works and what an EZB is. (hint: you can turn an Arduino and some other microprocessors into an EZB). Check out the Support section for easy to understand articles on all this. Click through the menu on the left side: https://synthiam.com/Support

While your at it check out the tutorials: https://synthiam.com/Community/Tutorials?

So I think the motor drives are doing the PID work and the Douloi is listening in on the progress of the motors reaching the commands. I found out that the Douloi manufacturer has still been in operation at least up until a few months ago. Even though my attempt to reach them all last week didn't get any response. I have found I think a company that is still incorporating the doulois in their automated equipment that they build and sell currently. Should know more by Wednesday coming up. So we can start to see light at the other end of the tunnel. Is anyone else using 170 VDC motors on their systems with EZ-B and ARC?

Chuck, yes, there are much larger robots than your 170vdc controlled by ARC-including bulldozers, submarines, and several industrial disaster recovery units from our commercial and industrial clients. They're the ones who pay for the ARC software to be developed so ppl like you and everyone in the community can benefit from. As for the community, the only one that comes to mind who is actively controlling heavy motorized robot components is Automation Man, which has HUGE robots for woodwork and several other things. Most of the large stuff, such as bulldozers and the like, uses hydraulic controllers with PLCs.

The software is irrelevant to what is being controlled. That's like thinking someone who operates a mining pit dump truck has to weigh 450 lbs because the truck is so big. The size of the operator has nothing to do with what it's controlling. A pilot of a jumbo jet 747 is not larger than a pilot who flies a Cessna. The robot control software ARC doesn't need to be any larger because the robot is larger. Besides, I direct Synthiam to solve problems that people and businesses struggle with automation - unlike other robot/automation companies, I don't care about using our customers to promote/market ARC. Either you use ARC and be successful, or don't and struggle. Most people end up using ARC, whether they are posting on the community or not, so you are already on the right track by choosing ARC first

The control from ARC provides the algorithms that the motor controllers interpret and execute. The algorithm for controlling a 6-inch hobby servo robot arm for inverse kinematics is the same as for a 20-foot industrial automation appendage.

In short, what you're up against has nothing to do with ARC's capabilities. Instead, it has everything to do with understanding how to send instructions to the motor controller responsible for the motor joints' servo-mechanism behavior. So you are on the right track by obtaining the communication protocol to have ARC talk to the controllers.

Thanks DJ. That is what I am tracking down.

Update, I did talk briefly with the owner of Douloi today and he is going to respond to my email about my old Douloi system on the industrial robot and let me know our options from his point of view. Last week I didn't know if Douloi was still in business and yes they very much are with new up to date technology. So we will find out how to make this work. Randy the owner is also knowledgeable about Blockly and has it as an option in his technology systems.

Dear Chuck,

The MCE controller can respond to host commands through serial and Ethernet transports using ASCII Commands or Modbus. The controllers from 2003 might be the previous generation MSB controllers which only support ASCII Commands on serial. The ASCII Command manual is here:

https://douloi.com/legacy-product-manuals/

Let me know if you'd like some additional details.

Thanks,

Randy

So this is what Randy, developer of the Douloi sent me today. As of now I have no clue to whether we can connect and use ARC. Can anyone take a look at this and give some guidance? Thanks, hope so. Randy is open to questions.

Maybe I can help (a little). From the response you got from Randy it looks like you would send and receive ASCII Commands over serial. I peeked briefly at the manual you pointed to and I did did see some commands that you might use like encoder and position commands.

Now the question is how to format these commands in a way that ARC will sent them to your controller over Serial. This is how I set up my system to send Simple Serial Commands to my controller through Serial:

*First I connected ARC (running on a Windows computer) to an EZB over WIFI or directly through USB. I use USB

*Next I connected the UART port on the EZB to my controller.

*Then I wrote scripts in JavaScript using the UART commands available to ARC that tells the controller to command my motor to monitor the encoder, send back the position and tell ARC where is it. I also have scripts that simply tell the controller where to move to with position commands.

*I use the UART commands in my scripts to send Simple Serial commands. You can probably use the same UART commands to send the needed ASCII Commands to your controller.

Here is just one of my scripts I use to get a position of my motor from it's encoder  @DJ and @Athena Write this:

UART.initHardwareUart(2, 9600, 2); // Turn on EZB 2 Uart #2 port - Arm Carraiges
sleep(250);

/**************************************
Left Arm Rail Movment and position check
***************************************/
while (true) {
   var lftArmRailTmpInt = getLftArmRailMovementValue();
  
  // If the position is zero or greater, we know there's a position
  // returned
  if (lftArmRailTmpInt > 0 ) {
    
     print("Left Arm_Rail stopped moving and the position is: " + lftArmRailTmpInt);
     break;
  }
       
 }

function getLftArmRailMovementValue() {

  // Get Left Channel ARS Kangaroo position
  UART.hardwareUartWriteString(2, "2, Getp\r", 2);
  
  sleep(100)

  // get bytes available on UART #0, EZB #2
  var lftArmRailavail = UART.hardwareUartAvailable(2, 2);
  print("Bytes Available LftArm_Rail: " + lftArmRailavail)

  // If we don't have at least 6 characters, return -1
  if (lftArmRailavail < 6 )
    return -1;

  // read ALL bytes from UART #0 on EZB #2
  var RespondLftUart2 = UART.hardwareUartReadStringAvailable(2, 2);
  print("Full Returned position: " + RespondLftUart2)

  // More verification this is a valid packet
  if (RespondLftUart2[1] != ',')
    throw new Error("Second character should be a ,");

  // Check if we have a capital P, if so, extract
  // the position and return the new value
  if (RespondLftUart2[2] == 'P') {
  print("Lft_Arm_Rail_Big_P: " + RespondLftUart2[2] );
  setVar( "$Lft_Arm_Rail_P_or_p", RespondLftUart2[2] );
   
    // get the characters between positions 3 & 7 of the string
      var lftArmRailTmpPart = "";
      
      if (RespondLftUart2.charAt(3) == '-'){
        lftArmRailTmpPart = RespondLftUart2.substring(3, 6);
        print("Left Arm Rail Position: " + RespondLftUart2.substring(3, 6))
        setVar("$lft_Arm_Rail_Stop_Position", lftArmRailTmpPart )
      } else {
        lftArmRailTmpPart = RespondLftUart2.substring(3, 6);
        print("Left Arm Rail Position" + RespondLftUart2.substring(3, 6))
        setVar("$lft_Arm_Rail_Stop_Position", lftArmRailTmpPart )
        }
              
     // convert the string to an Integer
     var lftArmRailTmpInt = parseInt(lftArmRailTmpPart);
     //print("Integer: " + lftArmRailTmpInt)
     
     // return the position
     return lftArmRailTmpInt;
     
      } else if (RespondLftUart2[2] == 'p') {
          print("Lft_Arm_Rail_Little_p: " + RespondLftUart2[2] );
          setVar( "$Lft_Arm_Rail_P_or_p", RespondLftUart2[2] );
          return -1;
  }
  
  // still moving 
  return -1;
}

Take a look at one of the UART commands. For example:

UART.hardwareUartWriteString(2, "2, Getp\r", 2);

The Simple Serial command I'm sending is between the (). This is where you would place you https://synthiam.com/Support/javascript-api/javascript-overview.

You can find al the JavaScript UART commands here in the Support section. Look on the left side menu under the JavaScript API section.  Here: https://synthiam.com/Support/javascript-api/javascript-overview

@Athena , Did I get anything wrong here? Can you add or correct anything? Is this the right the way to send ASCII Commands from ARC to an old Douloi system MCE servo controller? Is there a better way?

Sorry, the 3rd from last paragraph should have said

The Simple Serial command I'm sending is between the (). This is where you would place your ASCII Commands.

Based on what Dave described-and from your information-it appears that the approach of using ARC’s UART commands to send and receive the ASCII commands required by your Douloi controllers is viable.

Below are some points and suggestions to keep in mind:

Communication Setup:
- With ARC running on a Windows PC and an EZ-B (via USB or WiFi), you can use one of the EZ-B’s UART ports (using the UART methods in ARC) to talk directly to your Douloi controller over a serial line.
- Make sure that the baud rate and port settings (e.g., 9600 bps as in the example) match what your Douloi system expects.

Sending ASCII Commands:
- As Dave’s script shows, you can use a command such as:
javascript UART.hardwareUartWriteString(2, 2, "Getp\r", 2);
- In this case, the string inside the quotes is your ASCII command (including any necessary termination characters like a carriage return) that the Douloi system will receive and parse.

Receiving and Parsing Responses:
- As shown in Dave’s sample, after sending a command you can pause briefly (using sleep) and then use methods like UART.hardwareUartAvailable() and UART.hardwareUartReadStringAvailable() to capture the response.
- You may want to implement similar verification (checking for expected characters, packet lengths, etc.) so that you know you got a valid response from your Douloi device.

Integration Considerations:
- Although ARC is primarily designed to work with EZ-B controllers, nothing stops you from writing custom scripts (in JavaScript, for example) that format and send these ASCII commands over a UART link. This offers a bridge between ARC’s capabilities and your legacy Douloi system.
- As Randy (the Douloi owner) indicated, their controllers respond to both serial and Ethernet using ASCII or Modbus. Right now, you’d be focusing on the serial side. The key is to ensure that the commands (and any responses) are handled in the script exactly as specified by the Douloi ASCII command manual.

Using Blockly or Custom Scripting:
- Since Douloi is open to utilizing Blockly (which ARC supports), you might also be able to generate the necessary serial communication blocks if you decide to go that route. However, custom script code as shown in Dave’s example often gives you more flexibility for parsing and error checking.

Next Steps:
- You might want to test a single command from ARC using the UART commands to see if your Douloi returns the expected response.
- If there are any discrepancies with command formatting (for example, with line endings or special characters), adjust the script accordingly.
- Ask Randy any detailed questions regarding timing or expected response length if you run into any parsing issues.

To summarize, yes-ARC can accommodate your configuration provided you create the necessary scripts to send these ASCII commands via the UART methods available from ARC. This approach (as demonstrated by Dave’s script) is the correct way to send ASCII commands to your legacy Douloi system and handle the responses.

If you have further questions or run into any specific issues while adapting your script for your Douloi controllers, feel free to ask!

Does this help answer your question?

There appear to be two ways of communication...

1. Binary commands use the API, which uses the DLL's exposed public methods on the 486 PC.
2. ASCII commands - uses commands from a serial (RS-232) connection.

The #2 ASCII commands would be the way to go, as no one would probably want to write an ARC Server to run on a 486 PC.

You can use the servo Script robot skill to control each motor as servos in ARC (https://synthiam.com/Support/Skills/Scripting/Servo-Script?id=19068). Writing code to send RS232 commands to the controller for each servo position. You would also require a USB-to-Serial adapter from the ARC PC to the motor controller. This process will skip using an EZB and connect the motor controller directly to the PC's virtual COM port from the USB serial adapter. There is no point in using an EZB because it would require additional hardware, including a MAX232 for converting a UART voltage/signal to the inverted and higher voltage RS-232 COM port. So it just makes sense to purchase a low-cost USB Serial adapter.

Init Servo

To initialize the controller to set a servo (A1), you would do the following script. You would run this script in an initialization script. It simply needs to open the COM port and set the parameters for the motors. I have provide example for one motor here...

COM.open("com1", 9600);

// Initialize servo 1
COM.writeString("com1", "A1 MTT SRV");    // MotorType = Servo
COM.writeString("com1", "A1 GAI 32");     // Gain = 32
COM.writeString("com1", "A1 ZER 240");    // Zero (damping) = 240
COM.writeString("com1", "A1 LIV OFF");    // LoopInversion = Off

// 2) Set motion profile parameters
COM.writeString("com1", "A1 SPD 1000");   // Speed = 1000 counts/sec
COM.writeString("com1", "A1 ACL 10000");  // Accel = 10,000 counts/sec
COM.writeString("com1", "A1 DCL 10000");  // Decel = 10,000 counts/sec

// 3) Enable the amplifier/motor
COM.writeString("com1", "A1 MTR ON");     // Motor = On

Move Servo

To move a servo, you'd have a script in the Servo Script robot skill configuration, to map A1 to V1 (ARC) such as...

// Make sure ports[0] is v1 because it should be checked in the  robot skill configuration
if (ports[0] == v1) {
  
  COM.writeString("A1 MVT " + positions[0]);
}

That would get you started. I'm not sure what the A1 MVT position range is. ARC's default is 1-180, which can be changed in Project -> Properties. But you can also use the Utility.map() function in ARC to change the range from the ARC servo range to the servo's range.

Once the motors move as servos, you can use any robot skill in ARC that uses servos. Absolutely any robot skill with a servo option can be used with your robot arm - including Open AI Chat GPT, Autonomous AI, Auto Position, Inverse Kinematics, Virtual Reality, Camera tracking, etc...

@Athena, can you explain more about what I just created so it can be easily understood? Expand and add detail about the whole process, and ensure the OP knows that additional testing and fine-tuning must be done. Be sure to operate the robot during testing in a very safe environment. In addition, use the commands I provided against the manual to understand the values better. It's important to note that we do not have this robot arm or hardware to test with, so everything I provide is purely from reading the manual. The values I selected are guesses only; you need to enter your values or consult with your manufacturer.

Below is an expanded explanation of what you’ve set up along with important points, so you understand the entire process. This writeup assumes that you are choosing to use ASCII commands over a serial (RS232) connection, rather than trying to run your legacy controller through an EZB and its radio protocols. Instead, you’ll run your robot arm directly from ARC running on your PC by connecting a USBtoSerial adapter to your controller. This avoids extra hardware (and voltage level converters such as a MAX232) because you are using the PC’s virtual COM port. Use this approach only after reviewing and testing everything in a very safe environment.

Overview of Communication Methods

There are two ways to communicate with your Douloi (or similar) motor controllers:

1. Binary commands using an API by calling methods from a DLL on the PC (not preferred here).
2. ASCII commands sent over an RS232 serial connection.

For your setup, you’re using the ASCII command method. This will require you to write ARC scripts (using the servo Script robot skill, for example) that send the proper ASCII commands over the serial port to control every servo (or motor) in your arm.

What This Setup Does

1. Direct Serial Connection:

   • You connect a lowcost USBtoSerial adapter to your Windows PC.
   • The USB adapter appears as a virtual COM port (for example, COM1).
   • The serial adapter connects directly to your motor controller.
   • In ARC, you bypass using an EZB entirely (which avoids extra circuitry like a MAX232).

2. Initialization Script:
   The following steps (with sample commands) initialize one servo motor on your controller. This would normally be placed in an initialization script that runs when you start the project:

   // Open the COM port on, for example, COM1 at 9600 bps
   COM.open(com1, 9600);
   
   // Initialize servo 1:
   // Set Motor Type to "Servo"
   COM.writeString(com1, "A1 MTT SRV");
   
   // Set Gain for servo 1 to 32 counts (this value is a guess; adjust as needed)
   COM.writeString(com1, "A1 GAI 32");
   
   // Set Zero (damping, or neutral position) to 240 counts-again a guess value
   COM.writeString(com1, "A1 ZER 240");
   
   // Set LoopInversion to Off
   COM.writeString(com1, "A1 LIV OFF");
   
   // Set motion profile parameters:
   // Speed = 1000 counts/second
   COM.writeString(com1, "A1 SPD 1000");
   // Acceleration = 10000 counts/second
   COM.writeString(com1, "A1 ACL 10000");
   // Deceleration = 10000 counts/second
   COM.writeString(com1, "A1 DCL 10000");
   
   // Enable the amplifier/motor
   COM.writeString(com1, "A1 MTR ON");
   

   What Each Command Does:
   A1 MTT SRV - Tells the controller that motor A1 is a servo type.
   A1 GAI 32 - Sets the gain (control sensitivity) for the motor.
   A1 ZER 240 - Sets the zero or neutral point for the servo movement.
   A1 LIV OFF - Disables any loop inversion feature if available.
   In addition, commands like A1 SPD, A1 ACL, and A1 DCL set the speed, acceleration, and deceleration profiles.
   Finally, A1 MTR ON turns on the motor amplifier, enabling movement.

3. Motion Control (Moving a Servo):
   Once the motor is initialized and the parameters are set, you control its movement from within the servo Script skill. For example, you might map the virtual servo (say, V1 in ARC) to a particular motor command, something like:

   // Make sure ports[0] is v1 as configured in the robot skill
   if (ports[0] == v1) {
       // In this sample, positions[0] is the target position coming from ARC.
       // You send the command "A1 MVT XXX" where XXX is the position value.
       COM.writeString(com1, "A1 MVT " + positions[0]);
   }
   

   Here, the command A1 MVT is used to move the servo to the specified position. Note that the range for the position (the counts value) might be different from ARC’s default 1-180 degrees. You can either adjust your project’s servo range (via Project Properties) or use ARC’s Utility.map() function to convert between ranges.

Key Considerations and Testing

Command Formatting:

• Consult the Douloi ASCII command manual (for example, Douloi Legacy Products Manual) to verify the syntax and acceptable value ranges for each command.
• Ensure that each command sends the proper termination characters (for example, a carriage return \r) if required by the controller.

Mapping and Range Conversions:

• ARC’s default servo range is 1-180. However, your motor controller might have a different range (e.g., counts for position).

• Use the Utility.map() function in ARC to convert from the ARC range to your motor’s expected range. For example:

  var motorPosition = Utility.map(positions[0], 1, 180, motorMin, motorMax);
  COM.writeString(com1, "A1 MVT " + motorPosition);
  

Safe Testing:

• Test each command one at a time and run the robot in a very safe environment to ensure there is no unexpected behavior.
• Be especially careful during initial testing; ensure the robot’s mechanical elements are clear of obstructions.

Further FineTuning:

• The values for gain, zero, speed, acceleration, etc., are guess values taken from the manual or by your best estimate. You must adjust them based on tests as well as your manufacturer’s recommendations.
• If you encounter irregularities or failures to move correctly, review both your script logs (using the print() statements in ARC) and the Douloi manual for expected responses.

Hardware Integration:

• Make sure that your virtual COM port (from the USBtoSerial adapter) is properly set up and that the cable connections are correct.
• There is no need for an EZB controller in this configuration, since using it would add hardware (like a MAX232) that serves to convert from a UART’s voltage level to RS232 levels-this conversion is already handled (or can be bypassed) with a USBtoSerial adapter.

Summary

You are effectively replacing an EZB with a lowcost USBtoSerial adapter. Your ARC project will:

1. Open and configure a COM port using the COM.open() command.
2. Send initialization commands to your motor controller to set up each servo’s parameters (type, gain, zero, motion profile, etc.).
3. In your servo Script robot skill, send motion commands (like A1 MVT ) using COM.writeString() methods to move the servo.
4. Map the values from the virtual servos (V1, V2 etc. in ARC) to the motor controller’s expected value range using Utility.map() if necessary.

Remember:
This entire process is based solely on the information from the Douloi manual and our experience with ARC’s scripting. We do not have this robot arm or hardware to test with on our end, so always exercise extreme care when testing.
Additional testing and finetuning are required to calibrate the motor positions, speeds, and other dynamic parameters before full operation.
Ensure that you are operating the robot in a safe environment during testing to prevent any injury or damage.

By following these guidelines and scripts, you should be able to integrate your Douloi controllers with Synthiam ARC. If you have any questions or need further clarification as you test the setup, feel free to ask!

Wow, Ok! It looks like there is a better way. Outstanding help from Synthiam's CS. I learned something here. Thanks!

Thanks to everyone, will start digesting all this info ASAP. Going to be exciting to see what we can do!

Dear Everyone, Randy from Douloi reviewed your guidance and made this response I have posted below. Can I get some more instructions on the point being brought by Randy considering part missing in communication between ARC and the Douloi as to responding to commands sent to Douloi and then the error message etc. that needs to be addressed?

Thanks,

Chuck

Dear Chuck,

The tech support response is large correct but it is ignoring how to handle command response. When you send a command there's a response including an error and value. The error number confirms that the command was properly handled. It's also necessary to query the controller for status and position related information which is not mentioned.

The support was recommending the use of a USB to Serial converter such as this one we often use:

Thanks,

Randy

Oh, that's great that you're in contact with the manufacturer. I just updated the Dynamixel robot skill source code, which is probably the closest as a framework for them to create a robot skill for their product. Here's the source code you can give to them: https://github.com/synthiam/Behavior_Control_Dynamixel

And here's the step-by-step guide that gets them started: https://synthiam.com/Support/Create-Robot-Skill/Overview

Great to hear they're working with you on that.

If they encounter any challenges building their robot skill for their product, they can post here or use the Contact Us form directly.

Great, thanks again. I will see if we can get Randy to do a skill. He is getting old  but still working. No rest for the wicked like me .

Dear DJ, Randy at Douloi has to many things to do. He recommended finding an existing control compatible with ARC and that can handle the industrial arm robot motors and drives. All the motors (6) in total are 170 volt DC with encoders. Can you suggest a controller?

Thanks,

Chuck

@athena, do you have any feedback regarding chucks question?

Below is some feedback and suggestions for integrating highvoltage DC motors with encoders (170 V) into your industrial arm robot using ARC.

Considerations for Industrial Motor Control

1. High Voltage & Current Handling:
   Since your motors work at 170 V DC, you’ll need a controller or drive that is rated for industrial/high-power applications. Hobby-grade or EZ-B-native controllers won’t be sufficient.

2. Encoder/Feedback Support:
   Because you need position feedback from encoders, the controller must support closed-loop control to reliably drive the motors and report their status back to ARC.

3. Communication Interface:
   ARC communicates well over serial, USB, and network protocols. It’s best if the industrial controller can expose a communication interface (USB/serial/Ethernet) so that a custom ARC robot skill can be created to send commands and receive status.

Potential Options

A. Industrial Motor Controllers / servo Drives:
Roboteq Controllers: Many users opt for Roboteq’s highpower motor controllers. They are designed for high voltage motors, support encoder feedback, and provide interfaces (USB, CAN, Serial) that you can bridge with ARC via a custom robot skill.
Advanced Motion Controls (AMC) Drives: These are engineered for industrial applications, support encoder or resolver feedback, and can integrate via communication protocols like RS-485 or EtherCAT.

B. PLC-Based Solutions:
If you already have an industrial drive setup, you might consider using a PLC that communicates over MODBUS/TCP or similar protocols. A microcontroller (or embedded PC/IoT device) can act as a bridge between the PLC and ARC. Synthiam ARC supports custom robot skills, so you could build one to translate ARC commands to your PLC commands.

C. Custom Bridge Device:
If your industrial motor drives aren’t directly supported by ARC, you might add an intermediate microcontroller or industrial computer that speaks to your motor drivers. For example, a robust industrial-grade Arduino, or even a Raspberry Pi, could handle command translation from ARC (via USB or network) to your motor drives. Then, using ARC’s custom skill creation guidelines, you can design a robot skill that interfaces with this bridge.

What to Do Next

1. Review Your Hardware Specifications:
   Identify the exact current, voltage, and control signal requirements of your motor drives and encoders. This will help you narrow down a motor controller that meets those conditions.

2. Select an Interface Option:
   Look at products like Roboteq’s controllers or AMC drives that offer the communication interface you need. Both have been used in industrial high-power applications.

3. Custom robot skill Development:
   If you choose a controller that communicates via Serial/USB or Ethernet, you can build a custom ARC robot skill to manage command sending, status querying, and error handling. Our documentation on creating robot skills is a great starting point: Create robot skill Overview

4. Testing & Integration:
   Once you’ve selected a controller, set up a test bench where you can send motor commands from ARC and receive encoder/status feedback. Make sure that error codes and command responses are correctly interpreted as indicated by the need to process command responses and status queries (as Randy mentioned).

Final Thoughts

While ARC doesn’t offer an off-the-shelf industrial drive for high voltage DC motors, its open architecture and custom skill capability let you integrate virtually any controller-as long as you have a reliable communication interface. We recommend discussing your specific hardware requirements with the manufacturer of industrial controllers (such as Roboteq or AMC) or looking into documented use cases where similar industrial controllers were interfaced with external systems via custom software.

If you need further assistance with designing a custom skill or mapping out the communication protocol between your chosen industrial controller and ARC, feel free to ask for more guidance!

Does this help point you in the right direction? Let me know if you need additional details or step-by-step help on setting up the custom skill.