Advanced Search

I just discovered that my formula and the one in the QTPlasmaC documentation ids not correct for the THAD2. Those formulas work for the previous release of THAD.
PncConf has the correct formula by the looks of it. Does any have the correct formula for me?

I do not, i set automation off, play with voltage till i get roughly good cuts and THC properly tracking, sometimes a bit of editing the scale and offset to match the measured voltage (ranges from 97V to 135V depending on the source and nozzles), then:
- fine tune the cut height by changing the voltage in 2V increments up or down
- fine tune the feed rate
- fine tune the air pressure to get clean cuts on the bottom side (less dross)
All this should be done whenever changing material thickness/type, nozzle diameter/type, and/or plasma source eventually. Also will be influenced by the amount of moisture in the compressed air, sometimes enough to cause issues.
And i never use autovolts, mainly due to many external factors that i have no control over, like, huge power fluctuations, huge differences in material being cut, above mentioned moisture, old air compressors spewing oil through the torch, using old plasma sources with no current control, etc.
-
Another thing that will absolutely mess with cutting is the ground clamp, it has to be properly bolted to the table, no clamp.

 

How do others determine the volt/mm if you don't use Autovolt?

You are missing this line in your kinematic component:

Mark-

My Fanuc 21 will alarm if you program a feedrate which exceeds the machine's capability during G94 or G95.  There are no settings; the control checks commanded RPM and FPR, calculates the IPM (or m/m) and vomits if you exceed the ceiling.  In my case, this is about half the max rapid rate.

There is no check to see if the commanded feedrate is a good idea - only if it exceeds the MFGR's max.

In your case you could probably set a ceiling which corresponds with your coarsest desired thread plus some headroom for accel... but that is probably still fast enough to crash a drill.
 
EDIT
Is there any reason for you to program in G94?  On my Fanuc lathe the only time I need to program in G94 is during live tool work or when I need to position the turret for the bar feeder with the spindle stopped.

Maybe just stop using G94 on the lathe?

OP-
Unfortunately, there is no built-in or pre-made configuration for combining a rotary axis and spindle functions in LCNC.  As you've discovered in other forum posts there are a number of ways to skin the cat, but none of them can be implemented without some HAL fiddling.  Much like tool changers, rotary axes/spindle combinations are very hardware dependent so a one-size-fits-all approach is unlikely to be created and incorporated in to mainstream LCNC code.

Others may - hopefully will - chime in, but what I've gathered is the fundamental hurdles to a combination axis/spindle is that LCNC cannot re-home an axis in the middle of a gcode program.  Other controls I've used (or own) home the rotary axis every time the axis is engaged via M-code, including in the middle of a program.  LCNC can't do this, and so the result is a massive following error between where LCNC expects the rotary axis to be and the real position after running in spindle mode and then switching back to axis mode.

If you have axis encoder feedback to LCNC, then LCNC goes crazy when you switch from spindle mode to axis mode due to the following error.

If you don't have encoder feedback (open loop), then there is no way to switch from axis to spindle and back to axis mode in the middle of a program without completely losing track of position.

All the configurations I've come across for axis/spindle are just different schemes to work around the above problem.

Do you need the A-axis/4th axis to do synchronized motion with another axis?  i.e. lathe-like threading or rigid tapping?

If not, then the caxis.comp HAL component would be the easiest way to get your 4th to behave like a spindle.  Once of the nice things about caxis.comp is that there are no M-codes required to 'switch' back and forth between positioning and spindle (velocity) modes.  Caxis.comp handles that internally - essentially it checks for spindle-type commands and if one is issued (M3 Sxxx $xx) then it spins the rotary axis.  When the spindle stop command is issued caxis.comp simply returns the rotary axis to the last position it was at before the velocity command was triggered.

If you do need synchronized motion then one of the other methods would be better; I've found that caxis.comp interferes with synchronized moves and have had to abandon attempts at using it on my lathe in favor of one of the other configuration types.

It would help if we knew what your end-goal was, or at least how you intend to use the combo spindle/axis.
Is it primarily going to be a rotary axis with infrequent spindle work?  Or is it more like a lathe with infrequent C-axis positioning?
What are you driving the rotary axis with?  Servo drive?  If so, is the drive capable of homing accurately on its own?

Working on Axis style jog controls...



JT

after playing around with the refclock in the xml the issue has been solved

You might have missed edit in the last post

I would start out with an unmodified 'xyzcb_tdr_kins.comp' and do the modifications in small steps while frequently 'halcompiling' the file to find out when it breaks.