I currently have 2 AL5D arms built and had been working on calibrating the arms. During the course of calibration, I powered off a robot arm and, once I powered it back on (no cables were disconnected during this time; only the switch was turned off and back on), I have not been able to get the SSC-32U Sequencer Utility or FlowArm to communicate with it again. I set the baud rate to 9600 and then power it on, but the “Auto” light continuously blinks green and the “Found” light never lights up. I tried switching to the second robot arm to see if it was a problem with the cable or SSC-32U board, but the communication never completes. I have uninstalled and re-installed the software on the computer and used another computer, but the results are the same. I have power on the arms (the power light shows blue). I hear the computer tone when I disconnect the cables, so the computer is seeing when the cable is connected.
Basically, I have duplicates of everything and no combination corrects the problem. I don’t have a lot of information about how to trouble-shoot this and don’t know where to start. These are brand-new arms. Any suggestions are appreciated.
Please provide us with one or more pictures clearly showing all components (SSC-32U, jumpers, wires, power connections, etc.). You can attach pictures to your reply in Full Editor mode. See the attached image for details.
When the SSC-32U is powered (by VS1), what happens when you press the BAUD button (near the USB port / XBee socket)? One, both or neither of the LEDs should blink rapidly for a few seconds. Please let us know in your reply what happens with your boards.
You said you were working on calibrating the arms. What software were you using to calibrate the arms and were you able to have them move/respond to commands in this software?
When I press the Baud button, “A” flashes green rapidly. “B” also blinks red twice, but it’s a slow blink, not a flash. Both boards respond the same.
When I was calibrating and experienced the initial problem, I was using Sequencer. Once nothing responded, I also tried FlowArm just to see if it might work there.
Thank you for the pictures. According to those, the jumpers and wiring seems good. The green LED blink rapidly and the red LED blinking twice (once at beginning, once at the end) indicates a baud rate of 9600, which is good (default value).
Please note that for working in FlowArm, the Bluetooth icon needs to be active (blue) to get the proper baud rate (9600).
To check the board, please power it and connect it to the computer. Then, check device manager to identify which COM port it is using (it should be under the category Ports (COM & LPT) ). Then, download and run our free diagnostic tool, Lynxterm.
Once started, please go to SETUP and change the COM port and baud rate. Then, click connect and write “VER” followed by [return] in the black text box. The SSC-32U should respond with its firmware version.
Also, for calibrating the board, we recommend that you use Lynxterm directly. Once connected (and if the board responds to VER), simply click on the Reg. button on the bottom row. Then, first press READ and once the in formation is populated you can set the offsets. You can then activate them on the right side (you’ll need to activate both Global and Initial pulse offset).
I didn’t get a response from either board on the firmware version. The robot arms were connected and powered on when I typed “VER” and pressed enter. I’m including a picture of the Lynxterm window.
I’ve been working with just these 2 arms. I do have a 3rd that is still sealed in the package, which I’ve been very hesitant to open until I have these first 2 working. Would it be helpful if I pull it out of the package, along with the cable and power adapter to check it?
You may want to take out only the SSC-32U (the servomotor controller board) from the extra package so that you can confirm if it works or not and if not, perform the following steps:
Since everything else seems fine, it may be an issue with the interface chip (FT232R) that provides a connection between the USB port and the SSC-32U’s on-board electronics.
Fortunately, this can usually be fixed by reprogramming the chip and reinstalling the drivers. Please try the steps below (see the attached images for details):
For the following steps, remove all connections from the SSC-32U (power cables, servo motors) except for the USB connection to your computer.
With the SSC-32U connected, click on the DEVICES menu and select Scan and Parse F5. A list of compatible FTDI devices should be listed under Device Tree.
Find your device in the list and go to USB Device Descriptor.
Change the Custom VID/PID field to the value of Custom PID.
Go to the Product ID field and change the value to F460.
Right-click any of the items in the Device Tree for your device and select Program Device.
8 )Disconnect the SSC-32U from the USB connection.
9] Reconnect the SSC-32U with the USB connection.
Windows should normally install the drivers automatically. If it does not, simply open Device Manager and install the drivers manually. You will have to browse to where they were extracted to install them.
Once this is completed, reconnect only the power on VS1 and power-up your SSC-32U using the power supply. Then, try the Lynxterm utility again and see if you can connect and obtain a response.
The 3rd board did not work either so I followed the steps as outlined and saw improvement. My students will be working with the FlowArm software. I can now get a solid green line for “Found” in FlowArm. The “A” light blinks green. However, it still is not communicating fully as the box in the lower left says and I can’t properly operate the arm. Is there another step to get it to recognize the robot arm?
When I came in this morning, I powered up the robot arm again and was able to communicate. After powering it off and back on, it wasn’t working again and I had to go back through the driver install that I just did yesterday. I am using Windows 8. Is there a known bug between SSC-32U and Windows 8? I shouldn’t have to re-install drivers on a daily basis.
After re-installation, I am again able to communicate with the robot arm and Lynxterm. FlowArm is still doing the same as my previous post (“found” is green, but there is no arm found).
I was originally trying to calibrate using the Sequencer Utility because that’s what your instructions say to do. In the instructions, you are told to use Lynxterm if you are using SSC-32 or Sequencer Utility if you are using SSC-32U.
Concerning the drivers issue, it may be cause by the security parameters of your setup. You may want to verify with your IT support why this is happening. The drivers used are directly from the manufacturer of the interface chip and we have no control over those. But, we did test them with Windows 7, 8 and 10 with no issues.
The box at the bottom means that your FlowArm software is unable to find the definition files, which basically tell the software the various dimensions of the arm, therefore enabling it to perform inverse kinematics properly.
We have attached a copy of the definitions to this post. Simply extract this into the installation folder of the FlowArm PLTW software (it should be under Program Files (x86)\RobotShop\FlowArmPLTW) and restart it afterwards.
If the software still does not find the definition files, then it was most likely installed with one account (maybe administrator) and is being used with an account that does not have the rights required to read the files. Please reinstall it under the account that will use it. This may happen when the deployment is done as an administrator but the user is not one.
I had the definition files, but downloaded them again anyway. No change.
IT has looked at it and he may have found the problem. The FlowArm software is 32-bit and my computer is 64-bit. We tried downloading the FlowArm again to correct this, but there is nowhere to select between 32-bit or 64-bit. Can you please direct me to a 64-bit version or send it? Thanks!
The software is 32-bit but it installs fine on Windows 64-bit systems using the framework provided in Windows (hence why it is installed in Program Files (x86) and not the regular Program Files folder).
The issue you are facing is most likely a user rights management issue during installation and use. As a reference, all the systems we tested it on (Windows 7/8/10) are all 64-bit systems and it works with no issues.
If the files are still not found it would strongly indicate that FlowArm is unable to see them. This usually happens when a software does not have the right to the folder it is looking it. Trying to be helpful and prevent a crash, Windows will hide this error by using a different local folder instead of the real one (inside VirtualStore). Unfortunately, this other folder will not have the files in it and therefore the software will not find them. You have a few solutions to this:
Run the application as Administrator. This may fix the issue but it may not be a good option if you do not want or cannot give users an Administrator password or account.
Copy the required files to the VirtualStore. It is normally located here: **%localappdata%\VirtualStore**. You should place the files in the same folder as the installation of FlowArm PLTW. By default, this would be: %localappdata%\VirtualStore\Program Files (x86)\RobotShop\FlowArmPLTW.
Reinstall the application so that the user has the proper rights to access the files directly where they are installed.
Since my last post, I have worked with our IT department and had multiple people look at the problem. We continued to have problems with having to go through the procedure you sent on a daily basis to get it to work, so we ended up uninstalling and reinstalling everything. Now, I can no longer get anything to return when I follow the procedure and try to get LynxTerm to show the software version. The only thing one of the IT people noticed was an error in the Device Manager - USB Interface Download. There were 3 events there - the “started” and “configured” events appear fine. The 3rd event is the migration. It gives the error information copied below. My IT person thought this might be the problem but suggested I contact you again for further steps.
I have also been in contact with other teachers (from PLTW training) trying to find someone I knew with a similar experience. The ones I heard from had a range of experiences but nothing similar to mine. I am set up as administrator on my laptop, so that shouldn’t be a problem at all.
Considering the issue type and the troubleshooting already done, the SSC-32U (mostly its interface chip) may be defective. We will be contacting you through our support center for the next step.
