Home designed and built 5C CNC lathe with ATC and C_Axis
My intention is to get the machine going as a basic 2 axis lathe to start - that is a given.
After that the next thing is that the mechanics have to be aligned - Z parr to spindle axis, X perp to Z, Spindle nod 0, etc and for that I need to jog the axis around a lot, with dial indicator and accurate test bar in spindle, etc - So that is the reason I am trying to get the jog controls working as part of the basic function. I realise I can do all the jogging using the mouse, etc, but thought the way I am trying is good to learn from as well - after all, the concept is not complex - just jog the Axes with manual wheels, etc!
All the rest of the complex stuff - C_axis, ATC, etc is miles down the road and not on my mind right now!
To continue doggy-paddle in the deep end...
Homing is a bit complex on this machine. The Clearpath motors have a built-in programmable function called 'Accurate Homing' . When the motor is first powered, the first ENABLE causes the motor to rotate in a programed direction, at a (programmed) reduced torque, till the axis engages a hard stop. The motor stops, and rewinds from there till the motor controller senses the Index pulse on its encoder. ( the motor is a brushless motor, with built in controller and 6400 pulse encoder, so is closed loop internally) - When the motor senses it's index pulse it stops and reverts to full torque operational mode. And that is the home position.
How to tell Linuxcnc that we are at home? The motor has an output discrete which indicates it reached the index position, so I will feed that into L_cnc and use that as home, but the problem is that L_cnc must not generate step pulses to home that axis - the motor must just be enabled and the motor will home itself..
Perhaps for starters I must just use the Limit switches as home position to get things going - they are not accurate - only hall effect sensors so not great for absolute home sensing.
This is NOT a basic lathe......If it was I would just have used an ordinary lathe and converted it like many have done! I must just try make it an ordinary one to start..
Regards
Joe
Please Log in or Create an account to join the conversation.
I see that will complicate things a bit.The Clearpath motors have a built-in programmable function called 'Accurate Homing' .
So, just to make sure we are on the same page:
Were your axis homed when you tried to jog?
[edit]
With homed I mean in LinuxCNC (Homed symbol in the DRO)
[edit2]
So considering your homing set up I don't really see all that much of an issue with manual simulation the home switch, my apologies.
There has been a discussion about homing done by the drives. I'll try to find it.
[edit3]
Ok according to this (linuxcnc.org/docs/2.8/html/config/ini-homing.html):
to set up for immediate homing you would need to set
HOME_SEARCH_VEL = 0
HOME_LATCH_VEL = 0
HOME_USE_INDEX = NO
HOME_SEQUENCE = 0
Are your drives sending the position back to LCNC (eg by encoder output)?
[edit4]
The only way I see is to connect the 'homed'-signal from the drive to the index input. But for that to work i think you need to set a latch_velocity:
HOME_SEARCH_VEL = 0
HOME_LATCH_VEL = 0.1
HOME_USE_INDEX = YES
HOME_SEQUENCE = 0
The problem is that the stepgenerator will put out steps which is what you don't want. So I don't have a solution for you at the moment.
[edit5]
one way might be to loop the pid.N.output back into the pid.N.input and disconnect the stepgen in HAL using a multiplexer (mux2) and using the joint.N.homed for the select input. Not sure what happens once the stepgen is reconnected though, following error?
Attachments:
Please Log in or Create an account to join the conversation.
Were your axis homed when you tried to jog?
No, not homed. I did not realize I needed to home before trying to jog.
Are your drives sending the position back to LCNC (eg by encoder output)?
No. The motors look like a normal stepper motor with a stepper drive/controller attached, except motor has an encoder which the drive uses to close the INTERNAL loop, ie, the motor will always try to turn by the number of steps given by using its encoder to know if the step command equals the encoder steps moved.
So it is closed loop, but within the motor. Normal steppers may lose steps due to resonance, etc, these do not- they WILL step, and keep track of steps and not lose any, so long as the max motor torque is not exceeded.
Let me try on the lathe with the limit switches as home indicators, and disable the motor's own homing process. If I can get all that working, then I can mess around with alternatives. And in the meantime read up some more to see if I can discover and understand what you wrote:
HOME_SEARCH_VEL = 0
HOME_LATCH_VEL = 0.1
HOME_USE_INDEX = YES
HOME_SEQUENCE = 0
means..!
Thank you for working at this to try help me see the light!
Please Log in or Create an account to join the conversation.
HOME_SEARCH_VEL = 0 => don't look for the home switch
HOME_LATCH_VEL = 0.1 => move at 0.1 machine units/s in the positive direction until the index signal appears
HOME_USE_INDEX = YES => look for the index
HOME_SEQUENCE = 0 => first joint to home
In your INI file each [joint] has it's own homing configuration. This would configure your joint to use 'Index only'. The index here would come from an encoder that is going back to LCNC. For example linear glass scales.
Please Log in or Create an account to join the conversation.
That's the sort of explanation I am looking for to get me going!
Please Log in or Create an account to join the conversation.
Your HAL is set up for jogging with + / - buttons. I don't know if PNCCOnonf knows how to set up jogwheels, but I imagine it would.
So perhaps you forgot to mention the MPG during setup?
Anyway, MPG jogging is handled by pins belonging to the motion module. (You currently have button jogging set up using halui, which is a user-space module, effectively a GUI with no G)
Look at the axis.L.jog-.... pins.
axis.L.jog-counts needs to connect to the MPG counts. Something like:
net jog-counts hm2_5i25.0.7i73.0.0.encoder-00-counts
net jog-counts axis.x.jog-counts axis.y.jog-counts axis.z.jog-counts
And if you want to jog in joint mode too, add those in:
net jog-counts hm2_5i25.0.7i73.0.0.encoder-00-counts
net jog-counts axis.x.jog-counts joint.0.jog-counts
net jog-counts axis.y.jog-counts joint.1.jog-counts
net jog-counts axis.z.jog-counts joint.2.jog-counts
You might well be asking how the system knows which axis to jog if they are all connected to the same encoder? That is where the jog-enable comes in:
net x-enable axis.x.jog-enable joint.0.jog-enable hm2_5i25.0.7i73.0.0.input-00
net x-enable axis.x.jog-enable joint.1.jog-enable hm2_5i25.0.7i73.0.0.input-01
net x-enable axis.x.jog-enable joint.2.jog-enable hm2_5i25.0.7i73.0.0.input-02
And as for the scale? That needs a similar structure, but withoiut knowing how you intend to configure the jog increment settings that is a bit harder to guess.
Please Log in or Create an account to join the conversation.
Your HAL is set up for jogging with + / - buttons. I don't know if PNCCOnonf knows how to set up jogwheels, but I imagine it would.
So perhaps you forgot to mention the MPG during setup?
I have separate jog wheels for X and Z, and an encoder for Spindle speed override ( and for a live tool speed overrride - not relevant now). I have set these all up in pncconf ( in 'advanced setup' mode) and can see all the wheels counters and all the switches I have all toggling in HAL_Show in linuxCNC.
Towards the end of the HAL file I attached some posts ago is the setup related to the encoders - (excerpt below - not complete).
So I am not sure what you meany by me forgetting the mention MPG during setup? Am I missing something? ( quite possible at this stage!)
# ---jogwheel signals to mesa encoder - x axis MPG---
net x-jog-count <= hm2_7i92.0.7i73.0.1.enc0.count
# ---mpg signals---
setp axis.x.jog-vel-mode 0
net x-jog-enable => axis.x.jog-enable
net x-jog-count => axis.x.jog-counts
net selected-jog-incr => axis.x.jog-scale
sets x-jog-enable true
# ---jogwheel signals to mesa encoder - z axis MPG---
net z-jog-count <= hm2_7i92.0.7i73.0.1.enc1.count
# ---mpg signals---
setp axis.z.jog-vel-mode 0
net z-jog-enable => axis.z.jog-enable
net z-jog-count => axis.z.jog-counts
net selected-jog-incr => axis.z.jog-scale
sets z-jog-enable true
# connect selectable mpg jog increments
net jog-incr-a => jogincr.sel0
net jog-incr-b => jogincr.sel1
net jog-incr-c => jogincr.sel2
net jog-incr-d => jogincr.sel3
net selected-jog-incr <= jogincr.out-f
setp jogincr.debounce-time 0.100000
setp jogincr.use-graycode False
setp jogincr.suppress-no-input False
setp jogincr.in00 0.000000
setp jogincr.in01 0.001000
setp jogincr.in02 0.005000
setp jogincr.in03 0.001000
setp jogincr.in04 0.100000
setp jogincr.in05 0.010000
setp jogincr.in06 0.050000
setp jogincr.in07 0.100000
setp jogincr.in08 0.500000
setp jogincr.in09 0.125000
setp jogincr.in10 0.125000
setp jogincr.in11 0.125000
setp jogincr.in12 0.125000
setp jogincr.in13 0.125000
setp jogincr.in14 0.125000
setp jogincr.in15 0.125000
# connect feed overide increments - MPG
setp halui.feed-override.direct-value false
setp halui.feed-override.scale .01
net fo-enable => halui.feed-override.count-enable
net axis-selected-count => halui.feed-override.counts
# ---spindle override signals to mesa encoder - mpg---
net so-count <= hm2_7i92.0.7i73.0.1.enc2.count
# connect spindle overide increments - MPG
setp halui.spindle.0.override.direct-value false
setp halui.spindle.0.override.scale .01
setp halui.spindle.0.override.count-enable true
net so-count => halui.spindle.0.override.counts
Then you indicate:
axis.L.jog-counts needs to connect to the MPG counts. Something like:
net jog-counts hm2_5i25.0.7i73.0.0.encoder-00-counts
net jog-counts axis.x.jog-counts axis.y.jog-counts axis.z.jog-counts
I think this is in my HAL file as above?
But this is not ( I could not find it anyway!)
And if you want to jog in joint mode too, add those in:
net jog-counts hm2_5i25.0.7i73.0.0.encoder-00-counts
net jog-counts axis.x.jog-counts joint.0.jog-counts
net jog-counts axis.y.jog-counts joint.1.jog-counts
net jog-counts axis.z.jog-counts joint.2.jog-counts
What I don't understand is why is the above not in the HAL file? Should this not have been created by pncconf? When I used pncconf to do the setup the result in HAL_Show is that all the connected hardware, encoders, jog wheels, switches are seen.
NOW - a small Eureka moment..
Before hitting submit I went to try some more, as it had been mentioned in some previous posts that I must HOME first else jogging wont work.
I used switches to simulate the home switches, managed to home, and then all jogging works!
The X and Z jog wheels jog fine, using the rates as selected by my 4 position jog step size switch, etc!
The X+,X- and Z+, Z- jog push buttons work ( at rate =1 - where do I change that?) , etc
So I am even more confused now, as the setup seems to work - jogs, etc, but appears to be lacking fundamental enabling statements in the HAL file??
Could I ask that you please explain the jogging concepts in LinuxCNC? I think I am not asking the correct question here, but lack the knowledge to know what I should be asking! What or where are the jog instances that occur in L_CNC - You can jog in 'Axis' and in 'joint' modes? Joint is a 'motor', but that is attached to an Axis and so the axis jogs when you jog the 'joint'?
You said :
And if you want to jog in joint mode too, add those in:
If I did not add 'those' in, what mode am I jogging in? And what moves when jogging then?
Going back to read all the HAL docs again, since it seems the more I learn the less I know!.
Thanks Andy!
Please Log in or Create an account to join the conversation.
If I did not add 'those' in, what mode am I jogging in? And what moves when jogging then?
The concept is this:
When you start LCNC it's in 'joint' mode. Which means the controller has no concept of how your machine is built in respect to cartesian space, in your case which motors (ie joints) have to be run to move the tool along the X axis or the Z axis.
In your configuration there is this:
[KINS]
JOINTS = 2
KINEMATICS = trivkins coordinates=XZ
Which defines the kinematic of your machine as being 'trivkins' or 'trivial kinematics', this is a file containing the mathematical model of how the joints (ie motors) are related to the X axis and Z axis. I your case this relation is 'trivial' meaning movement of joint0 is proprtional to movement of axisX and movement of joint1 is proportional of axisZ. Your machine as most lathes and mills just happens to be mechanically built in a way that the two coincide, this is however not the case with all machines.
Once the homing procedure has been performed and the controller knows where the joints (ie motors) are positioned in relation to the defined limits the mode is switched from joint-mode to
As an illustration:
In my robotic arm there are 6 rotational joints (motors) involved to move the tool in cartesian space (XYZABC) so this uses 'non-trivial' kinematics called 'genserkins'. Here the calculation to derive the tool position and orientation in cartesian space from the positions of the six motors involve multiple matrix multiplications. So here if I jog in joint-mode I rotate the individual joints of the arm, while in '
Once homed and thus in
What Andy means is that in your hal if you replace this:
net jog-counts hm2_5i25.0.7i73.0.0.encoder-00-counts
net jog-counts axis.x.jog-counts axis.y.jog-counts axis.z.jog-counts
with this:
net jog-counts hm2_5i25.0.7i73.0.0.encoder-00-counts
net jog-counts axis.x.jog-counts joint.0.jog-counts
net jog-counts axis.y.jog-counts joint.1.jog-counts
net jog-counts axis.z.jog-counts joint.2.jog-counts
you will be able to jog in joint-mode because the signal named 'jog-counts' coming from hm2_5i25.0.7i73.0.0.encoder-00-counts is not only routed to axis.N.jog-counts that is used in '
The X+,X- and Z+, Z- jog push buttons work ( at rate =1 - where do I change that?)
When you say 'at rate = 1' do you mean it jogs in incremental 1mm moves or at a continuous speed of 1mm/min?
Please Log in or Create an account to join the conversation.
If I may, I need to ask my same question in a different way, given the last paragraphs in your post-
First, do I understand correctly :
Using your robotic arm as example, since the lathe 'joints' are excessively simple,
If you have a motor at the base of the arm (like a music record turntable with the arm sitting on the record) and you rotate that motor,the whole arm rotates about the axis of that motor. So if you jog that motor (joint..) the whole arm rotates, and the tool at the very end of the arm simple rotates around that joint's axis, in a radius equal to the tool tip distance from the joints vertical axis. Thats a joint jog or rotation I believe?
Now if you wish to move the tool tip from a point in 3D space to a new point in 3D space, you have to move ( probably) every joint in the arm to get the tool tip there, in a specific orientation, AND ALONG A SPECIFIC PATH - That is a coordinated move.
If I understand that correctly, then the two modes are actually very simple in concept. But what does that mean then in my simple lathe?
I do not see the same concept existing, since there is no coordinated move when jogging. I understand that if I jog X, then its the same as the jog of that Record Turntable your robot arm is sitting on - just X moves, even if only linearly. If I wish to move the tool tip from an X,Z point to a new one, I can do so by jogging X first till at new X, then Z till at new Z. Is That what is termed 'joint only' moves?
If I wish to get the tool there following a straight line between those two points I have to turn both X and Z handwheels in a coordinated manner so that the tool follows that straight line - That is what the kinematics would do to interpolate the X and Z stepgen pulses to move in a coordinated manner. ( coordinated jogging by hand was just to illustrate my understanding of the concept..)
As I have managed to get the jog to work on my setup after homing, with the HAL file as I posted, and without those HAL statements posted by Andy, what Mode am I actually jogging in? You indicate it is in coordinated mode, but if I jog, its only ONE axis that moves, which is 'joint mode'. So after thinking I understand joint and coordinated moves/jogging, I discover I actually don't!
Please Log in or Create an account to join the conversation.
What makes this a little confusing is that, in your case, the two things are functionally identical because you have a machine with cartesian joints.
But the software is in two different states before and after homing.
(you might start to see a difference if you introduced backlash compensation, or screw error compensation)
Please Log in or Create an account to join the conversation.