Probe Basic using "carousel.comp" instead of macros?

I have a working Gmoccapy config using carousel component. Is it possible to use Probe Basic with the carousel component instead of the macros?

COlger81 wrote:

I have a working Gmoccapy config using carousel component. Is it possible to use Probe Basic with the carousel component instead of the macros?
 

Yes, but it requires a fair amount of hand-fiddling.

If you have an ATC that doesn't follow the basic mechanical config intended by the PB devs, you'll need to do some heavy editing.

Search the qtpyvcp forum... I think I posted my config a (few times) that is for PB using carousel.  I have a stepper motor and 5:1 reducer with one index sensor, and one per-pocket sensor.

spumco wrote:

If you have an ATC that doesn't follow the basic mechanical config intended by the PB devs, you'll need to do some heavy editing. 

To clarify... the macros are designed to work with a geneva drive and a 'dumb' on/off motor.

The machine is a Fadal with a 21 tool Geneva.

COlger81 wrote:

The machine is a Fadal with a 21 tool Geneva.
 

Nice!

IIR, the Fadal has a 3P motor driving the ATC, and a couple of contactors to run the motor.  The chip shield is mechanical, and I think the ATC has two position switches for feedback.  You'll have to add outputs in LCNC for the through-spindle taper cleaning blast and a couple other IO bits, but since you've already done that for Gmoccapy it should be pretty straightforward (I won't say easy) to get the same functions in PB.

So you're (more or less) all set to use the built-in PB macros.  Any specific reason why you'd want to use carousel.comp instead?  In my inexpert opinion it will take more time to untangle & rewrite the PB macros or write your own logic from scratch for carousel than to edit the built-ins.

BTW... if you've got the Pozi-drive two-speed spindle, there's a gent in Germany who built one from scratch and posted his LCNC config on github:
github.com/PeterMue/ZX45-LinuxCNC

The tool changer has a single prox sensor that counts "triggers" halfway between the pockets. Current setup, i have to shutdown each time at tool 1 or it gets confused. On startup, it automatically tells software that the turret is homed. This works well but it would be nice if i could save current tool persistently on shutdown, and recall the last tool on startup.

I think the best way to achieve this is probably to just add another sensor to the turret for homing. Would be nice to be able to do it in software though.

COlger81 wrote:

This works well but it would be nice if i could save current tool persistently on shutdown, and recall the last tool on startup.

The PB macros use persistent parameters to keep track of which tool is in which pocket (and spindle); it's pretty graceful on re-start as once the homing routine is complete it 'remembers' the state at last shutdown.

Once homing is done, the animated screen widget updates to show the post-homed status - which tool is in which pocket, what's in the spindle, etc.

As you mentioned, I think you need some sort of 'home' sensor - a once-per-turn thing.  I know that ATC is pretty slow and homing it would be annoying each startup, but it'd be safe.

Yeah it's add a home sensor, takes just a few seconds to home mine at startup and all is good to go!