Wednesday, August 30, 2006

 

Things get a little complicated...

Had my first shot at getting speed control (without shaft encoder feedback) rolling. Seems to work okay. Can't test out the two working in concert, though, till I've got two motors.

Pololu said that I should get mine by Saturday, so this weekend... :-)

The big change in the programming approach is that I'm not changing numbers to ASCII strings when I send them over any more. That cuts the length of the message that I have to transmit and receive way down. When I get to having to receiving Word and Long variables, though, I am going to have to write a bit of VB code to interpret them since as best as I can see the PIC chips don't understand what is meant by representing a negative integer by two's complementing it.

Comments:
Only problem I see is when hypothetically setting the speed to ascii "{" and "}"

Maybe just have a control byte (say 128) followed by 2 sequential motor speed bytes. Optional closing byte if we want to get fancy.

For other options, like extruder controls, z axis, etc, you use different control bytes to trigger that mode in the PIC.
 
The format that I'm using is an ad hoc holdover from the old programme on the 16f628A. What I am probably going to do is to either have fixed length messages or have the length determined by a lookup table in the PIC that reads a three letter ID that leads the message.
 
*** as best as I can see the PIC chips don't understand what is meant by representing a negative integer by two's complementing it ***

What do you mean by this? Are you sure you're not losing the high bit because of serial line settings? The magic of 2's compliment numbers is that unless you are doing overflow detection or multiplication, they are the same as unsigned integers.

In terms of packets, what's wrong with just having a single byte command, and argument length and/or format depending on the command?

I'm thinking for my initial approach, I might write a general purpose controller program that can translate XML into serial line binary data, and turn serial line binary data into XML fragments for display. Should make it a little easier to write test programs with the integrated XML stuff in .NET. I'm not sure yet, though. Need to get serial up on my chips first (not finding a lot of time to do it yet.)
 
Sounds like a good approach.
 
Post a Comment

Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?

Subscribe to
Posts [Atom]