Pololu Robotics & Electronics
Menu
Shop Blog Forum Support
My account Comments or questions? About Pololu Contact Ordering information Distributors

Pololu Forum

TReX Jr Pololu Serial Protocol issue with return values on daisy chained controllers

Support Motor controllers/drivers and motors
#1

I have two TReX Jr (FW ver 1.3) motor controllers daisy chained together and connected to a Beaglbone Black (BBB) UART (TTL serial interface). The BBB Tx pin is connected to both of the TJr receive pins and the BBB Rx pin is connected to the TJr transmit pins.

One of the TJr controller IDs was changed to ‘8’ so each TJr has a unique IDs (7 & 8) and I can successfully send commands to each controller using the ‘Pololu Protocol’ (0x80, 0x07, 0x42, 0x30) to set motor1 speed on controller 7 to 0x30. So I know the connections are properly made up. The issue is when I send a command looking for a response when the controllers are daisy chained.

If I disconnect one of the TJr, from the serial chain, and send a command expecting a return the return values are received. For example…
I send 0x81, or [0x80, 0x08, 0x01] and I receive ‘TreXJr1.3’ as expected. This works for the other controller and all other commands as well. However, when I have both controllers connected on the daisy chain no return values are received from either controller.

#2

Hello.

When daisy-chaining multiple TReX Jr controllers on the same serial line, simply connecting the TX pins together and back to the main microcontroller will not work since they will interfere with each other. You might find this post by nexisnet helpful.

If you need to get information back from all of your controllers, you could AND their TX outputs together before connecting them to your microcontroller. Since two of your TReX Jrs are configured to the same device number, you should probably only connect one of them in this manner though, otherwise you will likely still get interference when they try to respond at the same time. Unless you need to be able to get information back from each of them separately for some reason, then you would probably be better of using unique device numbers for all 3 of your controllers.

By the way, we generally recommend our newer and easier-to-use G2 Simple Motor Controllers over the TReX Jr. In this case, it would simplify your system since each Simple Motor Controller G2 has a TXIN pin that can be used to daisy-chain multiple units instead of external AND gates, as shown in the “Connecting a serial device” section of the Simple Motor Controller G2 user’s guide.

Brandon

#3

Hello,

Thanks for the link, to the other post, but as stated in the original post I have connected the devices together in parallel and changed the ID on a controller to 8, vs the default 7, just as stated in that post. So the controllers are connected in parallel, one with ID byte 0x07 and one with ID byte 0x08, and the Tx/Rx lines are ‘crossed’ at the Beaglebone development board.

Why doesn’t daisy-chaining the TrexJr serial connections work the same way as any other daisy-chaining of serial devices e.g. CAN, RS-422/485? Typically all the devices on the chain have their transmit and receive lines tied together and then these two lines are attached to the ‘master’ devices (chain’s Tx to Master Rx, and chain’s Rx to Master Tx which is how these are currently connected as stated in my original post). The ‘interfering with each other’ statement is resolved with protocol and implementation. So in this case when I send data expecting a reply I send the command and wait for reply before sending next command. Ensuring one device is not going to reply over another.

Using external logic would not help in this situation for the following reasons.

  1. What would be the ‘second’ input for the AND gate? If I tied the inputs together, i.e. creating a logic buffer, the same issue would still be present as the controllers Tx lines are still tied together.
  2. If the AND gates second input is the other controller’s Tx line, then the logic gate’s output is only driven when both controllers are transmitting the same bit value and the same time.
  3. Using a logical OR gate would not provide a solution for the same reason as stated in (1) above.

I appreciate your suggesting the G2 however, that controller does not appear to meet the necessary requirements of this system. The product comparison states the G2 devices operates at 5.5V vs the 5V of the TReX devices. The design is using a 3.3/5VDC system so the signal levels from the BBB may be insufficient for the G2s. The TJrs were selected based on the information presented on your website and documentation for that reason.

#4

The TReX Jr uses a TTL serial interface where the TX pin is high when idle and goes low to transmit data (and it is driven both high and low, as opposed to some other interfaces like I2C where it is pulled high and driven low). If you connect several together and one of the TReX Jrs is trying to transmit data while the others are idle, you are basically shorting a low output and a high output together, which is both potentially harmful to the TReXes and not guaranteed to go low enough for the main controller to register it. By using an AND gate to combine them, the signal on the output of the AND gate will go low when any of them is transmitting data without making them conflict by driving the same wire in different directions. Interfering with each other with respect to time is a separate issue, and as you mentioned, that is prevented by the protocol.

By the way, as described on the product pages, the SMC G2 is a 3.3V device (with 5V tolerant inputs) and its TTL serial interface uses 0 V and 3.3 V on TX (though it accepts 0 V to 5 V on RX), so it should work with a 3.3V device like a BBB. It sounds like you were looking at the operating voltage instead of the logic voltage.

Brandon