I have a TReX chip with two motors hooked up to it, and when I first got it everything worked great. It is controlled through a BASIC Stamp microcontroller that is hooked up to a computer. I just hooked everything up again after taking a break, and when I send commands, I am getting very very slow motor movement. It is in the right direction, but both of the motors are barely moving.
Does anyone have any idea as to why this could be happening?
I have a few questions for you:
- How are you powering your system?
- Can you think of anything that might have changed between when it worked and now?
- If you disconnect your motors, do the motor indicator LEDs light up as you would expect (i.e. brightly when you command a high speed and dimly when you command a low speed)?
- Have you changed any of the TReX Jr’s configuration parameters from their default values?
We are powering our system with a 12V car battery. Right now it is not fully charged, so it’s only outputting 9V. When I hook the motors up directly to the battery, they go at full speed.
Nothing has changed - I even tried more than one TReX Jr. I have three.
Yes, the motor LED’s light up as they are supposed to.
I have upgraded the firmware because the BASIC Stamp requires that. All of my chips are at v1.1. I have no jumpers on on any of my chips as per the settings I need.
That’s all I can think of.
I have no idea what fixed it, but I sent it a simple command at speed 60, and they worked. I increased it to 127, which is what it was at when it wasn’t working, and it worked. I have no idea why…
I’m glad to hear you have it working now. If the same problem affected multiple TReXes that at one point worked fine, the problem almost certainly has to do with your system and not the TReXes themselves, so that’s where I’d start looking if the problems recur.
I seem to be having the problem again - I have reevaluated the situation and noticed that when I have this problem, the motor speed and direction LED’s, both the red and the green, are on continuously. This does not make any sense to me.
I tried what fixed this problem for me last time and it did nothing.
It is normal for both motor direction LEDs to appear to be on at the same time if you have a motor connected and are not driving at full speed. During the driving portion of the PWM (the positive duty cycle), the correct direction LED will be on, and during the coasting portion of the PWM the incorrect direction LED will be on, so the net effect is that it appears both direction LEDs are on at the same time. This is a result of the inductance of the motor, which acts to keep the current flowing when the motor driver outputs switch to high-impedance during the coasting phase of the PWM. The only path for the current once this happens is through the direction LED that corresponds to the opposite direction. Does this make sense?
What fixed the problem the last time? I thought things just suddenly started working again. I still think the problem is somewhere in your system (noise on the serial line, a problem with your power source, etc).
Last time I set the speed to 60 and then back to 127 and it worked. That time I had one chip hooked up. This time I have 3 at the same time. I think it may be a power source problem because our battery is not fully charged. Is there any way to check if there is noise on the serial line?
What is your serial source? Is it something that could be especially prone to noise, such as a wireless connection? The best way to check for noise would be with an oscilloscope. If you don’t have access to one of those, you could try enabling CRC error detection on your TReX. This requires you to transmit the appropriate CRC7 byte for each command packet as the final byte. You can see the CRC section of the TReX’s user guide for more information and sample code for computing the CRC7 byte. If you have a noisy serial connection that is altering serial bytes, the CRC7 you transmit won’t match the CRC7 byte the TReX expects for the packet it has received, and it will reject the command packet, producing a CRC error in the process.
Have you tried using our TReX configurator program? Does the problem persist if you use it to set the motor speeds?