Advanced Search

I think you've got your X travel direction and/or limits messed up.  I see this in INI:

And you mentioned earlier that when homing X moves away from the spindle (positive X).  If the SEARCH_VEL is negative (-15), but the movement is AWAY from the spindle, then you've got the X-direction backwards.

I think what's happening is that when homed, LCNC thinks the X axis is at centerline.  When you move in towards the chuck all X moves are negative.  Result is that your X-axis is basically reversed in LCNC from reality, and LCNC is trying to execute the G-code from (what appears to be) inside-out.

The DRO in your photo shows "G54 X -29.031" when the tool tip should be a positive number.  It should be on the positive (bottom) side of part centerline (it is) and be at a positive X value (it isn't).

Maybe think about making a copy of your config and then start adjusting your axis/joint values.  My suggestion, based on your Emco lathe, is to work out values which put all your drill positions at G53 X0.  Your turning tools will then have positive offset values (I think), but whenever you're at G53 X0 you know the turret drill holes are on spindle centerline.

I could be wrong, of course.  Go slowly with any adjustments.

Anything in a pull request should be mature and thoroughly tested. Changing the code of a hal component after it has been released brings the unpleasant possibility of breaking configurations.
A recent example is the 'toggle2nist.comp' that showed buggy behavior.
Given the lack of personnel we must not expect others to check the code we submit for inclusion.

Thank you! Will try it out on friday.

This is my crude explanation
youtube.com/shorts/nY0A_utbBd4?si=7yU3tGuBq7IW74BQ
 

blazini36 wrote:

Well anyone can just submit a component via pull request to the linuxcnc repo. Not sure if the maintainers test them at all other than making sure they compile. If it's a good an useful component, there's really no reason not to just submit it via pull request.

This is how it should be done. Chances are it would be approved because a broken component will not break Linuxcnc. Compilation is automatically tested with the commit. I have submitted one this way. It does add some overhead to what you have to do as you need to format the comments etc so the man page is generated.

This thread maybe should be helping people to get this formatted and into the code.

The wider part(base) is on right in linuxcnc as in the pic. It should be on the left the wider part is supposed to be held in the spindle. My spindle is on the left 

It's supposed to machine the head first and move down to the base. But it's flipped around. I'll try and take a video of it, 

I m not sure, I haven't gotten as far as an index yet, I'm trying to get the A and B working right first. That uses the PRUencoder. The encoder only supports quadratic at the moment. I have the A and B pulses going to the WHA and WHB inputs from the MPG(by passing the opticouplers). I'm not sure if the index pin will have to be bypassed also.

Don’t make that assumption re feedhold. And tapping. The planner is taking things direct from the Hal pin. Not from the lcnc motmod module.

it needs to be explicitly tested. Unless someone has done so already and can confirm what the behaviour is. 

And my lmde was dead after adding dev version for halcompile. Which is easy to understood.

But - after reinstall all - first it does not need to manually add python ? It was not working at all. Some updated libraries. No official rtai kernal with mint yet ? 

Looks ok to me, the base of the pawn (ie the wider part) is on the left.
The green/blue X/Z indicator shows your current work offset origin.
X+ should move the tool away from the center line.
Z+ should move the tool away from the spindle.

I'm using a component authored by Andy Pugh to control my lathe's main spindle as both a C-axis and spindle.  Comp attached, and I believe this was the last version Andy and NoJo worked out via the forum a few years ago.

NOTE - this component treats the spindle as an axis until a spindle command is issued.  This means absent a spindle command, the C-axis is active and trying to maintain a position.  Once the spindle command is done, C-axis re-engages and will return to the last position (within one turn) prior to the spindle command.

I want the ability to disconnect the spindle/axis so I can manually turn it (indicating part/chuck).  Because the spindle motor is a servo, if the drive is enabled and machine is on, the spindle is locked in position when the machine is at rest.

Right now I have a simple enable toggle in HAL that disables the drive directly.  This allows me to turn the spindle by hand for indicating or tightening the chuck.  I can jog the C-axis, but I find being able to manually move the spindle more convenient.

Unfortunately, because I haven't disconnected anything else in HAL, if I rotate the spindle more than about a turn I get a following error and LCNC turns the machine off.  I've had to set the ferror higher than I'd like just to be able to turn it a bit, and I'd really like to tighten it up.

I could use some help figuring out how to disable the motor in such a way that:

• No following error while disabled, regardless of turns
• No caxis.comp errors or accumulation of following error upon re-enable (which would result in a potentially violent attempt by the C-axis PID to eliminate the following error)

Is this something I could accomplish in HAL, or does caxis.comp need to be modified/edited in some way?

andypugh wrote:

This should have been fixed now:
github.com/LinuxCNC/linuxcnc/commit/0bc9...000f4da3e4ba393b65c3

The new version is only in the development version of LinuxCNC at the moment.

You can install it on your own installation with:
1) Install LinuxCNC dev to get the "halcompile" tool.

sudo apt-get install linuxcnc-uspace-dev

2) Download this file and save it to your PC
https://raw.githubusercontent.com/LinuxCNC/linuxcnc/refs/heads/master/src/hal/components/toggle2nist.comp

3) Install it
[code]sudo halcompile --install toggle2nist.comp

[/code]
 

Problem with toggle2nist is the name of the is-on pin. Halui uses the is-on name as an output for lots of pins so it tripped me up expecting that to be an output pin. It's an input pin that absolutely must be connected to the is-on output or the component can't transition to the next state. They should have named it "on-state" or something.

Why is LinuxCNC so stupid?

You are not helping yourself with comments like this.

As said already. Post the ini and hal files

I don't understand why it does not work with just the stepconf config.

Why is LinuxCNC so stupid?

I have the axis travel set to 20 inches in stepconf.

I have the home switch location set to 0.

Why does it move away from zero and toward 20 while homing????!!!

Moved to "EtherCAT" section.