Serial Communications Problem w/ Prop and Motor Controller

Greg Norton

I've got a set of the motor mounts and controller and I'm trying to learn how to communicate with them using the propeller. I've set it up so the serial interface has a 1k resistor inline on the serial data pin to protect the prop from the 5v output of the motor controller. The attached program just attempts to move the wheels 1000 positions forward, wait until it has arrived and move 1000 positions back (and repeat forever). I usually get 1 or more loops through the program where the wheels move as expected, but eventually it will hang waiting to receive a byte from the motor controller when I check for arrival. I know it's waiting at the serial.rx statement and not looping because the counter variable does not increment when it finally stops.

I have also noticed that sometimes my program advances very rapidly through the forward phase and starts out by moving in reverse. I'm guessing the two problems are related, but don't know exactly how.

Anyone have a suggestion?

Thanks.
Greg

Bruce Bates

Greg -

You probably want to take this issue to the Propeller Forum. There is a separate Parallax Forum which addresses Propeller questions and problems. Alternatively, you can ask one of the administrators to move this message for you.

Regards,

Bruce Bates

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When all else fails, try inserting a new battery.

Greg Norton

I don't see a way (looked in the edit screen) for me to move this post, but if any of the admins think it should be moved, feel free.

Greg

Mike Green

I think your problem is that Simple_Serial is unbuffered and written in Spin. It tends to not work very well above 9600 Baud, particularly on receive. I suggest you switch to using FullDuplexSerial instead which is buffered and can handle much higher Bauds.

You may be able to just substitute one for the other only needing to change the .init call.

Greg Norton

Hi Mike,

I made the suggested changed to FullDuplexSerial, and now it sometimes goes forward (not sure how it manages to miss this occasionally), then always goes backward and hangs where LOCATION = 4, waiting for the signal the it has arrived. I am unsure if I have selected the correct mode settings for the call to serial.start.

Anything else I should look at here? Thanks for your help.

Greg

Mike Green

You haven't mentioned anything about the motor controller you're using and I don't see anything else obvious without a lot of further details about your controller, your overall setup, your motors, etc.

Greg Norton

Hi Mike,

I should have been more clear. I'm using the Parallax Motor Mount and Wheel Kit and the Prop Demo board. The serial connection from the prop to the motor controller has a 1k resistor in line, and the output of the position controller goes to an HB25. It's an all Parallax setup, pretty much as specified in the various documents.

Thanks again.
Greg

Beau Schwabe

Greg Norton,

Can you provide a schematic and/or pictures of your setup? Also, how are you powering the HB25? ...is it adequate with the demand of the motors?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Greg Norton

Beau,

I have attached a schematic of my setup, I can provide pictures if you still think it is necessary. I am powering the whole setup from a benchtop power supply that should be able to deliver 3A at 12v. It is possible that the power supply is not handling the inrush current when the motor tries to start up, but I have yet to see currents above 2A when the motors are running. Usually when the power supply is overloaded, I can hear it click (ahem - not that I've ever shorted the power supply by accident ). There seems to be some kind or short circuit protection in there, which I don't hear when trying to run the motors. It will take me some time to come up with something more powerful to try it out.

Thanks for your help.

Greg

kwinn

It sounds like you are using a switching power supply. They will typically have high frequency dropouts when overloaded which will affect cpu's and other logic. Try separate power supplies (battery?) for the logic and the motor.

Mike Green

Chuck,
FullDuplexSerial's mode bit 2 is functionally the same as the Stamp's "open-mode". You might read through the chapter in the Stamp Manual on the SEROUT statement for some further discussion. Mostly this is used when you want to have a party line or otherwise share one I/O line. The Stamp or Propeller only switches the I/O pin to ground and makes use of a pull-up resistor to keep the I/O line at +Vdd idle. This allows several devices to share the line without destroying themselves by having one device switch the I/O pin to Vdd while some other device tries to switch the I/O pin to Vss.

Mike Green

Chuck,
Please start your own thread. It's unfair and confusing to Greg and others.

Greg,
I would start by putting short pauses (like: WAITCNT(CLKFREQ/1000+CNT)) after each byte transmitted. At 19.2KB, this would allow each character to be transmitted and a short pause between characters. I might even clear the receive buffer prior to the pause between transmitting the last character and trying to receive the reply. This would eliminate most timing problems and, hopefully, provide some more information to work on.

Greg Norton

Hello All,

I do appreciate all of the input from everyone. I made the following changes:

1. Changed bit 2 of the mode setting to 0 since I do not have a pull up resistor on the serial line.
2. I am now powering the propeller from a 9v battery, while the motor still runs from the power supply.
3. Added delays after transmitting of each byte and calling rxflush before attempting to receive as suggested by Mike.

The results now are a consistent hang on the first attempt to receive a byte. I can see through viewport that it is stuck where location := 1, it should switch to 2 if it receives anything at all.

  LOCATION := 1
  ARRIVED[noparse][[/noparse]0]:= serial.rx                                 ' See if we have arrived or not.  Loop until we have
  LOCATION := 2

The full code is attached.
I have an oscilloscope available to look at what's happening on the serial line, but I don't know what I'd be looking for at this point. Once again all suggestions are welcome.

Greg

Mike Green

Greg,
Would you please try again with Simple_Serial? I've attached a modified version of your last posting with my copy of Simple_Serial from the Object Exchange. Let me know what happens. I haven't tried to compile this myself, so please fix any minor errors.

Oh yeah. Please add a pull up resistor, maybe 10K or higher to +5V on the motor controller.

Greg Norton

Mike,

I added the pull up resistor and your code works perfectly. Looking at the changes you made it seems that delay is required between transmission of bytes, but not before or between receiving. Is that correct? I'm just trying to give myself a rule of thumb for creating future code. How did you know what was needed?

Once again, thanks very much for your help.

Greg

Mike Green

1) Because the I/O line is shared between receive and transmit and I know there's no pullup on the motor controller end, you needed a pullup resistor.

2) At the relatively high Baud (19.2KB), it's easy to get out of sync, particularly with a simple microprocessor at the motor controller end of things and with the use of Spin at the Propeller end for serial I/O. Adding a short pause between transmitted bytes helps that. You could try shortening the pause if you want. I'd probably try 500us, then 250us, then 100us. I left off the pause between transmit and receive because you want to listen to the I/O line as soon as possible. In this case, it doesn't matter too much because the motor controller is programmed to wait before sending its response and the default is around 500us if I remember correctly.

The pause between transmitted bytes was more important when FullDuplexSerial was used because the assembly I/O routine works at full speed and the bytes are transmitted one right after the other. The pause would allow the transmission to take place, then a short pause between bytes. With Simple_Serial, there would be a short pause anyway because of the time needed to return from the .tx call and do the next .tx call.

I think the pullup resistor was the main thing that made a difference.