Advanced Search

No, the machine starts up in C-axis mode.  Actually, it may be more useful to think of it as the C-axis is always 'on', but paused when the spindle or orient is engaged.

• Start LCNC
  • C-axis is not paused, encoder disconnect not active
• Home all axes
  • axes-are-homed triggers C-axis homing
• C-axis is-homed signal triggers M255 via one-shot and halui.mdi
• M255
  • Checks if C-axis is homed, abort if not homed
  • G0 C0
  • Disconnect encoder from c-axis joint/axis and PID
  • Disable C-axis PID
  • Change stepgen settings to spindle values
• Now in spindle mode, all automatically.

To get back in C-axis mode:

• M254
  • Checks if C-axis is homed, abort if not homed
  • M19 orient spindle to 0 position
  • change stepgen to C-axis values
  • reconnect encoder
  • enable PID
• C-axis is on, and positioned at C0

Minor tip: one thing that frequently trips me up when copying/using other people's files is forgetting to change the M-code (and other) path(s) in the INI file.

You have HOME and HOME_OFFSET values mixed up, HOME = 0 , HOME_OFFSET = -4 or whatever value suits your machine.
Also, it seems you have one of the Y joints reversed, so be careful when jogging it, slowly, to check if all is OK.

Thanks! If I understand correctly you load the machine with spindle in spindle mode, rather than Caxis mode? That makes sense and is one of the things I would've wanted to achieve too, I'll be definitely taking notes from your files Once I figure out why the mcodes don't seem to work for me even though the directory and files seem ok, probably some other silly thing I overlooked. Gotta rtfm. I will have a chance to play around with the lathe in a few days and will report the results

Hi PWC  and many other folk. After many months I am having another go. I took the advice from this thread, and installed new proximity sensors, and added home positions. The issue that  now have is that it homes the z axis correctly, homes the X axis correctly. The y axis homes in sync and in tandum (y1 and y2 gantry motors) as seen in the first photo. It completes the four part homing procedure as seen in the second photo. It shows a capital H for X, Y and Z axis and it also shows the correct Home locations. However it also shows an error - exceeded negitive softlimit on joint 2 . So even though it seemed to of homed correctly , it disables the machine, and I can do nothing with it. 

Any suggestions are greatfully received.  

PS: I have tried endless permutations. The current positive and negitive values are the only ones that make the four step process work. The software suggests that I jog the axis off the joint but its part of the gantry pair so wont do it.

Some think that circles and ellipses are polygons as well.  So I added a ellipse pocketer subroutine  (which does circles too) to the program, and here it is, I also "sharpened up" the  vertices of the polygons a bit. See the screen dump for how well the "half ellipse" fits with the square.

You asked how to make a user button execute a .py script. The link shows how to do that.

What are you trying to do exactly?

RotarySMP wrote:

That forty year old hall sensor module is already cracking, no way I will risk mechanical contact with it.

More powerful magnets may trigger the halls even with a bit of distance.  Try triggering them with a good (N50) neodymium magnet and see how much spacing you can get away with.  You might be able to stay with a fixed magnet and nothing touching the fragile hall ring.

If they need to be closer than the fixed position allows, you could cut a protective surface out of plastic sheet, glue it to the sensor ring, and let the magnet rest on that instead of the halls.  Basically reinforce the hall ring - which it probably needs anyway - and let the reinforcement take the wear.

With a light spring there shouldn't be any real up/down impact forces on the hall ring... just the magnet sliding along.

That forty year old hall sensor module is already cracking, no way I will risk mechanical contact with it.

And another thing...

The existing trigger magnet is a really old ceramic magnet.  You could potentially use a newer, much smaller, neodymium magnet with a square shape to get a cleaner rising edge from the hall sensors.

Or stick with a round one and fiddle with the alignment and possibly carousel.comp's decel-time setting.

RotarySMP wrote:

Any suggestions how to easily make the carousel.comp step through till the desired pin goes high also appreciated.
Cheers,
Mark

Remove the stationary magnet from the cover thing, and replace it with a spring-loaded magnet which remains in contact with the halls as the upper section rises and falls.  The halls will now get positional feedback when the turret is up or down, and carousel will keep the motor-fwd signal high until the appropriate hall sensor is triggered.

Doesn't look like there's any reason you couldn't just 3d print the top cover with appropriate mods for a captive, sliding, spring-loaded magnet.  I'd probably make an aluminum or brass 'carrier' tube for the magnet that presses in to the printed part so the magnet isn't sloppy but also doesn't get hung up on print layer lines.

I don't think I remember seeing another sensor to indicate the turret is down and locked, but as soon as carousel.comp turns off the motor-fwd output it should drop.  You will likely need to play with the hall alignment (or the top hat alignment, to be precise) to make sure carousel.comp doesn't drop the motor signal too quickly or too late to engage the alignment pin(s).

Above should let you eliminate the 'tp' component in your HAL example and just let carousel.comp treat your pneumatic system like a unidirectional motor.

Trylobite sent me a mail which really helped me understand the difference between the original Schaublin turret control, as mine still is, and the mods he made.He replaced the hall sensors with microswitches, which activate once the turret rotates into position. He uses that to signal closing the pneumatic tool change valve, dropping the turret to lock.

Since my Hall sensors do not read high until after the turret drops, bringing the magnet into proximity, I can't use the switches for valve control.

I initially thought it would simply step through, one pocket at time, till the correct feedback sensor goes high. I started writing the attached draft HAL to include a second pause for the pressure to bleed off, dropping the turret onto the hall sensor. But carousel.comp step through pockets like that does it?

Using Carousel.comp, how do make it cycle three times, if it is in pocket #2, to get to pocket #1, verses only moving once to get to #3?

Trilobyte also pointed out that the carousel will keep cycling from one position to the next continually, as long as the pneumatic valve is held open. There is a delay of a few seconds at each position, which appears to be controlled by adjustable restricters in the valving. With those pauses, controlling  the pneumatic valve open loop with simple timing seems feasible. 

I guess I can have it calculate the modula number of pockets to the destination when a change is commanded.
If if measure the time for lift and turn, and the time of pauses, and setp the three delay times whether 1, 2 or 3 pocket moves are needed.
Then by holding the valve open for the appropriate time, it will turn the correct number of pockets.

Any suggestions how to easily make the carousel.comp step through till the desired pin goes high also appreciated.
Cheers,
Mark

Oops, sorry SMC, deleted.

RotarySMP wrote:

Any suggestions how to easily make the carousel.comp step through till the desired pin goes high also appreciated.
Cheers,
Mark

Yes, but I'll wait until you've started your own thread 

RotarySMP wrote:

How do those lathes deal with the order of motion? A Z clearance move first followed my X makes sense for boring tools, with the opposite for turning tools.

Probably time to start your own tool-changer thread rather than blowing up @SMC's project.

Having said that, I'll violate unwritten courtesy and ramble on...

I don't think there's a hard-coded tool change position on those machines... just the expectation that it will be programmed to go to 'home' position.  For Fanuc 21T "C" mode, G28 G0 U0 W0 would move the carriage/slide/turret to the reference position.  If the programmer (or post) calls it on two lines you'd get a sequential X-move then Z-move.  Or W0 then U0 would do Z first, then X.

If you ensure that the tool path before a tool change includes a clearance move of some sort (Z for centerline tools, X for OD and internal boring), then your turret should use a Z-first, X-second sequence.  Your lathe is entirely capable of being used like a gang-tool lathe, with tools on the front and back of the part, turning in both M3 and M4.  You really don't want a boring bar working the rear OD to rapid home in X without a Z-clearance move first.

One reason the tool change position isn't hard-coded (in Fanuc) is that it's much faster to program a specific tool change location than wait for the slide to go all the way back to home.  I've done this on production runs of short parts... back the turret up so the longest tool barely clears the stock/part, and substitute that location for the standard "G28 G0 U0..." move.  Saves a ton of cycle time on long part runs.

So I'd leave out a specific TOOL_CHANGE_POSITION in your INI file and get used to programming a version of G53 G0 Z0 as your 'default' safe position.  You probably aren't going to be using the tailstock and automatic turret commands at the same time.  And you'll get used to drilling with the turret pretty quickly; it's so much nicer than using a tailstock by hand.

Tailstock work:  manual tool indexing
Non-tailstock work: auto tool changes at G53 Z0 X0 (or somewhere)

Hi,
Will this button open a new GUI when BUTTON is pressed?