BasicMicro - Forums

I have exchausted my search of the forums to find threads specific to this topic and am humbly reaching out for assistance. I am a noob, and finally decided to reach out on the forum.

Configuration:
Atom Pro (microcontroller)
Robo Claw (motor controller)
Two Quadrature Encoders mounted to geared motors
Track Drive System
Packet Serial (DIP set for packet serial and Robo Claw at address 128; ie SW=3,4, and 5 are on)
S1 (Robo Claw) connected to P15 (TX on microcontroller) w/ GND only
S2 (Robo Claw) connected to P14 (RX on microcontroller) w/ GND only
Right Encoder connected to header (A and B) for encoder 1 on Robo Claw w/ GND and +5V
Left Encoder connected to header (A and B) for encoder 2 on Robo Claw w/ GND and +5V

I have successfully used the SEROUT (P15) to control the motors, but am having difficulty integrating HERSOUT/HERSIN to integrate the encoders.

Goal:
Control motors and read encoders to terminal and eventually 7-segment display.

Sample Code:
Encoder1 Var Long
Encoder 2 Var Long
Status Var Byte
CRC Var Byte

Enablehserial

Pause 250

SetHSerial H38400, H8DATABITS, HNOPARITY, H1STOPBITS

Hserout [128, 20, (148 & 0x7F)]

Main

Serout P15, i38400, [128, 0, 32, (160 & 0x7F)]; motor1 forward
Serout P15, i38400, [128, 0, 32, (160 & 0x7F)]; motor2 forward

ReadEncoderM1
Hserout [128, 16]
Hserin [Encoder1.byte3, Encoder1.Byte2, Encoder1.Byte1, Encoder1.Byte0, Status, crc]
Serout s_out, i38400, [0,”Encoder1: “, SDEC Encoder1, 13, “Status Byte: “, BIN Status]

ReadSpeedM1
Hserout [128, 18]
Hserin [Encoder1.byte3, Encoder1.Byte2, Encoder1.Byte1, Encoder1.Byte0, Status, crc]
Serout s_out, i38400, [13, 13, “Speed: “, DEC Encoder1, 13, “Direction: “, DEC Status]

ReadEncoderM2
Hserout [128, 17]
Hserin [Encoder1.byte3, Encoder1.Byte2, Encoder1.Byte1, Encoder1.Byte0, Status, crc]
Serout s_out, i38400, [0,”Encoder1: “, SDEC Encoder1, 13, “Status Byte: “, BIN Status]

ReadSpeedM2
Hserout [128, 19]
Hserin [Encoder1.byte3, Encoder1.Byte2, Encoder1.Byte1, Encoder1.Byte0, Status, crc]
Serout s_out, i38400, [13, 13, “Speed: “, DEC Encoder1, 13, “Direction: “, DEC Status]

Goto Main

Kurt and Nathan have posted on the roboclaw commands. You might consider using the library of roboclaw commands that Nathan worked out.

Kurt has posted:



Which I'm gonna try as soon as I can get my encoders cabled up!

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

I found Nathan and Kurt's relevant posts. Thank you for steering me right. I will review them and continue.

Can you clarify if the serout and hserout commands can both use pin 15 (or pin 14) within the same program?

Does sending a serout command to pin 15 (or pin 14) conflict with the hserout using that same TX pin (or RX pin)?

Ultimately, I am comfortable using any either or both commands, but I am concerned adding PS2 control and 7-segment will dictate what to use. I have working code for each function (differential movement, 7-segment display, PS2), but intergrating them together is posing a unique challenge and tremendous learning experience.

I have removed the wireless PS2 from the BotBoardII to simplify testing of the motors and encoders. I hope to renintroduce the joystick contorol after I get the encoders and motors functioning together.

Thanks again!

I don't know what would happen if you did a serout to P14 after you initialized the hardware serial port... It would work before then. I am not sure why you would want to...

Now if you are asking can you do serouts on other IO pins while hserial is active, that is always an interesting question. That is HSERIAL uses interrupts which for sure if its interrupt happens and you are doing a bitbang serout at a higher baud rate, it is likely your output will be messed up. If your bit bang is at a low enough baud rate you usually can get reasonable results. Some of my programs use HSERIAL for XBEES and I have added the RTS line from the XBEE where I can tell it not to send anything. I then wait until the output queue is empty and then I can do high speed communications to things like a robowclaw or SSC-32... I use this approach for my Phoenix and ...

As for PS2 control. On some of my BB2s I have been able to get the PS2 to work on pins 0-3 with the built-in pull-up resistor. On others I have had to add my own pull-up...

Not sure if I answered your question or not...

Kurt

No, I can't confirm using both hserout and serout on the same pin. I think I had trouble just using both at the same time. Not sure why you would want to. Also, interrupt driven I/O can trash the timing of bit-bang I/O. Kurt has posted considerably on this topic. 7-segment shouldn't be affected (although I haven't tested), but again PS2 is bit-bang. I suppose one could turn off interrupts while the PS2 *waits* for its input...

Alan KM6VV

_________________
Visit:
http://groups.yahoo.com/group/SherlineCNC/
http://tech.groups.yahoo.com/group/HexapodRobotIK/

Yep, I have run into it many times with serouts...

The good news is for the most part I have not had many problems with the PS2 with interrupts. As the PS2 is more or less a SPI interface where it is driven by the clock signal, which we control, so if one clock is a little slower it usually does not matter...

Kurt

Based on your feedback and current system behavior, I am focused on sending/receiving commands through the hserout with no serout commands.

The following code results in proper motor control, but the 'speed' and 'check crc' output zero each cycle.

Encoder1 var long
Sts var byte
CRC var byte
CheckCRC var byte
Address var byte
Speed var byte
Command var byte

Clear

ENABLEHSERIAL

SetHSerial H38400, H8DATABITS, HNOPARITY, H1STOPBITS

Address = 128
Speed = 32

Main

Pause 1000 'Let Processor Stabilize

Command = 20
CRC = (Address + Command) & 0x7f
hserout [Address, Command, CRC] 'Clear Encoders

Pause 1000

Command = 0
CRC = (Address + Command + Speed) & 0x7f
hserout [Address, Command, Speed, CRC] 'forward M1

Command = 4
CRC = (Address + Command + Speed) & 0x7f
hserout [Address, Command, Speed, CRC] 'forward M2

Pause 1000

Command = 19 'Get encoder speed M2
hserout [Address, Command]
hserin [Encoder1.byte3, Encoder1.Byte2, Encoder1.Byte1, Encoder1.Byte0, Sts, crc]
serout s_out, i38400, [0, "Speed ", dec10 Encoder1, 13, "Check CRC ", dec3 CheckCRC, 13, 13]

Goto Main

Correction to prevous post:

In order to first integrate motor control and encoders, I am using hserout and hserin to communicate with the Robo Claw instead of serout to test. I do use the serout to output.

Still no encoder ouput besides Speed =0 and Check CRC = 0.

Is there another way to test if the encoders are functioning? Multimeter? Other send/receive test command?

One of the first things I would do is to maybe send out a request packet to get the version and receive and print it (p38 data sheet). That will say for sure your bidirectional communications is working properly...

FYI - I fried both encoders in my first attempt as things were not working and I thought I had the wires backwords and swapped them... And hooked up - to + and + to -...

I used commands 16 and 17 to read the counters for my testing. I also used my logic analyzer to see the signals coming off of the encoder. I use the analyzer far more often than I ever would have imagined... If I did not have this, I would have probably tried disconnecting the encoder inputs from the robo-claw and hooked them up to my BAP with at least one output on interrupt enabled lines, I would then setup an interrupt handler that maybe toggles an LED on the board, so I can see if I am receiving anything from it... This is what I did before the roboclaw...

Kurt

With encoders you can use a multimeter to check them if you turn the wheels VERY slowly. You should see the encoder pins go from 0 to 5v and back again as you very slowly turn the wheel.

I do suggets you change yout test program. Just send a speed command to the motors before your main loop and then only read the encoders in the main loop. Obviously do this after double checking the encoders are doing something.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

I am looking into a logic analyzer (looks fun). I have a bad feeling the encoders are fried. I turned the encoders VERY slowly there was no detectable change in the Voltage (not 0V to 5V). I ordered two more encoders and expect to be more careful in the future.

The RoboClaw data sheet (p10) seems to indicate a test of the encoder's function is initiated at powerup. When I power up the RoboClaw, the Error LED and Status LED come on at the same time and then turn off. Is that consistent with the error description from page 10?

"Quad Decoder Fail = Error LED and Status LED 2 alternate blink on start up"

I sent the request command for the version, but had to guess at the syntax (see below) of the serout command for viewing in a terminal window. With this code, I see "Roboclaw" for a split second followed by meaningless characters. I am not sure if the result is sufficient to know if the the BB2 is receiving GOOD data from the RoboClaw. I am not sure if the result is bad data or bad syntax.

Version Request:
Hserout [128, 21]
Hserin [Str VersionByte\32\0, CRC]
Serout s_out, i38400, [Str VersionByte] <-- ?

I know that feeling!

try:
Serout s_out, i38400, [Str VersionByte\32\0, 13]
It will output up to 32 bytes, end when it sees a 0 value and not output it and then outputs the CR...
This assumes that VersionByte is defined as an array of at least 32 bytes...

Kurt

The code worked!! Thank you. The "Roboclaw..." has minor character fluctations, but generally the string is complete. I am not sure if the minor character anomolies are normal or can be eliminated.

I regret that I didn't head your experience with frying them out, sooner. I recall reading one of your posts about burning them out, but I am sure I got careless during one of the late nights.

The attached file (encoder_test.bas) is draft code for eventual testing of encoders. I have some command commented out to simplify testing. The code returns the bits of the Status Byte.

Encoder1: 0
Status Byte: 10000000

Encoder2: 0
Status Byte: 10000000

The 7th bit on the Status Byte is zero. The manual says that means the Encoder is FAIL and not OK. Further evidence of fried encoders? I do not know if I can trust the result to know if the 7th bit is good info.

To clarify, on the Roboclaw there is a seperate chip that handles quad decoding. Communications to that chip is what is being checked. We can't detect if encoders are attached to the roboclaw. We can only detect that the decoder chip is functioning correctly.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved

Ok. Good to know. Thank you.

Do you think the 7th bit of the status byte is returning correctly (0 = Fail)? If so, that mean it is reporting an underflow in the 1st bit.