|
Very slow. Maybe 5 seconds to complete an entire revolution. This means I'm getting a tic about once every 5.0S/1440 = 3.5mS The interrupt handler for is very short. Say 25 instructions or so total, including saving off all the registers etc. at the beginning of the routine. The PIC is running at 4MHz. Thanks, --- In , "rtstofer" <rstofer@p...> wrote: > > > How fast are you spinning the motor? Maybe you are running out of > time... > > --- In , "cjl023" <cjl023@y...> wrote: > > > > Eirik, > > > > That's a good point. > > > > I'm driving the motor using a TEA3718. It drives a constant > current > > through the motor using switch mode current regulation. The power > > and encoder channels all run through the same flat 6 conductor > piece > > of cable. This is just the way the motor is put together. It comes > > off-the-shelf this way. > > > > Thanks for your help and counsel. I will look into isolating these > > cables from one another and see if it helps. > > > > Take Care, > > > > > > --- In , Eirik Karlsen <eikarlse@o...> > wrote: > > > Ok. > > > You may well have noise in the system. Use screened wire for all > > > feedback signals, screen to proc. gnd. > > > Also try screening the motorwires. Motordrive signals > (especially > > PWM) > > > are very noisy. > > > > > > cjl023 wrote: > > > > > > > > > > > Eirik, > > > > > > > > I dynamically brake the DC motor by momentarily reversing the > > > > voltage applied to it for 20mS. This stops the motor dead in > its > > > > tracks. > > > > > > > > I'm using a TEA3718 to control the motor, and always turn it > at > > the > > > > slowest speed possible, when positioning it in the described > > manner. > > > > > > > > It's just a small 9VDC motor with a gear box that then has a > > shaft > > > > that comes out both sides of the gear box. One of the shafts > > > > connects to the encoder. The other shaft connects to a rack- > and- > > > > pinion focusing mechanism on an optical tube. > > > > > > > > Thanks, > > > > > > > > > > -- > > > ******************************************* > > > VISIT MY HOME PAGE: > > > <http://home.online.no/~eikarlse/index.htm> > > > LAST UPDATED: 23/08/2003 > > > ******************************************* > > > Regards > > > Eirik Karlsen |
|
|
PLC vs PIC
Started by ●December 15, 2004
Reply by ●January 5, 20052005-01-05
Reply by ●January 5, 20052005-01-05
|
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 --- cjl023 <> wrote: > > Very slow. Maybe 5 seconds to complete an entire > revolution. > > This means I'm getting a tic about once every > 5.0S/1440 = 3.5mS > > The interrupt handler for is very short. Say 25 > instructions or so > total, including saving off all the registers etc. > at the beginning > of the routine. > > The PIC is running at 4MHz. > > Thanks, > --- In , "rtstofer" > <rstofer@p...> wrote: > > > > > > How fast are you spinning the motor? Maybe you > are running out of > > time... > > > > --- In , "cjl023" > <cjl023@y...> wrote: > > > > > > Eirik, > > > > > > That's a good point. > > > > > > I'm driving the motor using a TEA3718. It drives > a constant > > current > > > through the motor using switch mode current > regulation. The > power > > > and encoder channels all run through the same > flat 6 conductor > > piece > > > of cable. This is just the way the motor is put > together. It > comes > > > off-the-shelf this way. > > > > > > Thanks for your help and counsel. I will look > into isolating > these > > > cables from one another and see if it helps. > > > > > > Take Care, > > > > > > > > > --- In , Eirik Karlsen > <eikarlse@o...> > > wrote: > > > > Ok. > > > > You may well have noise in the system. Use > screened wire for > all > > > > feedback signals, screen to proc. gnd. > > > > Also try screening the motorwires. Motordrive > signals > > (especially > > > PWM) > > > > are very noisy. > > > > > > > > cjl023 wrote: > > > > > > > > > > > > > > Eirik, > > > > > > > > > > I dynamically brake the DC motor by > momentarily reversing the > > > > > voltage applied to it for 20mS. This stops > the motor dead in > > its > > > > > tracks. > > > > > > > > > > I'm using a TEA3718 to control the motor, > and always turn it > > at > > > the > > > > > slowest speed possible, when positioning it > in the described > > > manner. > > > > > > > > > > It's just a small 9VDC motor with a gear box > that then has a > > > shaft > > > > > that comes out both sides of the gear box. > One of the shafts > > > > > connects to the encoder. The other shaft > connects to a rack- > > and- > > > > > pinion focusing mechanism on an optical > tube. > > > > > > > > > > Thanks, > > > > > > > > > > > > > -- > > > > ******************************************* > > > > VISIT MY HOME PAGE: > > > > <http://home.online.no/~eikarlse/index.htm> > > > > LAST UPDATED: 23/08/2003 > > > > ******************************************* > > > > Regards > > > > Eirik Karlsen > > |
|
|
Reply by ●January 5, 20052005-01-05
|
Peter van Hoof 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. > That would very much depend on how the quadrature signal is decoded. If a full state machine is implimented (one state for each edge) it's not a problem since the only way to get to the next state is to have the correct next edge appear. If the more common D flip flop for direction sensing is used (D=phase A, Clk=phase B) then jitter on the clk phase will produce false steps in whatever direction was last detected. I have seen Decwriter (printer) fling their carriages against the rails because of jitter on one phase of the motor encoder (low LED output). R |
Reply by ●January 5, 20052005-01-05
|
At 01:26 PM 1/4/2005, HangGlider wrote:
>But the following modified code doesn't run -
LEDS connected to RB0 and >RB1 stay lit continuously. Both programs simulate correctly with MPLab >SIM. >;****main program**** >begin movlw b'00001111' ; 0x0F into W > movwf countr ;stuff W into countr Following instruction is wrong - should be "movfw" instead of "movlw" >loop0 movlw countr ;get value of countr into W > movwf leds ;load W into portB (switch on rightmost LED) > call delay ;wait for some time > decfsz countr,1 ;decrement countr & replace results > goto loop0 ;if countr <> 0 loop again > goto begin ;countr = 0, start over dwayne -- Dwayne Reid <> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 20 years of Engineering Innovation (1984 - 2004) .-. .-. .-. .-. .-. .-. .-. .-. .-. .- `-' `-' `-' `-' `-' `-' `-' `-' `-' Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. |
|
|
Reply by ●January 5, 20052005-01-05
|
Thanks Dwayne!! I appreciate the help... HangGlider On Jan 5, 2005, at 5:21 PM, Dwayne Reid wrote: > > At 01:26 PM 1/4/2005, HangGlider wrote: >> But the following modified code doesn't run - LEDS connected to RB0 >> and >> RB1 stay lit continuously. Both programs simulate correctly with >> MPLab >> SIM. >> >> >> ;****main program**** >> begin movlw b'00001111' ; 0x0F into W >> movwf countr ;stuff W into countr > > Following instruction is wrong - should be "movfw" instead of "movlw" > >> loop0 movlw countr ;get value of countr into W >> movwf leds ;load W into portB (switch on >> rightmost LED) >> call delay ;wait for some time >> decfsz countr,1 ;decrement countr & replace results >> goto loop0 ;if countr <> 0 loop again >> goto begin ;countr = 0, start over > > dwayne > > -- > Dwayne Reid <> > Trinity Electronics Systems Ltd Edmonton, AB, CANADA > (780) 489-3199 voice (780) 487-6397 fax > > Celebrating 20 years of Engineering Innovation (1984 - 2004) > .-. .-. .-. .-. .-. .-. .-. .-. .-. .- > `-' `-' `-' `-' `-' `-' `-' `-' `-' > Do NOT send unsolicited commercial email to this email address. > This message neither grants consent to receive unsolicited > commercial email nor is intended to solicit commercial email. > > to unsubscribe, go to http://www.yahoogroups.com and follow the > instructions > Yahoo! Groups Links > > |
Reply by ●January 5, 20052005-01-05
|
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 > > --- cjl023 <cjl023@y...> wrote: > > > > > Very slow. Maybe 5 seconds to complete an entire > > revolution. > > > > This means I'm getting a tic about once every > > 5.0S/1440 = 3.5mS > > > > The interrupt handler for is very short. Say 25 > > instructions or so > > total, including saving off all the registers etc. > > at the beginning > > of the routine. > > > > The PIC is running at 4MHz. > > > > Thanks, > > > > > > --- In , "rtstofer" > > <rstofer@p...> wrote: > > > > > > > > > How fast are you spinning the motor? Maybe you > > are running out of > > > time... > > > > > > --- In , "cjl023" > > <cjl023@y...> wrote: > > > > > > > > Eirik, > > > > > > > > That's a good point. > > > > > > > > I'm driving the motor using a TEA3718. It drives > > a constant > > > current > > > > through the motor using switch mode current > > regulation. The > > power > > > > and encoder channels all run through the same > > flat 6 conductor > > > piece > > > > of cable. This is just the way the motor is put > > together. It > > comes > > > > off-the-shelf this way. > > > > > > > > Thanks for your help and counsel. I will look > > into isolating > > these > > > > cables from one another and see if it helps. > > > > > > > > Take Care, > > > > > > > > > > > > --- In , Eirik Karlsen > > <eikarlse@o...> > > > wrote: > > > > > Ok. > > > > > You may well have noise in the system. Use > > screened wire for > > all > > > > > feedback signals, screen to proc. gnd. > > > > > Also try screening the motorwires. Motordrive > > signals > > > (especially > > > > PWM) > > > > > are very noisy. > > > > > > > > > > cjl023 wrote: > > > > > > > > > > > > > > > > > Eirik, > > > > > > > > > > > > I dynamically brake the DC motor by > > momentarily reversing the > > > > > > voltage applied to it for 20mS. This stops > > the motor dead in > > > its > > > > > > tracks. > > > > > > > > > > > > I'm using a TEA3718 to control the motor, > > and always turn it > > > at > > > > the > > > > > > slowest speed possible, when positioning it > > in the described > > > > manner. > > > > > > > > > > > > It's just a small 9VDC motor with a gear box > > that then has a > > > > shaft > > > > > > that comes out both sides of the gear box. > > One of the shafts > > > > > > connects to the encoder. The other shaft > > connects to a rack- > > > and- > > > > > > pinion focusing mechanism on an optical > > tube. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > -- > > > > > ******************************************* > > > > > VISIT MY HOME PAGE: > > > > > <http://home.online.no/~eikarlse/index.htm> > > > > > LAST UPDATED: 23/08/2003 > > > > > ******************************************* > > > > > Regards > > > > > Eirik Karlsen > > > > > > > > |
|
|
Reply by ●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 |
|
|
Reply by ●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 ●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 ●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 > __________________________________________________ |
|
|
