Pololu serial 8 servo controlled using Labview

Hi,

I was wondering if anyone has had any success in building a Labview vi to control 8 servo motors from the polololu serial 8-servo controller (assembled). I have looked at a couple of different threads to try and get a starting point :

When i try and run my vi, I get an error with it saying that possible reason is "VISA: (Hex 0xBFFF0072) the resource is valid, but VISA cannot currently access it. I am also not entirely sure if I have my vi set up correctly, I understand that it currently will only be able to control 1 servo at time, but will eventually adapt it to control all 8 at once. I have attached a block diagram of the vi I am trying to use, any help would be much appreciated.


Hello.

For anyone following this thread, hyperons has called us several times today. He has switched from using LabVIEW to using the Pololu Serial Transmitter utility in order to debug his system.

Did you ever get past the “0xBFFF0072” error message? If so, please let us know how because your solution might be helpful to future people in the same situation.

You should consider using our Maestro servo controllers which are better than the Pololu Serial 8-Servo Controller.

If you continue to have trouble, please post a screenshot of the Pololu Serial Transmitter Utility showing what command you sent, along with a full description of your procedure, the expected result, and the actual result.

–David

I figured out the error message, when I was trying to run my vi I had the controller connected using the serial transmitter so once I disconnected it the vi ran. I attached a picture of the commands I am trying to send. When I run the vi shown above I get the yellow and red light to flash but that is it.


Thanks for the screenshot of the serial transmitter utility. I checked the baud rate and the bytes of the command and they look OK.

Are you sure the controller is configured to use the Pololu protocol? The protocol selection jumper, which is shown on the second page of the user’s guide, should be removed.

Could you try sending the three-byte command 0x80, 0x02, 0x00 and then see if your original command works? That command will configure the controller to respond to servo numbers 0-7. This is necessary if that configuration was changed at some point in the past.

Also, you are using the “Set Position, 7-bit” command. Could you try using the “Set Position, Absolute” command? For example, to send servo 0 to a position of 1700 microseconds, you could send these six bytes: 0x80, 0x01, 0x04, 0x00, 0x1A, 0x48

After that command is sent, the servo controller should be outputting 1700 microsecond pulses on channel 0. Do you have an oscilloscope available so to check it?

Also, what power supply you are using for the servos?

–David

Hi David,

Yes, I have the controller configured for the Pololu protocol. I am using the set position, 7 bit command, at the current moment I don’t have access to an oscilloscope, but I did enter the commands for the set position, absolute and got a response from the servo. I am using a AT 300W power supply, here is a link to it if you want more information on it microcenter.com/product/3216 … wer_Supply. When I currently run the labview vi, I get both green and red light to flash, I assume I am still not sending the commands properly, but have not been able to figure out what the problem.

thanks for the help

I am glad you were able to get a response from the servo. This means the hardware is functioning and we can focus on the LabVIEW code. I don’t know much about LabVIEW, but I can point you to another resource on the forum where a customer was able to control one of our Maestro servo controllers with LabVIEW:

I would recommend looking at how he assembles the serial bytes because the Maestro protocol is pretty similar to the Pololu Serial 8-Servo Controller and his code looks different from yours.

If that does not work, maybe you could try sending just one hardcoded with LabVIEW. By specifying each byte of the command instead of trying to compute them from a servo position, you can be more sure that you are getting the command right and you might be able to make something work. That would be a good first step towards building the general code that you want.

–David

Hey David,

Thanks so much for link, it finally works, though there are a few kinks though its great progress. There is some error where I have to run vi like 5 times before the command actually gets sent. The controller is telling me that I am sending the command wrong but when I send it again it works. I have attached what I have now in case anyone else needs it and will upload the future vi.

Thanks again
servo_v3.vi (10.3 KB)

I am glad you were making progress. I am not sure why are you continuing to have some trouble with the vi, but maybe someone with more LabVIEW experience might be able to help you with that.

–David

Hi,

I am trying to control 8 servo’s simultaneously using the labview code that I have written. I assume that I can’t just send the commands all at once i.e. just have a giant string of the byte commands. I have tried using a while loop and where I just changed the position of a single servo, but it doesn’t work unless I put a time delay of around 200ms on each iteration. I am able to control two servos simultaneously but can’t control any more than that, using just 1 string with both commands. I assume the error is I cant send the commands all at once in 1 strings. I also assume that there has to be some delay in sending the commands to the controller. If this is so, can someone please advise me in how I can control the servo’s simultaneously or if I need to get a different controller.

thanks

Hi, Hyperons.

As I said on the phone, the servo controller should be able to handle a continuous stream of serial commands, so I suspect there is a problem with the rest of your setup. Can you describe exactly what the LEDs are doing when you encounter a problem? Can you tell us what bytes you are trying to send from LabView? Have you verified that those bytes are what is on the serial port? If you have access to an oscilloscope or logic analyzer, you can probably look at the bytes coming out of your computer to see what they look like. By the way, 200ms sounds like a long delay.

- Ryan

Hi,

When I encounter a problem the yellow LED stays on and the red LED flashes or the red led stays on and green led flashes. The bytes I am trying to send are 0x80 0x01 0x02 servo num position. The way I have to send the commands is I have a byte array and then convert it into a string and then send it over the serial port. I can get it to work when I send the commands to control one servo or when I concatenate two strings to control two servos. When I try to concatenate strings to control 3 servos it doesn’t respond. I have tried a loop where I just change the servo num every iteration and I get 0 response from the system unless I put in a time delay. I currently do not have access to an oscilloscope so I can’t look at the output from the computer.

thanks

I suspect your baud rate is not consistent enough.

From the user’s guide:
“If the detected baud rate is too high, the red LED will turn on and the green LED will flash quickly.”
“Once you choose a baud rate, all subsequent transmissions must be at that same baud rate.”

Have you been able to determine when you get the one kind of LED flashing vs the other?

- Ryan

Hi,

I have tried changing the baud rate. I have it currently set at 9600 and that is when I get the red and green led. Though, with that error, sometimes I am able to just rerun the program and the servos will respond. The other configuration of led, where its constant yellow and flashing red seems to happen when the baud rate is too low. I just decreased the baud rate and saw a change in the configuration of the LED’s so I assume that is what the yellow and flashing red means. If that is the case I should be able to just increase the baud rate, but I get another error from labview that stops it from sending the commands when I try to go over 9600.

thanks

When you lowered the baud rate, did you power cycle the servo controller? Once it receives serial commands, it remembers the baud rate until it turns off. The led indicator state you are describing, solid yellow and flashing red, is not one of the two baud rate error indications. So, it seems like it might be some other kind of error.

You are not describing your system or your problems with much detail, so it is hard to help you debug it. Please explain exactly what bytes you are sending (e.g. you didn’t say what servo number and position bytes you are sending), and try to make the simplest program that doesn’t work. For example, if you make a program that just sends 3 set position commands and then stops sending commands, does that work? Once you find the simplest program that causes trouble, please post exactly what bytes you sent, exactly what your control flow or looping logic is doing, and as much other detail about your setup as you can.

- Ryan

Hi,

To control 1 servo, the command byte array is [128 1 2 0 0] which is then converted to a string and sent over the serial port. When I control 2 servos I can either send [128 1 2 0 0 128 1 2 1 0] or separate the array into two arrays and then convert them into strings and then concatenate them. When I try to control 3 servos at once I send [128 1 2 0 0 128 1 2 1 0 128 1 2 2 0].

When I try to use the loop it is similar to this
i=0
while i <3
command byte=[128 1 2 i 0]
i=i+1;
end
when I run this, the servos only respond if I have something similar to a 200ms delay for each iteration.

I also have a 30 amp power source so I don’t that I have an issue where I am drawing to much current to use all the servo’s simultaneously

Can you try making a simpler program, like I describe in my last post?

This step of converting a byte array to a string worries me. How do you know the case where you send one command works? Does the servo actually move to where you expect?

30A is a lot. I hope you don’t have the current limiting set that high because that could be dangerous.

- Ryan

Hi,

I have made the simplest program, where I just send the byte array [128 1 2 0 0] which is to move servo 0 to position 0. Labview requires that I give it a string to send over the serial port, so that is why there is the conversion from byte to string. When I send this command the servo moves to 0 position, I can change the position to 90 and servo moves to the desired 90 position. I have also made a program that can move the servo’s sequentially using the while loop I described in my previous post. It only does this reliably if I have a time delay on the while loop of 200ms, i.e. it waits 200ms before executing the next iteration. I was wondering if you can explain why I can send to commands, like I described in my last post, and have the servo’s respond, but why if I try to increase to 3 commands it doesn’t respond.

thanks

Thanks for being more explicit about what you’ve done. Please note that when you say “doesn’t respond”, you are not describing the problem was well as you could. You could say “the servos do not move and the LEDs are showing X and Y”.

Let me summarize the experiments I think you’ve tried and the results I think you might be hinting at:

  1. When you send [128 1 2 0 0] or [128 1 2 0 90], the servo moves as expected.
  2. When you send [128 1 2 0 0 128 1 2 1 0] or [128 1 2 0 90 128 1 2 1 90], the servos move as expected.
  3. When you send [128 1 2 0 0 128 1 2 1 0 128 1 2 2 0] or [128 1 2 0 90 128 1 2 1 90 128 1 2 2 90], you get some error. The servos are not moving. What are the LEDs doing?
  4. When you use a while loop with three servos that should be similar to the commands in experiment 3, you get some error. The servos are not moving. What are the LEDs doing?

Please let me know if I am wrong about any of the above experiments and their results. If you have not tried any of the above experiments, please try them and tell me the results.

- Ryan

Hi,

Sorry for no being more descriptive. I am going to just run down the list you have, either agreeing or modifying the statement:

  1. correct
  2. correct
  3. The servos are not moving and the yellow LED is constant while the red is flashing.
  4. When running the while loop, if the time delay was set to low, then all of the LEDs are flashing and the servos are not moving. Anything lower than 200ms time delay and the servos dont respond reliably. Anything less than a 100ms delay and the servos dont move.

thanks

I cracked out a servo controller to try to reproduce your problem. I wrote this C# code:

using System.IO.Ports;

namespace SerialServoControllerTest
{
    class Program
    {
        static void Main(string[] args)
        {
            SerialPort serialPort = new SerialPort("COM6", 9600);
            serialPort.Open();
            byte[] command = new byte[] { 128, 1, 2, 0, 90, 128, 1, 2, 1, 90, 128, 1, 2, 2, 90 };
            while (true)
            {
                serialPort.Write(command, 0, command.Length);
            }
        }
    }
}

and used the Parallax Serial Adapater. I took off the protocol selection jumper. I powered VSERVO and VIN at 6V. I connected a servo to channel 0. When I run this code, the servo moves to position and only the green LED is on.

I then wrote this program:

using System.IO.Ports;

namespace SerialServoControllerTest
{
    class Program
    {
        static void Main(string[] args)
        {
            SerialPort serialPort = new SerialPort("COM6", 9600);
            serialPort.Open();
            byte[] command = new byte[] { 128, 1, 2, 0, 90, 128, 1, 2, 1, 90, 128, 1, 2, 2, 90 };
            serialPort.Write(command, 0, command.Length);
            serialPort.BaudRate = 10000;
            serialPort.Write(command, 0, command.Length);
            serialPort.Close();
        }
    }
}

Which changes the baud rate after a couple of commands. This code generated the LED sequence you are seeing: solid yellow, red flashing, and green off.

I believe that something is wrong with your LabVIEW-computer system that is generating the incorrect baud rate. I suggest seeking help with someone more experienced with LabVIEW serial communication or exploring alternate options for your serial generation.

- Ryan