I am trying to use LabView to control the USB16. I cannot get the USB16 to respond at all. I look at the serial output pins using an oscilloscope and the bit signal does not match what I send at all. Also LabView is reading bytes from the controller. I cannot interpret these bytes and do not find anything in the manual describing how the controller responds. If anyone has info on the controller response or on using LabView it would be a great help.
I don’t think you should be getting anything back from the USB servo controller (though I don’t own one myself so I can’t say for 100%). Are you sure you’re seeing bytes getting sent back, as opposed to, say, the return count or the error out of the write block?
Anyway, serial control form LabView can be a little dicey. If you’re using the VISA serial write functions, they only accept ASCII strings, and if you try to convert an integer directly to a string, you’ll end up with the ASCII text characters of that integer. You may be seeing the ASCII character codes of the numeric values you’re trying to send on your Oscilloscope. To send byte values (like to control a Pololu serial device) you need to convert the decimal number to a boolean array (i.e. a byte), then that array to a string. It’s lame, and you can read all about it here (or just check out write serial byte.vi at the bottom of the page).
For how to apply the byte-writing technique to Pololu devices, there are a nice set of example LabView VI’s for controlling a Pololu serial motor controller (which uses the same kind of serial protocol as the servo controllers) here. As I’m sure you’ve discovered, the USB part of your servo controller is just a USB-to-serial adapter chip, and it’s drivers should make it look just like any other com port to LabView.
Also, if you feel like posting your VI, I could take a look at it.
-Adam
P.S. What are you trying to do with LabView+servos? Personally I try to stay away from LabView, but sometimes it’s unavoidable!
We got the servos to work using LabView. The key was the vi to convert a decimal number to the approrpiate ASCII string from Roberto. I am still not sure about the received bytes but it’s working so I am done. We use LabView to control our entire laser experiment. We interface GPIB, serial, ethernet, and USB instruments. We are using the servos to rotate a neutral density filter wheel. We custom fabricated a wheel that mounts to a hub from Servo City. IT makes a very compact and inexpensive wheel. The major problem we have had is finding a 360deg servo. We are using a sail winch servo that seems to do unlimited rotations but the minimum rotation angle for a 1us step is a bit large and the position seems to be a bit unreproducible. We are using a Hitec HS-785B servo. If any one knows a better 360 deg servo it would be appreciated. Thanks for your forum!
Glad to hear you’ve got it all working now, what sort of angular resolution are you hoping for?
Are you using the HS-785? It uses a multi-turn potentiometer to rotate 1260 degrees (3.5 revolutions), and you’re probably getting a little more than that in terms of range by using the Pololu controller. The problem is that the control electronics don’t have any higher resolution than a normal analog servo, and spread out over 1260 degrees instead of the usual 90 or 180 the precision is going to be pretty lame. If you want a ~3x improvement in positioning precision you could replace the servo’s potentiometer with a single turn one.
Do you really need a full 360 degrees of rotation, or would ~300 degrees be enough? The problem is that “one turn” potentiometers can generally only turn less than 300 degrees, and the servo electronics are going to limit that even more. 3 and 5 turn pots are common, so your sail winch probably has a 5 turn, yuk!
Other than that the next easiest way to get higher 360 degree positioning resolution would be to switch to a stepper motor. I’ve been using some nice ones lately with integrated controllers (ASCII interface, good for LabView) and single-slit optical detectors so the stepper can always return to a home position.
-Adam
I’m still guessing you’re using the Hitec sail winch since you said it can do more than one rotation (and since you got an output horn for it at ServoCity), and I just noticed something looking at the servos here at Pololu. If you need more positioning precision, before you try hacking the servo you’ve got or dropping $ on a stepper motor, you might try the GWS sail winch servo. Now, I haven’t used either of these servos personally, but the GWS sail winch rotates just one revolution. Assuming both servos are measuring their potentiometers with the same kind of resolution, it stands to reason that you would get ~3.5 more positioning resolution. It might just be worth $20 to find out!
-Adam
P.S. Standard size GWS and Hitec servos use similar, but not identical output spline shafts. The GWS shaft is a little bigger, but for such a light loading you may be able to just jam your custom plate on (get out the files!).
Hi All,
I stumbled across your conversation just as I was encountering the same problem with my USB-16 servo controller. I read the posts and it way like deja vu all over again. Many years ago I fought with LabView to communicate over a serial line and remember having “discovered” that it was sending text. This time around my problems are even more fundamental though. I can’t even get LabView to list the COM port that the Pololu is connected to. Here is the summary of what I have:
1- installed the Pololu windows driver (on Vista)
2- In Device Manager it shows up as COM3 and claims that it is functioning correctly
3- Using the Pololu Serial Transmitter utility I can successfully send data to the controller (serial active LED blinks)
4- I’m using LabView (7.0) and I pulled the part of Adam’s VI that “CHECK IF THERE IS AT LEST ONE SERIAL COM DEVICE AVAILABLE” out as a separate VI from his Pololu_board_driver VI and ran it.
5- I get a pop-up error message of “SELECT AN EXISTING SERIAL COM DEVICE” which suggests that LabView couldn’t find any serial devices and an error code of 42 (general error) in the error cluster.
In a separate effort to get it to work I also manually set the interface to ASRL3::INSTR in VISA_CONFIGURE and also get an error (42)
To my feeble understanding LabView isn’t “seeing” any COM ports. Does anyone have an idea where I’m going wrong? Do I have to VISA in some separate way to recognize the COM ports?
Any and all thought would be welcomed.
Thanks,
Cameron
Hi Cameron.
Credit where credit is due, I didn’t write the VI, I just lined to it. Roberto O originally wrote it, and did a fine job.
I think your problem is that you’re trying to use an older version of LabView on Windows Vista. It works for the most part, but I’ve heard of people having problems with drivers for external devices, especially the VISA drivers. For example, here’s a similar discussion of the problem.
The first thing I would try is downloading the latest version of the VISA drivers, which you can get here:
joule.ni.com/nidu/cds/view/p/id/1070/lang/en
Let us know if that does the trick!
-Adam
Hi Adam,
You were right, LabView 7.0 has issues with both serial ports and Vista. Sorting through the problem is a little convoluted but here is the synopsis for anyone else who is stuck.
1- Uninstall all LabView software from the Control Panel/Program Updates otherwise when you try and install the latest NI-VISA drivers you will get an error pop-up with multiple messages that all state that the NI-VISA drivers can’t install becuse some of the LabView components aren’t compatible with Vista. The exact messages I had were: “Unsupported version of National Instruments system component detected” “Unsupported version of NI PXI Platform Services detected” and “Unsupported version of NI-VISA detected” each goes on to also say “A version of NI-VISA that is not supported on this operating system has been detected. You must cancel this installation and uninstall the older version before continuing. Refer to Archived: NI Product Compatibility for Microsoft Windows 8 for more information.”
2- Use the NI Vista clean-up tool (available here: http://digital.ni.com/public.nsf/allkb/B4BF3B96988453B98625728100009670) to do some sort of magic inside the OS to completely expunge all of the old NI software, clean out the cobwebs and chase away any evil spirits.
3- install the latest NI-VISA drivers (see the link in Adam’s previous posting)
4- re-install LabView
5- verify that the Pololu usb servo driver is installed by going to Control Panel/Device Manager/ports. It should show up on the list as: “Pololu USB-to-serial adapter (COM3)” Note, your COM # may be different depending on how many ports you have in use
6- Startup LabView and run the little VI (attached) that I extracted from Adam’s VI which descended from Roberto O’s VI. It should report back the same list of COM ports (and maybe LPT’s too) that you saw in the Device Manager list.
Thanks for all of you help Adam and I hope this gets someone else out of the trouble I was having.
Cheers and a good weekend.
Cameron.
find_serial_resources.zip (16.5 KB)