Reply by tinkerdj ●January 18, 20052005-01-18

Thank you guys, i mean that. This is deffintly the direction i am
trying to take and starting small or slow for this isntance makes the
most sense. SO what i think i will do at this point is do like Rich
says and just get the pic responding to the program and sending the
apropriate commands then go from there. I was going to use Kellycam to
control everything but most likely am leaning towards Mach2. I will
build a pic877 board then go through the programing before i go any
father ahead. I was leaning towards a pic controller board running
seperate axis boards. I'll go through the archives here and see what i
can put together from other posts. Thank you for the info, as i am
still pretty new to pics its nice to see help is avaliable. --- In , "Phil" <phil1960us@y...> wrote:
>
> good points. especially on starting at a low rate to debug and human
> readable debug output.
>
> I'd suggest a different protocol encoding: with 8 bits, have a 2 bit
> "op code" and 3 2 bit axis pairs (one each for x, y and Z). One
> opcode would be step and each axis pair would be encoded as step +,
> step - and no step. This way, he could get 3 steps per byte, one on
> each axis. The other 3 op codes could be used for other axes, relay
> control, etc. One should probably be a query operation.
>
> If you encode the axis pair as a step and direction bit and assign
> your output pins in the right way, you can just slap the 6 bits from
> the protocol packet right into the output port with no bit twiddling.
> Of course you will need to return the step bits to 0 to set up for
> the next step pulse. The more you touch the data a) the slower your
> code will run and b) the more chance for errors. Speed may not be
> important right off the bat but it doesn't hurt to design it in from
> the beginning - I prefer to write my code once, not twice.
>
> Phil
>
> --- In , "rj_satterlee" <rj_satterlee@y...>
wrote:
> >
> > Hi-
> >
> > As Phil has already pointed out, you might want to give some thought
> > to a "serial format" byte wide serial communication.
> >
> > I might suggest that you start with RS232 and not get too involved
> > with USB just yet. It adds another layer of complexity that might
> > prove irritating.
> >
> > You might want to set up you own control protocol. For example
> > have the least significant bit be the axis control, the next
> > least significant the direction. Each byte would represent for
> > example a certian step in one direction for one axis. The rest
> > of the bits you can set up for error checking on the bits in
> > question.
> >
> > As an output, you might want to have the PIC respond to the
> > control PC with a status byte when the operation is complete.
> > Also you might want to have the limit and home switch settings
> > (debounced) in the status word as well.
> >
> > You will most likely have to pick apart your driver(s) and see
> > how they do the control. Most likely, since it's from the parallel
> > port, the drivers do most, if not all, of the direction and step
> > functions.
> >
> > I would suggest that you try to implement a fairly fast rs232 link
> > AFTER you get it running at a slow speed. Get the thing operational
> > then get the speed up, of the link.
> >
> > For examople a 19.2Kbaud byte can be transmitted in 500ns. Then
> > double that for the status returned, and you get about 1000
> > commands/status pairs. That should be fast enough to get you
> > running the steppers at pretty much flat out rate. But start
> > of testing with a slow link, like 1200 baud or so to get your
> > feet wet in serial communications.
> >
> > In fact, I would suggest setting up a "test case" where you can
> > just have the pic output characters, and feed them into a
> > hyperterminal link or minicom. There have been many articles on this
> > group on how to bring up a serial port. No need to reiterate it
> > here.
> >
> > Best of luck with the project.
> >
> > Cheers,
> >
> > Rich S.
> >




Reply by Phil ●January 18, 20052005-01-18

good points. especially on starting at a low rate to debug and human
readable debug output.

I'd suggest a different protocol encoding: with 8 bits, have a 2 bit
"op code" and 3 2 bit axis pairs (one each for x, y and Z). One
opcode would be step and each axis pair would be encoded as step +,
step - and no step. This way, he could get 3 steps per byte, one on
each axis. The other 3 op codes could be used for other axes, relay
control, etc. One should probably be a query operation.

If you encode the axis pair as a step and direction bit and assign
your output pins in the right way, you can just slap the 6 bits from
the protocol packet right into the output port with no bit twiddling.
Of course you will need to return the step bits to 0 to set up for
the next step pulse. The more you touch the data a) the slower your
code will run and b) the more chance for errors. Speed may not be
important right off the bat but it doesn't hurt to design it in from
the beginning - I prefer to write my code once, not twice.

Phil

--- In , "rj_satterlee" <rj_satterlee@y...> wrote:
>
> Hi-
>
> As Phil has already pointed out, you might want to give some thought
> to a "serial format" byte wide serial communication.
>
> I might suggest that you start with RS232 and not get too involved
> with USB just yet. It adds another layer of complexity that might
> prove irritating.
>
> You might want to set up you own control protocol. For example
> have the least significant bit be the axis control, the next
> least significant the direction. Each byte would represent for
> example a certian step in one direction for one axis. The rest
> of the bits you can set up for error checking on the bits in
> question.
>
> As an output, you might want to have the PIC respond to the
> control PC with a status byte when the operation is complete.
> Also you might want to have the limit and home switch settings
> (debounced) in the status word as well.
>
> You will most likely have to pick apart your driver(s) and see
> how they do the control. Most likely, since it's from the parallel
> port, the drivers do most, if not all, of the direction and step
> functions.
>
> I would suggest that you try to implement a fairly fast rs232 link
> AFTER you get it running at a slow speed. Get the thing operational
> then get the speed up, of the link.
>
> For examople a 19.2Kbaud byte can be transmitted in 500ns. Then
> double that for the status returned, and you get about 1000
> commands/status pairs. That should be fast enough to get you
> running the steppers at pretty much flat out rate. But start
> of testing with a slow link, like 1200 baud or so to get your
> feet wet in serial communications.
>
> In fact, I would suggest setting up a "test case" where you can
> just have the pic output characters, and feed them into a
> hyperterminal link or minicom. There have been many articles on this
> group on how to bring up a serial port. No need to reiterate it
> here.
>
> Best of luck with the project.
>
> Cheers,
>
> Rich S. >
> --- In , "tinkerdj" <tinkerdj@y...> wrote:
> >
> > > As you can see, I only populated 1 of the axis on the board.
> > > A lot of my friends teased me at work when I brought the little
> > > home project in because the circuit was all spread out and had
> > > "lots of room". Well, that's o.k. It's a prototype. So there!
> > >
> > > I cut in quite a bit of code from other projects to implement an
> > > RS232 interface to the critter. It's a lash up, but I can
> > > stick a hyperterminal in windoze or minicom in linux on the
> > > port and play with the operational code.
> > >
> > > This code was all done in assembly language (using the microchip
> > > assembler and much of the code was debugged using the free
> > > simulator).
> > >
> > > So, after this rambling I would suggest:
> > > 1. Read Jones, ebook and get an idea of what's available and
> > > how to hook them up.
> > > 2. Determine bed length and torque needed for router (Z axis?).
> > > 3. Design mechanical hardware.
> > > 4. Select stepper and zero index circuitry.
> > > 5. Design electronics.
> > > 6. Code "preliminary" code for PIC stepper controller and "play"
> > > with it until you are satisfied that your code acts as
> expected.
> > > 7. Design final low level code for stepper controller. Maybe sans
> > > a "final" interface from the computer.
> > > 8. Concurrently with steps 1-7, find a high level application that
> > > will meet your needs in laying out the foam cuts.
> > > 9. Determine an interface specification that will meet the needs
> > > of both the high level application software and the pic
> > > stepper controller software.
> > > 10."Cut in" the new intermediate code (into the PIC and maybe the
> > > PC) and verify that the linking sofware plays as expected.
> > > 11.Review the software design and desk check the finished
> > application.
> > > 12.Go cut foam!
> > >
> > > I hope that this leads to some insight on how I implemented it
> > > and how I would go about implementing your application. There
> > > are many ways to skin a cat, and I have just one of them.
> > >
> > > Hope this helps!
> > >
> > > Cheers,
> > >
> > > Rich S.
> >
> > Thanks Rich, I should have wrote in my original post that i already
> > have an operational, but not perfect router. I am using a cwtech
> board
> > as a driver. This board has been around since 94 and you can get the
> > plans off the interent and all the chips and parts cost less then
> > 40dollars. But the problem with most of the diy boards or designs
> out
> > there is that they all require the parallel port to funciton. Which
> is
> > a problem due to not being able to run under windows. As i'm in this
> > as a hobby to both learn and grow i really want to avoid buying any
> > prebuilt stuff. What i want to use the pic for is to control the
> > stepper driver and take its instructions from the serial or usb
> port.
> > Eventually my hope is to aslo incorporate a palm pilot or clone in
> as
> > a controller but this is way down the road. So i have a driver for
> the
> > steppers, several actually and am now trying to have the drivers
> > controlled by the pic. There are 2 inputs from the router to the
> pic,
> > one for limit and home switchs. Outputs from the pic to the driver,
> 1
> > for step, 1 for direction, 1 for enable for each axis. As well there
> > will need to be an output to turn on a relay to control the spindle
> or
> > in my case a really cheap dremil knockoff.
> > The pic then needs to be able to communicate with the host system
> > through a serial connection either with a max232 style chip for
> serial
> > connection or one of the newer usb style chips.
> > Now to my real question do i need to program the pic to do
> everything
> > or just to act as controller. This is were i don't really know what
> i
> > should do. As well i am just starting to get into programming. Thanx
> > for the reply's.



Reply by rj_satterlee ●January 18, 20052005-01-18

Hi-

As Phil has already pointed out, you might want to give some thought
to a "serial format" byte wide serial communication.

I might suggest that you start with RS232 and not get too involved
with USB just yet. It adds another layer of complexity that might
prove irritating.

You might want to set up you own control protocol. For example
have the least significant bit be the axis control, the next
least significant the direction. Each byte would represent for
example a certian step in one direction for one axis. The rest
of the bits you can set up for error checking on the bits in
question.

As an output, you might want to have the PIC respond to the
control PC with a status byte when the operation is complete.
Also you might want to have the limit and home switch settings
(debounced) in the status word as well.

You will most likely have to pick apart your driver(s) and see
how they do the control. Most likely, since it's from the parallel
port, the drivers do most, if not all, of the direction and step
functions.

I would suggest that you try to implement a fairly fast rs232 link
AFTER you get it running at a slow speed. Get the thing operational
then get the speed up, of the link.

For examople a 19.2Kbaud byte can be transmitted in 500ns. Then
double that for the status returned, and you get about 1000
commands/status pairs. That should be fast enough to get you
running the steppers at pretty much flat out rate. But start
of testing with a slow link, like 1200 baud or so to get your
feet wet in serial communications.

In fact, I would suggest setting up a "test case" where you can
just have the pic output characters, and feed them into a
hyperterminal link or minicom. There have been many articles on this
group on how to bring up a serial port. No need to reiterate it
here.

Best of luck with the project.

Cheers,

Rich S.
--- In , "tinkerdj" <tinkerdj@y...> wrote:
>
> > As you can see, I only populated 1 of the axis on the board.
> > A lot of my friends teased me at work when I brought the little
> > home project in because the circuit was all spread out and had
> > "lots of room". Well, that's o.k. It's a prototype. So there!
> >
> > I cut in quite a bit of code from other projects to implement an
> > RS232 interface to the critter. It's a lash up, but I can
> > stick a hyperterminal in windoze or minicom in linux on the
> > port and play with the operational code.
> >
> > This code was all done in assembly language (using the microchip
> > assembler and much of the code was debugged using the free
> > simulator).
> >
> > So, after this rambling I would suggest:
> > 1. Read Jones, ebook and get an idea of what's available and
> > how to hook them up.
> > 2. Determine bed length and torque needed for router (Z axis?).
> > 3. Design mechanical hardware.
> > 4. Select stepper and zero index circuitry.
> > 5. Design electronics.
> > 6. Code "preliminary" code for PIC stepper controller and "play"
> > with it until you are satisfied that your code acts as
expected.
> > 7. Design final low level code for stepper controller. Maybe sans
> > a "final" interface from the computer.
> > 8. Concurrently with steps 1-7, find a high level application that
> > will meet your needs in laying out the foam cuts.
> > 9. Determine an interface specification that will meet the needs
> > of both the high level application software and the pic
> > stepper controller software.
> > 10."Cut in" the new intermediate code (into the PIC and maybe the
> > PC) and verify that the linking sofware plays as expected.
> > 11.Review the software design and desk check the finished
> application.
> > 12.Go cut foam!
> >
> > I hope that this leads to some insight on how I implemented it
> > and how I would go about implementing your application. There
> > are many ways to skin a cat, and I have just one of them.
> >
> > Hope this helps!
> >
> > Cheers,
> >
> > Rich S.
>
> Thanks Rich, I should have wrote in my original post that i already
> have an operational, but not perfect router. I am using a cwtech
board
> as a driver. This board has been around since 94 and you can get the
> plans off the interent and all the chips and parts cost less then
> 40dollars. But the problem with most of the diy boards or designs
out
> there is that they all require the parallel port to funciton. Which
is
> a problem due to not being able to run under windows. As i'm in this
> as a hobby to both learn and grow i really want to avoid buying any
> prebuilt stuff. What i want to use the pic for is to control the
> stepper driver and take its instructions from the serial or usb
port.
> Eventually my hope is to aslo incorporate a palm pilot or clone in
as
> a controller but this is way down the road. So i have a driver for
the
> steppers, several actually and am now trying to have the drivers
> controlled by the pic. There are 2 inputs from the router to the
pic,
> one for limit and home switchs. Outputs from the pic to the driver,
1
> for step, 1 for direction, 1 for enable for each axis. As well there
> will need to be an output to turn on a relay to control the spindle
or
> in my case a really cheap dremil knockoff.
> The pic then needs to be able to communicate with the host system
> through a serial connection either with a max232 style chip for
serial
> connection or one of the newer usb style chips.
> Now to my real question do i need to program the pic to do
everything
> or just to act as controller. This is were i don't really know what
i
> should do. As well i am just starting to get into programming. Thanx
> for the reply's.



Reply by Phil ●January 18, 20052005-01-18

--- In , "tinkerdj" <tinkerdj@y...> wrote:
...
>
> Thanks Rich, I should have wrote in my original post that i already
> have an operational, but not perfect router. I am using a cwtech board
> as a driver. This board has been around since 94 and you can get the
> plans off the interent and all the chips and parts cost less then
> 40dollars. But the problem with most of the diy boards or designs out
> there is that they all require the parallel port to funciton. Which is
> a problem due to not being able to run under windows. As i'm in this
> as a hobby to both learn and grow i really want to avoid buying any
> prebuilt stuff. What i want to use the pic for is to control the
> stepper driver and take its instructions from the serial or usb port.
> Eventually my hope is to aslo incorporate a palm pilot or clone in as
> a controller but this is way down the road. So i have a driver for the
> steppers, several actually and am now trying to have the drivers
> controlled by the pic. There are 2 inputs from the router to the pic,
> one for limit and home switchs. Outputs from the pic to the driver, 1
> for step, 1 for direction, 1 for enable for each axis. As well there
> will need to be an output to turn on a relay to control the spindle or
> in my case a really cheap dremil knockoff.
> The pic then needs to be able to communicate with the host system
> through a serial connection either with a max232 style chip for serial
> connection or one of the newer usb style chips.
> Now to my real question do i need to program the pic to do everything
> or just to act as controller. This is were i don't really know what i
> should do. As well i am just starting to get into programming. Thanx
> for the reply's.

Its not clear to me what you mean by "do everything or act as a
controller". You do have to do everything to act as a controller!

If it were me doing this, I would start by defining a protocol between
your host machine and the controller. The problem you will run into
is that the serial interface is fairly slow so you will want to keep
your protocol compact. I'd try to set it up so a single byte would
convey at least one step on at least one axis, maybe more. Because
serial can have errors, you should add some level of error checking.
Maybe use parity. You'll need to understand how the G Code
interpreter outputs it's step commands. (TurboCNC doesn't support
serial or USB, what would you be using?) Also, you'll need to define
some sort of response from the controller to the PC (limit switches,
for example).

Once you have defined the protocol, assign the output pins on your
controller to the actual stepper input pins. Now all that is left is
to write the code that takes the serial command and flips the bits on
the stepper pins.

The controller code is reasonably simple. I think your bigger
challenge will be getting good stepper speeds. With a good, compact
protocol and running at 115.2Kbaud, you will get, best case, around
10K steps per second. So anything in your protocol that requires
multiple bytes really slows you down. If you are microstepping, it
gets even slower, of course. Moving to USB is probably the right
direction for more speed but I'm not sure what the overhead is going
to be on the PIC side.

This assumes that you aren't implementing timing or G Code
interpretation in the controller. That's a whole different ball game.

Phil



Reply by tinkerdj ●January 18, 20052005-01-18

> As you can see, I only populated 1 of the axis on the board.
> A lot of my friends teased me at work when I brought the little
> home project in because the circuit was all spread out and had
> "lots of room". Well, that's o.k. It's a prototype. So there!
>
> I cut in quite a bit of code from other projects to implement an
> RS232 interface to the critter. It's a lash up, but I can
> stick a hyperterminal in windoze or minicom in linux on the
> port and play with the operational code.
>
> This code was all done in assembly language (using the microchip
> assembler and much of the code was debugged using the free
> simulator).
>
> So, after this rambling I would suggest:
> 1. Read Jones, ebook and get an idea of what's available and
> how to hook them up.
> 2. Determine bed length and torque needed for router (Z axis?).
> 3. Design mechanical hardware.
> 4. Select stepper and zero index circuitry.
> 5. Design electronics.
> 6. Code "preliminary" code for PIC stepper controller and "play"
> with it until you are satisfied that your code acts as expected.
> 7. Design final low level code for stepper controller. Maybe sans
> a "final" interface from the computer.
> 8. Concurrently with steps 1-7, find a high level application that
> will meet your needs in laying out the foam cuts.
> 9. Determine an interface specification that will meet the needs
> of both the high level application software and the pic
> stepper controller software.
> 10."Cut in" the new intermediate code (into the PIC and maybe the
> PC) and verify that the linking sofware plays as expected.
> 11.Review the software design and desk check the finished
application.
> 12.Go cut foam!
>
> I hope that this leads to some insight on how I implemented it
> and how I would go about implementing your application. There
> are many ways to skin a cat, and I have just one of them.
>
> Hope this helps!
>
> Cheers,
>
> Rich S.

Thanks Rich, I should have wrote in my original post that i already
have an operational, but not perfect router. I am using a cwtech board
as a driver. This board has been around since 94 and you can get the
plans off the interent and all the chips and parts cost less then
40dollars. But the problem with most of the diy boards or designs out
there is that they all require the parallel port to funciton. Which is
a problem due to not being able to run under windows. As i'm in this
as a hobby to both learn and grow i really want to avoid buying any
prebuilt stuff. What i want to use the pic for is to control the
stepper driver and take its instructions from the serial or usb port.
Eventually my hope is to aslo incorporate a palm pilot or clone in as
a controller but this is way down the road. So i have a driver for the
steppers, several actually and am now trying to have the drivers
controlled by the pic. There are 2 inputs from the router to the pic,
one for limit and home switchs. Outputs from the pic to the driver, 1
for step, 1 for direction, 1 for enable for each axis. As well there
will need to be an output to turn on a relay to control the spindle or
in my case a really cheap dremil knockoff.
The pic then needs to be able to communicate with the host system
through a serial connection either with a max232 style chip for serial
connection or one of the newer usb style chips.
Now to my real question do i need to program the pic to do everything
or just to act as controller. This is were i don't really know what i
should do. As well i am just starting to get into programming. Thanx
for the reply's.




Reply by Allan Lane ●January 7, 20052005-01-07

Yup, I've used "Stallion" terminal servers
in this instance -- 16 ports, and software
(on Windows NT 4.0) that lets them all look
like local serial ports.

However, his application looks like merely
switching a single monitor port among 16
possible ports. Much simpler than a
Terminal Server.

--- In , Mr S <szinn_the1@y...> wrote:
> A 16 port terminal server and a telnet client sounds
> much cheaper and easier than any serial hardware
> development?
> It would add the functionality of simultaneous
> connections from a PC and allow connection remotely
> across the intranet or Internet even.
>
> Just a thought
>
> --- Allan Lane <allan.lane@h...> wrote:
>
> >
> >
> > A simple 'brute-force' design would be to have
> > 16 74LS154s as 'destination selectors'. Port 1's
> > RX signal would be routed to input #1 of each
> > '154. Then each '154 would have a 4-bit latch for
> > it's selection value. A single PIC would latch in
> > the selection value when commanded.
> >
> > The 'output' of each '154 would then be
> > routed to a MAX232, and then to the 'TX' pin.
> >
> > And you'd want each RX signal to come through a
> > MAX232 also.
> >
> > Yes, this sounds like it could work. Doing all
> > 8 control signals multiplies the number of '154s
> > you'll need, though.
> >
> >
> > --- In , "Kevin Van Winkle"
> > <kvwinkle@h...>
> > wrote:
> > > Hi all-
> > >
> > > This is not exactly a PIC question per se, but
> > there is one
> > involved:
> > >
> > > I want to make a 16 port rs-232 switch, using a
> > PIC (completely non-
> > critical
> > > as to the model, and this is even doable with out
> > a pic, but allows
> > me to do
> > > scan and display functions) and a 74LS154 (BCD to
> > 1 of 16), so 4
> > lines run
> > > the switching, I have some left overs for display
> > and buttons.
> > >
> > > Actually switching RS-232, can I do it directly
> > with transitors, or
> > (my
> > > guess) give each port it's own max232 style line
> > driver and switch
> > behind
> > > that?
> > >
> > > I need to switch 8 lines on each port (via RJ45,
> > the datalines and
> > the
> > > signals), doing this mechanically with relays is
> > not a good idea.
> > 8PDT's
> > > are really expensive and not all that elegant, on
> > the order or $20
> > each in
> > > the Mouser or Digikey worlds times 16 ports [stuck
> > with pre-
> > approved vendors
> > > on this one.])
> > >
> > > The good news this is for VAX, which really is not
> > rs-232 as the
> > voltages
> > > are a bit higher so the the drop across the
> > junction should go un-
> > noticed if
> > > I just did it in a crude, direct switching manner.
> > Even with the
> > VAXen's
> > > quirks, it'll talk to PC RS-232 fine directly.
> > >
> > > I know Blackbox makes these things, they are out
> > of production (the
> > ones we
> > > use, I have 3) and refurbs are on the order of
> > $1600, I'm thinking
> > this is
> > > doable using all new bits for around $150 w/
> > enclosure. Any input
> > (no pun
> > > intended)?
> >
> >
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > --------------------~-->
> > Make a clean sweep of pop-up ads. Yahoo! Companion
> > Toolbar.
> > Now with Pop-Up Blocker. Get it for free!
> >
> http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dN_tlB/TM
> >
> -------------------------------
-~->
> >
> >
> > to unsubscribe, go to http://www.yahoogroups.com and
> > follow the instructions
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> > __________________________________________________
>



Reply by Mr S ●January 7, 20052005-01-07
A 16 port terminal server and a telnet client sounds
much cheaper and easier than any serial hardware
development?
It would add the functionality of simultaneous
connections from a PC and allow connection remotely
across the intranet or Internet even.

Just a thought

--- Allan Lane <> wrote:

>
>
> A simple 'brute-force' design would be to have
> 16 74LS154s as 'destination selectors'. Port 1's
> RX signal would be routed to input #1 of each
> '154. Then each '154 would have a 4-bit latch for
> it's selection value. A single PIC would latch in
> the selection value when commanded.
>
> The 'output' of each '154 would then be
> routed to a MAX232, and then to the 'TX' pin.
>
> And you'd want each RX signal to come through a
> MAX232 also.
>
> Yes, this sounds like it could work. Doing all
> 8 control signals multiplies the number of '154s
> you'll need, though. > --- In , "Kevin Van Winkle"
> <kvwinkle@h...>
> wrote:
> > Hi all-
> >
> > This is not exactly a PIC question per se, but
> there is one
> involved:
> >
> > I want to make a 16 port rs-232 switch, using a
> PIC (completely non-
> critical
> > as to the model, and this is even doable with out
> a pic, but allows
> me to do
> > scan and display functions) and a 74LS154 (BCD to
> 1 of 16), so 4
> lines run
> > the switching, I have some left overs for display
> and buttons.
> >
> > Actually switching RS-232, can I do it directly
> with transitors, or
> (my
> > guess) give each port it's own max232 style line
> driver and switch
> behind
> > that?
> >
> > I need to switch 8 lines on each port (via RJ45,
> the datalines and
> the
> > signals), doing this mechanically with relays is
> not a good idea.
> 8PDT's
> > are really expensive and not all that elegant, on
> the order or $20
> each in
> > the Mouser or Digikey worlds times 16 ports [stuck
> with pre-
> approved vendors
> > on this one.])
> >
> > The good news this is for VAX, which really is not
> rs-232 as the
> voltages
> > are a bit higher so the the drop across the
> junction should go un-
> noticed if
> > I just did it in a crude, direct switching manner.
> Even with the
> VAXen's
> > quirks, it'll talk to PC RS-232 fine directly.
> >
> > I know Blackbox makes these things, they are out
> of production (the
> ones we
> > use, I have 3) and refurbs are on the order of
> $1600, I'm thinking
> this is
> > doable using all new bits for around $150 w/
> enclosure. Any input
> (no pun
> > intended)? > ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Make a clean sweep of pop-up ads. Yahoo! Companion
> Toolbar.
> Now with Pop-Up Blocker. Get it for free!
>
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/dN_tlB/TM
>
--------------------------------~->
>
>
> to unsubscribe, go to http://www.yahoogroups.com and
> follow the instructions
> Yahoo! Groups Links >


__________________________________________________
Reply by Phil ●January 6, 20052005-01-06

--- In , "rtstofer" <rstofer@p...> wrote:
...
> The way I see it, debouncing is intrinsic in the transition state
> table. Bounces, or illegal transitions, can be ignored as long as
> they involve just one bit. If there is so much slop in the system
> that both bits can bounce around then all bets are off but I
> wouldn't expect that to be the case when the encoder is internal.

I've gutted several old MS mice for their ALPS encoders. Really
bouncy little beasts. Single switch bounces look like double (or 2*N)
reversals so it works out ok. Only one switch will change at a time
so it works. However, he was just counting clicks, not keeping tally
of CW vs CCW events. I like to use the CW or CCW to add/subtract from
the direction "score" to desensitize direction detection. Especially
if you're going to do something based on a change of direction.

Phil



Reply by rtstofer ●January 6, 20052005-01-06


If it is true quadrature, the sequence should be

A=0 B=0 ; maybe this is the sequence for FORWARD
A=1 B=0
A=1 B=1
A=0 B=1

A=0 B=0
...
OR

A=0 B=0 ; and this for REVERSE or vice versa
A=0 B=1
A=1 B=1
A=1 B=0

A=0 B=0
...

Now, if you know that you are driving the motor in a direction that
should yield these transitions then debouncing is not an issue.

For example, going FORWARD A=0 B=0 transitions to A=1 B=0. The only
legal next transition is A=1 B=1 so a bounce back to A=0 B=0 should
be ignored unless the direction of rotation has been changed. Your
program logic should implement a state machine that will only follow
legal transitions but this is easy: you know what state you are in
and you know what transition will move you to the next state and
everything else that happens is ignored.

The way I see it, debouncing is intrinsic in the transition state
table. Bounces, or illegal transitions, can be ignored as long as
they involve just one bit. If there is so much slop in the system
that both bits can bounce around then all bets are off but I
wouldn't expect that to be the case when the encoder is internal.

I only tried interrupt on change once and I wasn't happy with the
result. I had an alternate strategy so I didn't bother to pursue
the issue. Maybe you should wander over to the Microchip site and
see if they have app notes on the subject. I'll bet they do...

If it can be accomplished, interrupts are the way to go. --- In , Peter van Hoof <pvhoof@y...> wrote:
> If you can afford to give up in resolution there is a
> way you can get rid of bounce and probably noise as
> well
>
> -Set a bit in memory is (A is high AND B is low)
> -Reset this bit if(A is low AND B is high)
> -Increment your position counter when setting the bit
> if its previous value was 0
> -Increment your position counter when resetting the
> bit if its previous value was 1
>
> The fact that both bits have to be opposite eliminates
> lots of the noise
>
> The fact that you throw away two of the four states
> and react on the edge of the other two eliminates
> bounce (at least at low speed)
>
> This will cost you half your resolution but may help
> you on your way. even if half the resolution is not
> acceptable you might learn more from the experiment. > Peter
>
> --- cjl023 <cjl023@y...> wrote:
>
> >
> > Peter,
> >
> > Just count pulses.
> >
> > Determining direction and speed is not critical to
> > the application
> > at all.
> >
> > Thanks.
> >
> > Take Care,
> >
> > --- In , Peter van Hoof
> > <pvhoof@y...> wrote:
> > > Do you do a true quadrature detect or do you just
> > > count pulses?
> > >
> > > In a true qudrature setup bounce would probably
> > not be
> > > such a big problem at such a slow speed it would
> > > probably just introduce a 1 bit jitter.
> > >
> > > Peter



Reply by Peter van Hoof ●January 6, 20052005-01-06
If you can afford to give up in resolution there is a
way you can get rid of bounce and probably noise as
well

-Set a bit in memory is (A is high AND B is low)
-Reset this bit if(A is low AND B is high)
-Increment your position counter when setting the bit
if its previous value was 0
-Increment your position counter when resetting the
bit if its previous value was 1

The fact that both bits have to be opposite eliminates
lots of the noise

The fact that you throw away two of the four states
and react on the edge of the other two eliminates
bounce (at least at low speed)

This will cost you half your resolution but may help
you on your way. even if half the resolution is not
acceptable you might learn more from the experiment. Peter

--- cjl023 <> wrote:

>
> Peter,
>
> Just count pulses.
>
> Determining direction and speed is not critical to
> the application
> at all.
>
> Thanks.
>
> Take Care,
>
> --- In , Peter van Hoof
> <pvhoof@y...> wrote:
> > Do you do a true quadrature detect or do you just
> > count pulses?
> >
> > In a true qudrature setup bounce would probably
> not be
> > such a big problem at such a slow speed it would
> > probably just introduce a 1 bit jitter.
> >
> > Peter