Hello all, I am having a problem with my Trex dual motor controllers. I have two of them connected to the same serial line, which means they both need different device numbers. They seem to work fine, but with one big problem: after power-on, I have to set the device number before the Trex will respond to any extended protocol command with that device number. To get them to work, I have to first disconnect one of them, set its device number, disconnect that one and connect the other one, set its device number, then connect the first one again, at which point they both work as expected. After power is removed (I do have to charge the batteries eventually), neither Trex will respond to the extended protocol at all until I re-set the numbers. The strange thing is that the device numbers seem to be retained in memory (I can read them), but the trex will just ignore its own device number.
I’ve never heard of a problem like this before. If it were affecting only one TReX, I would consider the possiblity of a defect in the microcontroller, but it seems very unlikely that two separate boards would both malfunction this way. I’ll do some tests tomorrow to make sure that this isn’t a firmware issue, but my first thought is that maybe you have a line in your program that unintentionally sets the device ID.
Can you try the simplest test possible? Specifically, write a program that sets the device ID (using the compact protocol) to some value that differs from the default, then try sending a single command using the Pololu protocol with that device ID. Cycle power on your TReX and try sending another Pololu-protocol command with that device ID (do this with only one TReX connected).
Even better would be if you could try this with the TReX Configurator utility. Use it to set the device ID, then cycle power, try reading the device ID, and try talking to it with the device ID.
Hey Ben, thanks for your reply. That is exactly the test I did when I first discovered the problem. I first try to communicate with the Trex (using the configurator) with the expanded protocol on the device number I gave it the previous time it was powered up. It doesn’t work. I connect using the regular protocol, see that the device number is the same thing I set it to last time (even if the last Trex I used had a different device number, so it’s not the configurator remembering it), then set it to exactly what it says it already is, then disconnect. I can then reconnect using the expanded protocol and the device number I just assigned. Everything works. I cycle the power, and try to connect again like I just did seconds ago. It doesn’t connect. ???
There is one thing I haven’t tried. I have a spare Trex that I got several months later than the two I am using, and it’s still in its original packaging. I will try to see if I can re-create the problem with that slightly newer Trex when I get back in the lab on Monday. That might narrow it down to a bad batch or something.
Thanks for your help.
Ok, I just tested the other TReX and it seems to work fine, so it looks like I have two defective TReX’s. Is there anything that I could have done to cause this problem? I have had various things connected to the various inputs, some of which may have exceeded the specified inputs. Is that a possible cause? Come to think of it, I don’t think I ever did communicate with these TReX’s with the expanded protocol before last week, which means the problem may have been there much longer than I thought. Is this something that could be fixed by a firmware update?
In the case that I need a new TReX, what is the absolute fastest possible way to get one?
The device ID is stored in non-volatile memory. If it’s not being stored properly, this could be an indication that that EEPROM memory location is defective, but it seems very strange to me that two different MCUs would have that same defect. It makes it seem more likely that the problem was caused by something you did to both units, but I can’t think of much that would damage EEPROM. Did you command the TReX to write to that memory location (i.e. by repeatedly setting the device ID) an excessive number of times? For example, did you put the command in a loop and call it many thousands of times? The EEPROM is only rated for 100,000 writes.
Do you have this problem with any of the other TReX parameters, or is it just the device ID?
If you need an immediate solution, perhaps you could change the device ID of your working TReX and connect that on the same line as one of the two whose device IDs cannot be changed. If the problem is only with the EEPROM location of the device ID, I could send you a firmware revision that stores this parameter at a different location, but before I do this I’d like to make sure that you’re not having this problem with other EEPROM locations.
If you want a new TReX, our same-day shipping cutoff is 2pm Pacific, so you can have one as quickly as tomorrow if you order in the next four hours with overnight shipping.
Perhaps I should try to clarify my problem. The TReX seems to be able to remember its device number well enough, it just doesn’t respond to it. The device number stays set, it just stops responding to the extended protocol until I re-set the device number (which I have done maybe 5 times, and never in a loop). That seems to be the only thing that will get it to respond to the extended protocol, so I thought that might be related to the problem. I might have another problem with parameters that don’t take effect until they are re-set, but I haven’t tried to reproduce that problem (I noticed it once), so I don’t know for sure. Setting other parameters doesn’t seem to have any effect on this particular problem (although I certainly didn’t try an exhaustive search for other potential triggers).
There is some good news, however. One of the two TReX’s seems to have fixed itself over the weekend (I’m sure it was broken on Thursday), so I’m only having problems with one. If this is an intermittent problem I’m even worse off, so I don’t know what to do besides test them some more.
I’m pretty much out of ideas at this point, aside from a last-ditch reflashing of the microcontroller with the firmware that it shipped with. You can download firmware version 1.0 from the resources tab of the TReX product page and upload it to your TReX using the configurator or a suitable terminal program.
If you can identify any other problems with it, please let me know. If reflashing the device doesn’t fix it, I can give you an RMA number, and you can send it back for us to take a look at.
Just thought I’d let you know how it turned out. We’re just using the two TReX’s that work, I haven’t had time to flash the broken one, but I may try that in the future. The reason I’m in such a hurry is because we’re participating in an international AUV competition in two weeks, and we have lots of other work to do to finish our AUV. It seems that the TReXs we are using are working as they should, so I likely won’t have time to troubleshoot the broken one until after the competition.
