Finally got help from sourceforge with my email troubles - after 3 
months of waiting for a response.

This homing sequence is a hot topic for me. We wrote a custom homing 
configuration that works well, but unfortunately it doesn't work the the 
PRU step generator.

 >> Simply give the same homing sequence number to each side.

This wouldn't work unless you actually assigned a separate joint to each 
motor and programmed your g-code accordingly. It needs to be simpler 
than that.

What our custom config does is intercepts the step signal after the 
switch on that side is triggered and waits for the other side to catch 
up. Then once the other side is triggered, it starts allowing the step 
signal to pass back out to both sides.

Here is the code:

# x-axis
setp stepgen.0.position-scale [AXIS_0]SCALE
setp stepgen.0.steplen 1
setp stepgen.0.stepspace 1
setp stepgen.0.dirhold 35000
setp stepgen.0.dirsetup 35000
setp stepgen.0.maxaccel [AXIS_0]STEPGEN_MAXACCEL
net xpos-cmd axis.0.motor-pos-cmd => stepgen.0.position-cmd
net xpos-fb stepgen.0.position-fb => axis.0.motor-pos-fb
net xstep <= stepgen.0.step
net xdir <= stepgen.0.dir
net xenable axis.0.amp-enable-out => stepgen.0.enable

# y-axis
setp stepgen.1.position-scale [AXIS_1]SCALE
setp stepgen.1.steplen 1
setp stepgen.1.stepspace 1
setp stepgen.1.dirhold 35000
setp stepgen.1.dirsetup 35000
setp stepgen.1.maxaccel [AXIS_1]STEPGEN_MAXACCEL
net ypos-cmd axis.1.motor-pos-cmd => stepgen.1.position-cmd
net ypos-fb stepgen.1.position-fb => axis.1.motor-pos-fb
net ystep <= stepgen.1.step
net ydir <= stepgen.1.dir
net yenable axis.1.amp-enable-out => stepgen.1.enable

# z-axis
setp stepgen.2.position-scale [AXIS_2]SCALE
setp stepgen.2.steplen 1
setp stepgen.2.stepspace 0
setp stepgen.2.dirhold 35000
setp stepgen.2.dirsetup 35000
setp stepgen.2.maxaccel [AXIS_2]STEPGEN_MAXACCEL
net zpos-cmd axis.2.motor-pos-cmd => stepgen.2.position-cmd
net zpos-fb stepgen.2.position-fb => axis.2.motor-pos-fb
net zstep <= stepgen.2.step
net zdir <= stepgen.2.dir
net zenable axis.2.amp-enable-out => stepgen.2.enable

# set all of the step signals to reset
#setp parport.0.pin-02-out-reset 1
#setp parport.0.pin-04-out-reset 1
#setp parport.0.pin-06-out-reset 1
#setp parport.0.pin-08-out-reset 1

# invert a couple of direction signals
setp parport.0.pin-03-out-invert 1
setp parport.0.pin-05-out-invert 1
setp parport.0.pin-07-out-invert 1
setp parport.0.pin-09-out-invert 1

# debounce the y-axis switches and connect them to signals
net switches-y1-raw    <= parport.0.pin-11-in
net switches-y1-raw     => debounce.0.0.in
net switches-y1     <= debounce.0.0.out
net switches-y2-raw       <= parport.0.pin-12-in
net switches-y2-raw     => debounce.0.1.in
net switches-y2     <= debounce.0.1.out
setp debounce.0.delay 10

# join the home switch signals so that both switches have to be closed 
to trigger a home position
net switches-y1        => and2.0.in0
net switches-y2        => and2.0.in1
net home-y         <= and2.0.out
net home-y         => axis.1.home-sw-in

# we will need the inverse of the home switch signals for our logic, so 
run them through not gates
net switches-y1        => not.0.in
net switches-y1-inv     <= not.0.out
net switches-y2        => not.1.in
net switches-y2-inv     <= not.1.out

# we will need the inverse of the direction signals for our logic, so 
run it through a not gate
net ydir    => not.2.in
net ydir-inv    => not.2.out

# we need to determine if the home switch for each motor is tripped 
while the direction line is
# moving the motor towards the switch

# for both y-axis motors, we will prevent the step signal from passing 
to the motor
# if the motor is moving towards the switch and the switch is tripped
# so "or" the inverted direction signals and the inverted home switches
net ydir    => and2.3.in0
net switches-y1 => and2.3.in1
net doh1    <= and2.3.out
net doh1    => not.3.in
net doh1-inv    => not.3.out

net ydir    => and2.4.in0
net switches-y2 => and2.4.in1
net doh2    <= and2.4.out
net doh2    => not.4.in
net doh2-inv    => not.4.out

# if the step generator is trying to send a step (ystep signal) and 
either the motor is moving
# away from the switch or the switch is not tripped, then pass the step 
signal to the motor
net ystep     and2.1.in0
net doh1-inv    and2.1.in1
net ystep1     and2.1.out

net ystep     and2.2.in0
net doh2-inv    and2.2.in1
net ystep2    and2.2.out

# connect our step and direction signals to the output pins
net xstep     => parport.0.pin-02-out
net xdir     => parport.0.pin-03-out
net ystep1     => parport.0.pin-04-out
net ystep2     => parport.0.pin-08-out
net ydir     => parport.0.pin-05-out
net ydir     => parport.0.pin-09-out
net zstep     => parport.0.pin-06-out
net zdir     => parport.0.pin-07-out

# we are using combined home and limit switches
# if either switch trips while the homing sequence is not running, then 
triggered a negative
# limit switch fault
net switches-y1 => or2.2.in0
net switches-y2    => or2.2.in1
net limit-y     <= or2.2.out
net limit-y     => axis.1.neg-lim-sw-in
net limit-y     => axis.1.pos-lim-sw-in

net switches-x-raw     => debounce.1.0.in
net switches-x         <= debounce.1.0.out
net switches-x         => axis.0.home-sw-in
net switches-x        => axis.0.neg-lim-sw-in
net switches-x        => axis.0.pos-lim-sw-in

net switches-z-raw     <= parport.0.pin-13-in
net switches-z-raw     => debounce.1.1.in
net switches-z         <= debounce.1.1.out
net switches-z         => axis.2.home-sw-in
net switches-z        => axis.2.pos-lim-sw-in# set up the other home and 
limit switches
net switches-x-raw       <= parport.0.pin-10-in



 >Len



On 1/3/2014 4:45 AM, andy pugh wrote:
> On 3 January 2014 02:05, Josiah Morgan <josiahmor...@gmail.com> wrote:
>
>> does anyone have a script written for homing in this scenario?
> If the gantry can survive a momentary out-of-square then you may find
> that nothing special needs to be done. Simply give the same homing
> sequence number to each side.
>
> The problem here is that when one side id searching for the latch the
> other side might be backing off prior to searching for the latch, so
> the two sides might end up moving in opposite directions.
>
> I have wondered if the homing behaviour should be to not move any
> joint on to the next homing stage until all joints with the same
> homing sequence number have completed the prior stage, but then it
> gets a bit more complicated if you need to consider questions like
> whether the first joint to find the limit should continue in the same
> direction or should stop. (I think perhaps the answer is "stop" but
> then it is changing state without waiting, and my simple scenario no
> longer holds.
>
> If you simply use the existing home behaviour with a shared sequence
> number then the gantry will only actually be squared at the end of the
> final home move. Up to that point the out-of-square might even be
> worse. You certainly want the final move from latch to home position
> to be as short as possible.
>


-- 
Len Shelton
Applications Engineer
PROBOTIX
8800-B N. Industrial Rd.
Peoria, IL. 61615
Email: l...@probotix.com
Phone: (309) 691-2643



------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to