Re: RE: PIC based DRO
Posted by
beer@s...
on 2000-03-15 08:48:06 UTC
On 15 Mar, CAD_CAM_EDM_DRO@onelist.com wrote:
language that "cross-cross assembles" down to native PIC code. Being a
longtime Intel programmer of both 8051s and x86s, I just never could
get the hang of PIC mnemonics. And unlike a compiled language, the
resulting program is NO bigger.
enough to add a keypad, I suppose, but I can't think of when I'd want
one often enough to bother with.
However, never having used a DRO, my opinion may change. I was simply
thinking about how I use the dials on my cranks, and all I really do is
this.
Read them.
Reset them to zero.
Calculate how far I've moved from the last time I zeroed them.
end ! <G> Until then, silence is my current choice.
could EVER be moved fast enough to cause the PIC to lose count. I
forget exactly what the top end is of my counter scheme, but I did
calculate it out once it was hundreds of feet per second, for inches
per minute didn't seem like a problem.
The ERROR testing was added to test the quality of the signal. For any
given quadrature state, there are two other states that are legal and
one that is not allowed. For example, from a 11 state, 10 is legal and
01 is legal, but 00 is not.
Purely digital decoders ( like those from HP or USDigital ) DO NOT
TAKE THIS INTO ACCOUNT and therefore have no way of determining if a
strip/codewheel is bad.
Once in the 11 state, they will sit there and wait for a 10 or a 01
state, ignoring a "bad" 00 state, should one occur. IF a 00 state
occurs followed by a 10 or 01, the digital chips will increment or
decrement their count by one. However, the 00 state in the middle
means that there has actually been at LEAST three counts occur and
very likely more.
This became a cause for concern when looking at my Goldmine codewheels.
Handling one with my fingers left enough oil in the slots to cause
quadrature problems ! I didn't bend it, I just touched it, and that's
the result.
It seemed to me that error checking was a needed idea.
is CRANK ROTATION. It does not read table movement.
To that end, they have a codewheel added to the leadscrews and IIRC, a
custom made optical assembly.
BTW, this info comes from the dim recesses of failing memory, so no
quotes please. However, I think I got it from the fellow ( whose name
escapes me ) who actually designed the product and was quite
forthcoming about all the details. I quite like that in a company. I
may have to buy one of these Sherlines one day.
problem is not yet solved, I'm reluctant to do so until I do have a
working unit.
Alan
--
Alan Rothenbush | The Spartans do not ask the number of the
Academic Computing Services | enemy, only where they are.
Simon Fraser University |
Burnaby, B.C., Canada | Agix of Sparta
> Message: 9It was written in Parallax/Tech-Tools assembly. This is an 8051-like
> Date: Tue, 14 Mar 2000 23:01:25 -0500
> From: Paul Devey <paul_devey@...>
> Subject: RE: PIC based DRO
>
> What language/compiler/assembler did you use?
language that "cross-cross assembles" down to native PIC code. Being a
longtime Intel programmer of both 8051s and x86s, I just never could
get the hang of PIC mnemonics. And unlike a compiled language, the
resulting program is NO bigger.
> Simple key/keyboard input I presume?No, NO input device of any type, EXCEPT for two reset pushbuttons. Easy
enough to add a keypad, I suppose, but I can't think of when I'd want
one often enough to bother with.
However, never having used a DRO, my opinion may change. I was simply
thinking about how I use the dials on my cranks, and all I really do is
this.
Read them.
Reset them to zero.
Calculate how far I've moved from the last time I zeroed them.
> I am sure many on this list may benefit from any of your experience. I knowWell, once I've actually got a working scale, I'll likely brag to no
> I would appreciate hearing about it.
end ! <G> Until then, silence is my current choice.
> [Paul Devey]The ERROR output seemed important to me. It is unlikely that a machine
> I like non-cryptic messaging.
could EVER be moved fast enough to cause the PIC to lose count. I
forget exactly what the top end is of my counter scheme, but I did
calculate it out once it was hundreds of feet per second, for inches
per minute didn't seem like a problem.
The ERROR testing was added to test the quality of the signal. For any
given quadrature state, there are two other states that are legal and
one that is not allowed. For example, from a 11 state, 10 is legal and
01 is legal, but 00 is not.
Purely digital decoders ( like those from HP or USDigital ) DO NOT
TAKE THIS INTO ACCOUNT and therefore have no way of determining if a
strip/codewheel is bad.
Once in the 11 state, they will sit there and wait for a 10 or a 01
state, ignoring a "bad" 00 state, should one occur. IF a 00 state
occurs followed by a 10 or 01, the digital chips will increment or
decrement their count by one. However, the 00 state in the middle
means that there has actually been at LEAST three counts occur and
very likely more.
This became a cause for concern when looking at my Goldmine codewheels.
Handling one with my fingers left enough oil in the slots to cause
quadrature problems ! I didn't bend it, I just touched it, and that's
the result.
It seemed to me that error checking was a needed idea.
> Never accept free advice. Trust me on this.Oh yeah.
> [Paul Devey]The Sherline system IS a DRO, but what it actually Digitally Reads Out
> It would be interesting to hear from anyone who has this beastie. What type
> of encoders/CPU/chips are they using? Does this device have repeatability
> etc.
is CRANK ROTATION. It does not read table movement.
To that end, they have a codewheel added to the leadscrews and IIRC, a
custom made optical assembly.
BTW, this info comes from the dim recesses of failing memory, so no
quotes please. However, I think I got it from the fellow ( whose name
escapes me ) who actually designed the product and was quite
forthcoming about all the details. I quite like that in a company. I
may have to buy one of these Sherlines one day.
> Alan, you have put much thought and effort into your DRO. Many of us couldThe day will likely come when I do exactly that, but as the encoder
> benefit from more info on your experiences. Of course I am buttering you
> up. Do you feel comfortable contributing your DRO design to this community?
> It probably would not be long before others contribute their efforts in
> ways that will also benefit you.
problem is not yet solved, I'm reluctant to do so until I do have a
working unit.
Alan
--
Alan Rothenbush | The Spartans do not ask the number of the
Academic Computing Services | enemy, only where they are.
Simon Fraser University |
Burnaby, B.C., Canada | Agix of Sparta