Advanced Search

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.

I had problems during the installation of linuxcnc irrc i had to manual mount the usb drive. how should i continue I'm a bit clueless

120watt is too low i think.
I plan to build a machine like this and am thinking to put 2 x 750w for y axis 1x750w x axis 1x600w z axis.
With servobelt transmission system with std s5m belts.

I use this calculator to calculate the parameters for the THC.

jscalc.io/source/ScVgoteuXJ9ySlXo

Can you check to see if it is accurate please?

The message about 'undefined symbol: kinematicsSwitch' is actually a spurious error that will pop up whenever the kinematic fails to load.
I believe the actual problem is:

which unfortunately is a bit cryptic.

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.

Thank you for the input andypugh and jpg. The Annual $1,900 usd. price tag for the GeoMagic  each year is so far a complete no
go for me.

i keep losing frames while operating the machine which affects the smoothness of the motion i dont know what should i do or look for to fix this issue i thought it might have been the cables so i got new ones but the issue still remains any help would be appreciated

This weekend I again trashed a tool (luckily only a drill), but using an F50 (Expecting G94 50 mm/min) while in G95 mode. (at about 38:45...)


I have heard the some other controllers allow setting an error trigger if the feedrate exceeds a set threshold. I went searching if LinuxCNC offers an option to set a max feedrate it will error out on in G95 (would also make sense to have a min feedrate error message in G94, as I have also had F0.01, and then wondered why the machine didn't seem to move). I didnt find these options. Am I missing something or they really dont exist?
Cheer,
Mark

Hi Tommy,

i think i never used the lower case "s". I used the millturn.comp for this function. Here is the part from my comp file:

EXPORT_SYMBOL(kinematicsType);
EXPORT_SYMBOL(kinematicsSwitchable);
EXPORT_SYMBOL(kinematicsSwitch);
EXPORT_SYMBOL(kinematicsInverse);
EXPORT_SYMBOL(kinematicsForward);

static hal_u32_t switchkins_type;

int kinematicsSwitchable() {return 1;}

int kinematicsSwitch(int new_switchkins_type)
{
switchkins_type = new_switchkins_type;
rtapi_print("kinematicsSwitch(): type=%d\n",switchkins_type);
// create case structure for switchable kinematics
switch (switchkins_type)
{
case 0: rtapi_print_msg(RTAPI_MSG_INFO,
"kinematicsSwitch:TYPE0\n");
*haldata->kinstype_is_0 = 1;
*haldata->kinstype_is_1 = 0;
break;
case 1: rtapi_print_msg(RTAPI_MSG_INFO,
"kinematicsSwitch:TYPE1\n");
*haldata->kinstype_is_0 = 0;
*haldata->kinstype_is_1 = 1;
break;
default: rtapi_print_msg(RTAPI_MSG_ERR,
"kinematicsSwitch:BAD VALUE <%d>\n",
switchkins_type);
*haldata->kinstype_is_1 = 0;
*haldata->kinstype_is_0 = 0;
return -1; // FAIL
}
return 0; // ok
}

You need to plot the voltage or encoder with halscope. I think that is way too low. I would expect around 130 volts. I suspect the THCAD is not properly calibrated. The plot will tell you how long to delay. I would check the input voltage at the thcad with a multimeter.

I did have a machine once that needed about 2 seconds to be stable...

Linux is case sensitive, so kinematicsswitch is not the same as kinematicsSwitch, notice the upper case S.

This will not work for the Pi because the buildbot does not build Debs for it.
Your only option is to compile from source.