Hi, I just got my motor to work with a TReX Jr with the included configuration software. For my project, I need to have two TReX Jr’s connected to two serial ports on my computer and I need a program that can control both of them simultaneously. Does anyone have any suggestions?
Thanks
What do you want this program to control the motors in response to? If you want something more sophisticated than just running two copies of the Configurator at the same time, you’re probably going to want to write your own program for this.
What kind of computer are you using (i.e. Windows, MAC OS, Linux…)?
Do you have any general experience with a programming language (C, C++, C#, Java, etc…)? You can control (multiple) serial ports with just about any language. Alternatively, do you use any control/simulation programs like Matlab or LabView?
-Adam
P.S. Sorry to answer a question with more questions!
I want to be able to control the motors first with the keyboard, then ultimately with a joystick. I am using a computer with Windows, and the reason I can’t use two instances of the same program is because I need to be able to control the 4 motors simultaneously, not have to switch in between screens. I have some experience with C, and anything I don’t know, I could probably figure out through resources I have.
I have never heard of MatLab or LabView.
Oh, also, I only have one serial port on the computer I’m currently using, and on the computer I will eventually be using there aren’t any. Are there serial emulators for USB?
You can actually “daisy chain” both of your TReX controllers together on a single serial port by changing the device number on one of them. The default device number for a TReX Jr is 0x07, but you could set one to be 0x08, then connect the second controller in parallel to serial and ground from your port. One controller will still respond to commands that start with [0x80,0x07] and the other will respond to commands that start with [0x80,0x08]. Neat-o.
Now, that doesn’t help you on the computer with no serial ports at all, but yes, there are lots (and lots) of USB-to-Serial adapters, which output either TTL (aka logic-level) or RS-232 level serial. The only difference between these two protocols as far as you need to be concerned is where you wire the connections between an adapter and your TReX. Pololu has a nice TTL level adapter available here. Slightly cheaper, generic USB to RS-232 adapters abound. I don’t think I’ve ever had two of the same brand, and some work great, but others I couldn’t get to work at all! It’s a crapshoot.
The good news for you is that once you get a USB to Serial adapter working, it will look to Windows just like a hardware com port (you can even set the port number) so any software you develop for your real serial port should continue to work over an adapter with no changes.
Configuring and communicating with a serial port from a C program in Windows isn’t too terrible. I would suggest reading through this document: Windows Serial Port Programming by Robertson Bayer. It’s not too long, and very well written. If you want some demo-code to start from, you could also hack at this program I wrote a while back for simple keyboard-controlling Pololu serial servo controllers, which use very similar serial commands to your TReX.
-Adam
Wow, thanks a lot. Could you please elaborate on how to daisy chain the controllers? I’m not quite understanding that.
Thanks
Sure. The TReX controllers have two different sets of communication protocols, described in the documentation. The “compact” protocol consists of simple, broadcast motor commands, sort of like shouting Hey, do this". The more complex “Pololu” protocol includes extra bytes that include a unique programmable device number, 7 by default, which is more like shouting “Hey you, controller number 7, do this”.
If you hook up just one motor controller to TX, RX and GND, you should be able to change the device number using the configurator program (I don’t actually own a TReX yet, I think I’m getting one soon…but I see there is a space to enter a device number so I assume that lets you set it. If not you can do it from a terminal program with a string of bytes). So, lets say you set one of your controllers to have device number 8 this way.
Now you can split the computer’s TX line, and wire it to the RX pins on both of your TReX controllers. You should also wire both controllers to the serial ground line. You should not wire both controller’s TX pins to the computer’s RX line, this will cause problems. You will probably need to leave one controller’s TX line connected to keep the configurator program happy, as it expects to get information back from the TReX. If you really need to get data back from both motor controllers you can do tricks with diodes and resistors (and time it so they’re never talking back at the same time) but in this case it would probably be much simpler to just get two USB to Serial adapters (you can do this anyway if it makes things simpler for you).
The most important part is that when your computer ‘talks’, both devices are listening, but each is listening for commands addressed to its own unique identifying device number. So, when you say “Hey, controller number 8, do this”, only the controller with the number you changed responds, while the controller with the default device number 7 waits for a command addressed to it. Both controllers should respond identically to compact protocol commands.
Anyway, I’m not sure if that cleared anything up or not. Is there a part that still isn’t clear (or is possibly less clear at this point)?
-Adam
P.S. I just edited the link for the serial port programming document to a more recent revision, so if you already download a copy you might want to get the newer version.
Thanks for all your help. That cleared some things up, but yousaid split the computer’s TX and wire to the TReX’s RX? Wouldn’t it be RX to RX?
And one more question - I am new to sending hexadecimal c ommands and packets of data, and I’m just wondering how to do this. I don’t need a whole program right now, I just want to begin testing with simple, single packet at a time, things. I have hyperterminal and another program like it, but a little better. I can’t recall what it’s called now.
Thanks
TX stands for Transmit, and RX stands for Receive, so in general when you want two devices to communicate, you want to connect TX from one device to RX from another. This is an odd case, since usually you want to connect pins with the same label together (like GND to GND).
You could think of your mouth as being a TX pin, and your ears as being an RX pin. If we’re standing in different rooms, we can talk to each other with two sets of those tin can string-phones, which are just like wires. Of course, the string phone from my mouth should go to your ear, and the one from your mouth should go to my ear. It’s not very useful to string our ears together.
Extending the comparison a little, multiple devices can receive instructions from a single commanding device by splitting a wire from the commanding device’s TX pin to the RX pins of the receiving devices, or:
TX and RX pin labeling can be really confusing though. Usually pins are labeled from the point of view of the device itself, so a TX label means “This is my TX pin” (all Pololu devices are labeled this way). Sometimes there is a distinction made between a master device and a slave device, and while TX on the master device means “This is my TX pin”, TX on the slave device may mean “This is my TX pin” or it may mean the opposite “Connect the master’s TX pin here, this is my RX pin”.
To further complicate things, serial cables can be wired differently. Some 9-pin serial cables are “straight through,” meaning pin 2 at one end connects to pin 2 at the other end, and the same goes for pin 3. These are meant for connecting a master device, or DTE (Data Terminal Equipment, i.e. your computer) to a slave device, or DCE (Data Circuit-terminating Equipment, i.e. an old serial modem). The computer sends on pin 3 and receives on pin 2, and the modem is wired already to send on pin 2 and receive on pin 3. A straight-through cable connects pin 2 to pin 2, and pin 3 to pin 3, and both devices are happy. There are also “null-modem” cables, which are meant to connect two master devices, like two computers, together. Since both devices are expecting to transmit on pin 2 and receive on pin 3, the wires are crossed inside the cable (pin 2 at one end goes to pin 3 at the other). It gets really crazy. The first thing I do when I pick up a serial cable is test the wiring.
It generally does not work to have multiple TX pins wired together without some extra components, and you would need to make sure that the connected transmitters try to talk at the same time. If all you want to do is command the motors, you can leave the TX pins on your two TReX controllers disconnected (you will need to have a controller’s TX pin connected when you set it up with the configurator program). If you need to use the response-features of your TReX controllers (like if you wanted to measure the motor current for example) I would suggest just getting two USB-to-Serial adapters.
ANYWAY, that servo control code I sent you builds strings of bytes and then sends them out a serial port, but you can totally try strings out with Br@y terminal first. You can type byte values into the white text box near the bottom to build up strings of bytes, then click “send” when you’re ready to transmit them (you should uncheck the “+CR” box, which optionally adds a carriage return, byte value 13, to the end of each command).
To build commands in hex, start with a $ character followed by two hex digits. So, if you wanted to send the string [128,1,4,1,23,63] you would type “$80$01$04$17$3F”. You can send decimal numbers by starting with a # character followed by three dec digits, so to send the same string [128,1,4,1,23,63] you would type “#128#001#004#001#023#063”. You can mix and match too, like this: “$80$01$04#001#023$3F”. Just be sure to always fill up the two hex digits or three dec digits (add leading zeros if you need to) or the terminal program will interpret them as ascii text characters instead.
So, what are your plans for two computer joystick-controlled TrEX motors?
-Adam
P.S. The windows calculator will convert numbers between decimal and hex. Under the “view” menu select “scientific”. You should now have a set of buttons just below the number readout (on the left) that let you switch the displayed number between Hex, Dec, Oct, and Bin. Quite useful.
OK, thank you. One more thing (for now, at least) - when the command to the TReX is “0xC7” what do you send to the robot? Just “C7”? The “0x” is what’s confusing me, as hex commands always seem to stard with it.
I am in a high school robotics class and we are going to the MATE underwater ROV competition in May. We went last year and used direct switches, which didn’t work out too well, so we’re going for a little more control this time.
Hello.
If you just want to send data packets, you can consider using our serial transmitter utility. You can enter the byte values as either decimal (0 - 255) or hexidecimal (0x00 - 0xFF). Note that the this utility transmits at 9600 baud, so you will first need to use the TReX Configurator application to set the TReX to run at this baud (the TReX default baud is 19,200).
When you send data in the form of a byte, you are sending a number. How you represent that number on paper or in your code does not affect the value of that number. If I write 255, numerically that is the same as 0xFF. It just so happens that the first representation of the value is in base 10 (decimal) and the second is in base 16 (hex). When the command to the TReX is 0xC7, what is sent is the value of that number, not the C, not the 7, not the 0 or x. The “0x” just tells the transmitting program that it should expect a number that’s represented in hex, so it knows how to interpret the string and compute the value correctly.
For example, what if I told you that I want to send the value 10? Should you interpret the string “10” as binary and treat the value as 2? Should you interpret the string “10” as decimal and treat the value as 10? Should you interpret the string as “10” as hex and treat the value as 16? Somehow, you have to both give me the string representation of the number and an indication of how to decode that string (i.e. what base is the number in). The standard convention is to assume base 10 by default. If you want to represent the number in a different base, you add a prefix to tell people that the base has changed. Often this is 0x for hex and 0b for binary. Does this make sense?
- Ben
Yes that does make sense thank you. So, for example, if I wanted to send the packet “0x80 0x07 0xC7”, what would I type into the field of my terminal program, in this case Br@y.
You would type “$80$07$C7” into the white text box of Br@y terminal then click send or hit enter. You could also type out the same numbers in decimal: “#127#007#199”. The serial output would be the same.
This would be different in other terminal programs.
-Adam
OK, thank you guys so much. I will test these out when I have a chance and come back if I have further questions.
Hey, I got the commands working - Great Success!
Now I am almost clueless about how to begin programming the program in C to send it commands. Any help?
Thanks
Have you taken a look at this code yet?
It’s meant for commanding the Pololu serial servo controllers, but if you wanted to, you could alter it into a TReX commander. It uses the Windows API to control access to the serial port, and has a simple key-press menu structure. In particular, you might want to look at the function ‘put’, which shows how to build up an array of bytes then send them out the open serial port. If something doesn’t make sense or isn’t working right feel free to ask about it.
-Adam
In addition to Adam’s code, you can take a look at Colin Karpfinger’s tutorial on using .NET to send serial commands to a Pololu servo controller. The serial servo commands in the tutorial will need to be modified to be what the TReX expects, but it will at least serve as an example of how you can use Visual C# to send serial command packets from your computer to a target device.
We also have a tutorial on controlling devices with the serial port and writing graphical interfaces.
If you have any specific questions on how to make this work, please ask.
- Ben
