PIC based DRO - Page 2

Page 2 of 10 FirstFirst 12345 ... LastLast
Results 13 to 24 of 113

Thread: PIC based DRO

  1. #13
    Registered
    Join Date
    Mar 2007
    Location
    UK
    Posts
    534
    Downloads
    0
    Uploads
    0

    Default

    The fast traverse is a completely separate interrupt handler, precise placement only happens at speeds where the motors can handle an instantaneous reversal.

    There is more work to do. When it encounters back lash it will tend to trail by the tolerance and I will need extra remedial steps. OTOH I'm not going to try to fix anything until it has had a chance to tell me what needs fixing.

    I'm writing the code and everything runs in SRAM. I can recompile and upload all new in a matter of seconds. I am in control



  2. #14
    Registered
    Join Date
    Jun 2007
    Location
    Australia
    Posts
    18
    Downloads
    0
    Uploads
    0

    Default

    Hi Robin. What a brilliant idea. When you get it right you will have solved one of the major issues with using steppers. i would be interested in the outcome.I had another thought that if i had the knowhow would be worth pursuing. What if you had a PIC counting pulses sent my Mach 3 and then the PIC moved the stepper motor using the encoder to go to the correct position? Its probably complicated, and you would get some lag,but i would gladly put up with lag for accuracy.



  3. #15
    Registered
    Join Date
    Aug 2008
    Location
    UK
    Posts
    573
    Downloads
    0
    Uploads
    0

    Default

    What if you had a PIC counting pulses sent my Mach 3 and then the PIC moved the stepper motor using the encoder to go to the correct position?
    Hmmm , That wouldn't be too difficult.

    I use a PIC (16F84 and an L6219) to drive the Z motor on my engraver, it'll happily keep up with the step inputs from the controller using interrupts. It even has has a couple of unused timer/counters that could be used to track an encoder. Might be worth a look

    [I still wonder, if you're going to add all this complexity you might be better of using proper servo-motors]



  4. #16
    Registered
    Join Date
    Jun 2007
    Location
    Australia
    Posts
    18
    Downloads
    0
    Uploads
    0

    Smile

    Quote Originally Posted by BillTodd View Post
    Hmmm , That wouldn't be too difficult.


    [I still wonder, if you're going to add all this complexity you might be better of using proper servo-motors]
    Yeah. you could be right, but steppers and encoders on ebay are a lot cheaper than servos, and if a cheap PIC could be made to act as a Pseudo closed loop it would be just as good for a lot less money for the DIYers



  5. #17
    Registered
    Join Date
    Aug 2008
    Location
    UK
    Posts
    573
    Downloads
    0
    Uploads
    0

    Default

    Yeah. you could be right, but steppers and encoders on ebay are a lot cheaper than servos, and if a cheap PIC could be made to act as a Pseudo closed loop it would be just as good for a lot less money for the Dyer's
    "just as good.." No, I'm afraid not.

    If a servo system requires speed to catch-up with the commanded steps all it has to do is dump more power into the servo motor (right up to the point it/something goes bang or hits a power limit) . A stepper motor driver cannot do this. The best a closed loop stepper system could do is to wait until the overload event has passed then add pulses to get back on track.

    Now let's assume the above error occurred while cutting material with multiple passes ( caused by a knot in a piece of wood for example) ; both would have left a 'bump' of uncut material. The servo system would have probably left a smaller bump than the stepper (since it had more power available to attack the bump), so subsequent passes would likely reduce the bump. The stepper system would have to leave the bump untouched and add to the bump while it waited to correct the error. Subsequent passes are very likely to stall again at the initial bump and... well you can see where it's going.



  6. #18
    Registered
    Join Date
    Mar 2007
    Location
    UK
    Posts
    534
    Downloads
    0
    Uploads
    0

    Default

    Quote Originally Posted by BillTodd View Post
    Now let's assume the above error occurred while cutting material with multiple passes ( caused by a knot in a piece of wood for example) ; both would have left a 'bump' of uncut material.
    If you overload a stepper to the point where you lose steps everything thereafter is garbage. That's why us stepper people tend to drive them way below capacity. I have more than enough power to snap the tool but I try not to use it

    With the scales attached, theoretically if it can't cut the material all 3 axes stop, possibly within 0.02 seconds depending on the tolerance. The repeating step pattern will cause it to back off and then try again and again until it succeeds, or not as the case may be.



  7. #19
    Registered
    Join Date
    Aug 2008
    Location
    UK
    Posts
    573
    Downloads
    0
    Uploads
    0

    Default

    With the scales attached, theoretically if it can't cut the material all 3 axes stop, possibly within 0.02 seconds depending on the tolerance. The repeating step pattern will cause it to back off and then try again and again until it succeeds, or not as the case may be.
    That would be the advantage of taking control at an earlier stage in the system.

    Although, If your steppers aren't losing steps (because you're driving them well within limits) why do you need the recovery system?



  8. #20
    Registered
    Join Date
    Mar 2007
    Location
    UK
    Posts
    534
    Downloads
    0
    Uploads
    0

    Default

    Not so much a recovery system, more an external reference to locate the table without depending on everything staying in adjustment on a cheap mill

    I have a certain amount of spring in the system. The Gibbs are tighter at the ends where I rarely stray making backlash a variable. Changing pressure from the tool makes it unpredictable.

    Aiming to better 1 thou accuracy has become a sort of Grail quest... Not quite sure what I'd do with it if I found it but I feel compelled to try



  9. #21
    Registered
    Join Date
    Jun 2007
    Location
    Australia
    Posts
    18
    Downloads
    0
    Uploads
    0

    Default

    Hmm..I think i found another hole im my theory about using pics to link encoders to steppers.It would be feasible to control one stepper that way but I guess would be a problem when integrating X,Y, and Z when interpolated on a g2 for example. If one took a bit longer to correct a couple of missed steps, it would throw the whole move out of wack. I guess you could have some way of all 3 PICs knowing what each of the others is doing.



  10. #22
    Registered
    Join Date
    Jul 2009
    Location
    US
    Posts
    20
    Downloads
    0
    Uploads
    0

    Default Comparator Overview

    Bill,

    I am having trouble simply reading the 90KHz clock single from the scales using just about every method I can think of, be it through a separate comparator, an opamp configured as a comparator, and even a combination of NPN and PNP transistors.

    Can you give us a little insight into how you are using the comparators on the chip to accomplish this and as well a little description of why there are LEDs connected to the clock and data lines.

    I've also read conflicting info on whether or not the signal from the scales is +1.5v high and 0 low, -1.5v high and 0 low or some combination of those. I have an oscilloscope being delivered today which should help ME see what's going on.

    As of now, all I see is 3 "pulses" per second on the clock. However, using a homebrew soundcard oscilloscope technique I can definitely see that it's outputting the usual 2*24. Unfortunately the card doesn't record fast enough to see the clock, just the basic outline of it which looks like this _/-|-\_ (pardon the wonderful ascii rendition) hehe The -'s there are obviously the clocking which ends up somewhere between high and low because it can't resolve on the soundcard.

    ok so I'm all ears.

    Thanks!



  11. #23
    Registered
    Join Date
    Mar 2007
    Location
    UK
    Posts
    534
    Downloads
    0
    Uploads
    0

    Default

    This was my circuit to convert scale volts to TTL. Screwed it to the back of the scale, putting new mounting holes on the PCB isolated the scale.

    Resistor pair R7 and R8 are there to hold the scale within the range of the comparators. 100k was not enough, needs a cap. Had a nasty surprise when I found the scale frame was connected to + on the battery so I had to isolate the scale steel bar to

    Attached Thumbnails Attached Thumbnails PIC based DRO-scale-jpg  


  12. #24
    Registered
    Join Date
    Aug 2008
    Location
    UK
    Posts
    573
    Downloads
    0
    Uploads
    0

    Default

    Hi Jon,

    The scale's signal polarity is conventional i.e. positive = hi, complicated by the fact that the battery +ve terminal is connected to the body of the scale making the 'signal ground' actually -1.5v. I've compensated for this by making my PIC's Vss -1.5v and Vdd +3.5. Once this is done the PIC sees a 1.5v pulse into the comparator's inputs

    The resistor and LED circuit is to simply limit the voltage to about 1v2 when the PIC is driving the CLK and DATA lines. The PIC drives the CLK and DATA lines hi to reset the scale and switch modes (e.g. from slow 300mS to fast 20mS update)

    Reading the data from the scale is simply a matter of

    a) setting the comparator to compare the CLK input with the internal Vref (set at about 0.75v)
    b) wait for clock = hi (by testing the comparator's o/p)
    c) wait for clock = lo
    d) switch comparator input to DATA line
    e) test comparator o/p (switch carry bit as necessary)
    f) shift data into store

    g) loop for 24 bits for binary scale incremental and again for absolute

    Below is the assembly code (it's fairly well commented, so it shouldn't be too difficult to read):

    Note: there are two types of scale data.
    1)Binary 1/20480th of an inch (in two 24bit words one incremental from last zero, one absolute from power on [battery insert])
    2)BCD - which has 6 4bit nibbles representing the display data plus 4bits mode info (Sign, 1/2 thou, mm/inch, not-used)

    My code reads either type, by first counting the number of CLK pulses to determine the type of scale connected to the PIC, then jumping to the appropriate routine.


    Code:
    ;(c) W.K.Todd 2005
    ;Read data bits from Vernier scale
    ;V2.00 - uses on-chip comparator for both inputs
    ;GP0 - data
    ;GP1 - clock
    ;------------------------------------------------------------------
    ;vernier data is 24bits (lsb first) absolute position 
    ;followed by 24bits relative pos (as displayed) 
    ;clock remains high for 50uS between data bursts
    ;each bit represents 20480th of an inch  
    ;data is valid on falling edge of clock
    ;Clock is high for 50uS prior to first valid clock edge 
    ;------------------------------------------------------------------
    ;4bit digit output from new verniers
    ;
    ;verniers tx data as 7 nibbles, first 6 nibbles are display digits lsd-msd,
    ;7th nibble is: Sign bit(1=-ve), Half thou bit(1=0.0005"), mm/inch bit(1=mm), always high bit
    ;Data is valid on falling edge of clock
    ;Clock is high for 50uS prior to first valid clock edge 
    ;-------------------------------------------------------------------
    ;Vdata	equ	0x00	;4 bytes shift register
    ;			;Vdata = MSByte
    ;			;Vdata+1 = NSB
    ;			;Vdata+2 = nsb+1
    ;			;Vdata+3 = LSByte
    ;
    ;initialise comparator etc
    ;
    VInit	BSF	status,RP0	;select bank 1		
    	movlw	B'10100011' 	;set Vref ~ 0.75v, Vdd = 5v;(24/5)* 0.75 
    	movwf	VRCON
    	BCF	status,RP0	;select bank 0
    	movlw	B'00010110'	;multiplex in, int ref output inverted, output
    	movwf	CMCON
    	return
    ;
    ;get vernier data into buffer
    ;
    GetVD	bcf	CMCON,CIS	;switch comp to clk input
    	btfsc	Mode,Vtype
    	goto	GetVDD		;get vernier decimal data
    	
    	call	synlp	;gvd	
    	call	GetVDB		;get and discard ABS
    		
    GetVDB	movlw	0x80		;set hi bit of shift register
    	movwf	Vdata
    	clrf	Vdata+1		;set-up for 24bits
    	clrf	Vdata+2
    	clrf	vdata+3
    	
    
    cphlp	btfss	CMCON,COUT	;wait for  clock to go high
    	goto	cphlp
    	bcf	status,c	;clear carry ready
    ;wait clock low - grab bit
    cpllp	btfsc	CMCON,COUT
    	goto	cpllp
    	bsf	CMCON,CIS	;switch comp to data input
    	btfsc	CMCON,COUT	;test data bit
    	bsf	status,c	;set carry if data = 1
    	rrf	Vdata,f		;roll bit into msb buffer...
    	rrf	Vdata+1,f	;then...
    	rrf	Vdata+2,f	;into lsb.
    	bcf	CMCON,CIS	;switch comp to clk input
    	btfss	status,c	;exit when 24 bits shifted
    	goto	cpllp
    	return
    
    ;sync - wait for clock low for >1mS	
    synlp	btfsc	CMCON,COUT
    	clrf	Vdata+3		;use Vdata+3 as temp timer
    	decfsz	Vdata+3,f
    	goto	synlp
    	return
    
    ;
    ;get decimal vernier data
    ;
    GetVDD	movlw	Vdata+3
    	movwf	FSR		;set indirection pointer
    ;set up nibble counter
    	clrf	vdata+3
    	call	synlp
    	movlw	0x08
    	call	VDbyte		;first nibble 1
    	decf	FSR,f		;Vdata+2
    	movlw	0x80
    	call	VDbyte		;2&3
    	decf	FSR,f		;Vdata+1
    	movlw	0x80
    	call	VDbyte		;4&5
    	decf	FSR,f		;Vdata
    	movlw	0x80		;get last byte 6&flags
    
    VDbyte				;get byte or nibble 
    	movwf	INDF
    cphlp1	btfss	CMCON,COUT	;wait for  clock to go high
    	goto	cphlp1
    	bcf	status,c
    cpllp1	btfsc	CMCON,COUT
    	goto	cpllp1	
    	bsf	CMCON,CIS	;switch comp to data input
    	btfsc	CMCON,COUT	;test data bit
    	bsf	status,c	;set carry if data = 1
    	rrf	INDF,f		;roll bit into msb buffer...	
    	bcf	CMCON,CIS	;switch comp to clk input
    	btfss	status,c	;exit when 8 bits shifted
    	goto	cpllp1
    	return
    
    ;measure the vernier reading speed (300mS slow,20mS fast)
    measure		bcf	CMCON,CIS	;switch comp to clk input
    		call	synlp		;wait for clock low >1mS
    		bcf	Mode,Fflg
    ;if clock occurs within ~25mS then Fast flag will be set
    		movlw	25
    		movwf	vdata		;borrow vdata as counter
    m2lp		btfsc	CMCON,COUT
    		bsf	Mode,Fflg	;
    		decfsz	vdata+3,f
    		goto	m2lp	
    		decfsz	vdata,f
    		goto	m2lp
    		return
    
    ;
    ;check vernier type by counting clock pulses
    ;
    GetVT	bcf	CMCON,CIS	;switch comp to clk input
    	call	synlp		;wait for clock low
    	clrf	vdata+1		;used as timer
    	movlw	30
    	movwf	vdata+2		;clock pulse counter
    vthlp	btfss	CMCON,COUT	;wait for  clock to go high 
    	goto	vthlp
    
    cntlp	btfsc	CMCON,COUT	;wait for clock low
    	goto	cntlp
    	decf	vdata+2,f	;count bit
    	clrf	vdata+1		;used as timer	
    cnthp	btfsc	CMCON,COUT	;wait for clock high  or timeout
    	goto	cntlp		;if clock hi then wait for clock low
    	decfsz	Vdata+1,f	;exit loop if low >~1mS
    	goto	cnthp
    	bcf	Mode,Vtype
    	btfss	Vdata+2,7	;test if >30 clock pulses
    	bsf	Mode,Vtype	;if not then flag as new type vernier
    	return


    Attached Thumbnails Attached Thumbnails PIC based DRO-multi-scale-jpg  
    Last edited by BillTodd; 07-08-2009 at 02:56 PM. Reason: adding picture
    Bill


Page 2 of 10 FirstFirst 12345 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


About CNCzone.com

    We are the largest and most active discussion forum for manufacturing industry. The site is 100% free to join and use, so join today!

Follow us on


Our Brands

PIC based DRO

PIC based DRO

PIC based DRO