I am using successfully the SMC03A servocontroller board connected to a Pc serial port by means of a small transistor interface to convert signal levels from RS232 to TTL for the SMC03A board.
The board is controlled with a LabVIEW software.
It works really great!
I would like now to use the board through a USB port.
I have the Pololu USB-to-Serial adapter (0391) and I have connected it directly to the SMC03A board without any transistor interface inbetween.
The Driver for the adapter has been installed following the instructions and semms to be ok to me.
I have changed the serial port in the LabVIEW program that runs ok but the board does not receives anything.
Is there something that I doing wrong?
I thank you all in advance for the help you will give me.
Ciao and have a nie day.
The USB-to-Serial adapter should work exactly the same as a real com port as far as Lab View is concerned. I’m assuming you properly installed the drivers and found that it created a new com port, right? You can get a free version of a serial-port monitoring program to see what (if anything) Lab View is actually sending, and to what port:
download.com/Free-Serial-Por … ag=lst-0-1
If Lab View isn’t sending the right things, or anything, out the new virtual com port you could also check the hardware with a loopback test. This is where you connect the TX and RX pins of the USB to Serial adapter and send it characters from Hyperterminal (assuming you’re using Windows). If everything is working fine you should see the same characters back on the screen as you’re sending. If you would like more details for either of these tests please let me know.
If you can determine that the signals going out of the adapter are correct, and the controller still works under direct serial control, then the problem is most likely one of wireing. Can you post a description of your wireing of the two boards (i.e. pin a to pin b)?
Another possibility just occurred to me. Does the RS-232 to TTL transistor interface you built include the handshaking bypass lines (connecting pin 4 to 6, and 7 to 8, like in the diagram in the smc03a users guide)? If so, Lab View might be checking these “handshaking” lines in its serial protocol. You could test this by by removing the two connections and trying to run the motor controller over direct serial again.
If this is the case, you can duplicate these handshaking bypasses on the USB to Serial converter by connecting the DTR and DSR pins to each other, and the RTS and CTS pins to each other. This is alluded to in the USB to Serial converter webpage, but never directly stated.
I’d be interested to know what happens, I need to do some interfacing with Lab View this week, and I have never used it before!
everything is working fine since last friday night. I managed to make it working finally but I had to rewrite completely the whole serial communication part of the driver.
So now it works under LabVIEW with a real serial com port or via a USB to RS232 adapter.
I am still changing the software a little bit and then I will send software source, diagrams and more details. It will be in the next days.
In this configuration I use the full RS232 capabilities:
-Tx to write to the SMC03A board
-Rx to read and debug with an hardware external loop what is going out from the Tx
-DTR to power up the SMC03A board from the software itself but with a external power supply
-RTS to hard reset the board
-RI to read the STATUS Led (green)
-CD to read the ERROR Led (red)
-CTS and DSR to read both end of range switches.
The communication is done by using the VISA serial functions and by defining the com port as ASRLn::INSTR.
The nasty thing is to be able to write one single byte on the com port.
I will be back soon with the remaining details on that.
So for now, thank you all fór the advices and the kind help.
Here some more details about how to write a single byte to the serial COM port from a PC with LabVIEW.
The VISA Write function under LabVIEW accepts only strings as inputs.
If you convert a dec number to string you will have the ASCII equivalent and not what you would like.
Example (see Doc.3J7G77XL NI developer Zone digital.ni.com):
If we want to send “9”, “1001” binary or even the hex code “09” we are sending characters.
If you write the character “09” to the serial port, the hardware receives “9” which is a symbol.
The ASCII code number of this symbol is 39. This is an actual number. It is in HEX format, so 39 actually
translates to the value 57 in base 10.
57 is not 9.
The workaround is the following. Before writing the number to the serial com port, you have to do some cosmetics:
- cast the dec number to Unsigned8
- convert the Unsigned8 to an array of booleans
- reshape the array to 8 elements exactly
- convert the array of 8 booleans to a decimal number
- cast the dec number to Unsigned8
- build the Unsigned8 into a one element array
- convert the one byte array into a string
- an then write it to the serial COM port by using VISA Write.
You must use VISA Write and not the old serial port functions if you want to use a USB to RS232 adapter as well.
Once the driver will be ready I will provide more usefull details.
Adam, your suggestion to bridge the Tx to the Rx on the RS232 side of the USB adapter was really very helpful. Thank you.