Developments on my Home built 5C CNC Lathe - Polar interp. and Live tooling

More
09 Nov 2021 08:10 #225787 by NoJo
We have resolved the issues we had with Switchkins and now have our Polar interpolation component working well on the lathe's C axis..
Thank You DGarrett and Aciera for your assistance in this regard.

The tool changer on the lathe has 8 peripheral tools, with a 9th axial live tool in the tool change axial center.
I need to apply standard tool offsets to place that tool's position and need access to the tool offset info,etc.

(1) I am needing to access the value G54_X (as stored in variable 5221) from within my polar interp / C axis component. I have not found a way yet.
   Can someone advise / suggest how I can access it?
(2) I am needing to command the C Axis to do the homing function from within my component. How can I generate that request? 
 

Please Log in or Create an account to join the conversation.

More
09 Nov 2021 09:01 #225791 by andypugh
I think that the fact that the live tool is in the middle of the changer shouldn't matter. It should work just like any tool, but with a bigger X-axis offset in the tool table.

Is the C axis already part of the homing sequence? Is there any reason that it can't home just like any other axis?

Please Log in or Create an account to join the conversation.

More
09 Nov 2021 16:32 - 09 Nov 2021 18:16 #225855 by NoJo
To clarify our needs:

The reason we want access to the G54X value is as follows : 
When in polar mode (ie after a G12.1 gcode) the functions kinematicsInverse and kinematicsForward need to perform the cartesian to polar and polar to cartesian computation respectively. These computations must be performed by translating the X axis position to be centered around zero, do the computation and then translate the X axis position back to the G54_X offset.
For example, the computations for kinematicsInverse are as follows. (Note that the tool_offset variable must be the G54_X value.
Currently we have hardcoded this value - which is not ideal as the offset may change...):
        // G12.1 mode : j[0] is x, j[2] is C : do cartesian to polar conversion
        // j[0] set to radius, j[2] set to angle_deg
        xVal = pos->tran.x - tool_offset;
        cVal = -pos->c;  // take -ve as want CW rotation for +ve C value
        radius = sqrt((xVal * xVal) + (cVal * cVal));
        j[0] =  radius + tool_offset;
        j[2] =  atan2(cVal, xVal) * 180.0 / M_PI;

The reason for wanting access to command C Axis Home is that prior to exiting the polar mode with G13.1, we need to ensure that all axes
are at zero.( This appears to be the convention in Gcode structure - enter G12.1 with C @ zero, and exit likewise.) In the case of X and Z, we can just command a move to zero( G53, etc). We could do the same for C, but this can be very tedious, as when in C Axis mode, if the axis has for example done several full revolutions, the current position may be say 4*360 = 1440degrees! So to command zero now means the axis will unwind 1440 degrees ... which can take a long time. Hence to command the axis to home rather than unwind is the preferred method
 
Last edit: 09 Nov 2021 18:16 by NoJo. Reason: added statement re Convention..

Please Log in or Create an account to join the conversation.

More
10 Nov 2021 03:13 - 10 Nov 2021 03:17 #225915 by dgarrett
Homing is not applicable in coord mode (gcode) as it is
a joint operation that sets motor position offsets.
Coord mode operates in world space (xyzabcuvw) and
has no information about joints.

In gcode, you can offset when required (instead of
unwinding) so that a subsequent move-to-zero is at most 360
degrees:

g10l20p0c[#<_c>mod360] ;offset so that: 0 <= c <= 360
g0c0
Last edit: 10 Nov 2021 03:17 by dgarrett.

Please Log in or Create an account to join the conversation.

More
10 Nov 2021 12:48 #225977 by NoJo
I have experimented with the use of G10L20 and have found that as a result of the G10L20P1C0 (which has the desired effect for the current run), the G54C value is set to the current C Axis position (eg -360.0)
So when I next startup I start with this offset value, which is not desirable. I do not want to each startup first need to manually restore the G54C value to zero.
Do you see a wat around this?

And any ideas on my second question re accessing the G54X value from my component?

Please Log in or Create an account to join the conversation.

More
10 Nov 2021 14:47 #225990 by andypugh

So when I next startup I start with this offset value, which is not desirable. I do not want to each startup first need to manually restore the G54C value to zero.
Do you see a wat around this?


Possibly with an RS274NGC_STARTUP_CODE
linuxcnc.org/docs/2.8/html/config/ini-co...l#gcode:ini-features

And any ideas on my second question re accessing the G54X value from my component?


Not yet, though you might be able to work around it with WRAPPED_ROTARY linuxcnc.org/docs/2.8/html/config/ini-co...lt_letter_gt_section

Please Log in or Create an account to join the conversation.

More
11 Nov 2021 19:39 #226132 by NoJo
Thanks Andy. We have solutions to both items - it appears to be working OK. Take care of the C axis zeroing etc in the C axis component and within G12.1 - works well.
Currently using a stripped down Master branch compiled as rip - no tool changer in, etc so including all the modules again and will build and do more tests tomorrow.

Please Log in or Create an account to join the conversation.

More
15 Nov 2021 10:40 #226565 by NoJo
Is it possible to set a value in a switchkins component using a 'param'? In other components we have done we have used a statement such as
param rw s32 extend-sensor-timeout = 5000
in the component .comp file, and then set the actual  required value in the hal file using:
setp jntoolchanger.extend-sensor-timeout 1000.

When I try do the equivalent in my kinematics component, and do the halcompile I get the following error.  The halcompile error goes away if I do not actually use the value in the kinematics component, but then linuxCNC will not start as the link between the reference in the hal file and the actual parameter is not found.

If this way of setting a value in the kinematics component is not possible, is there another way I can achieve the same functionality?
 

 
Attachments:

Please Log in or Create an account to join the conversation.

More
15 Nov 2021 14:15 #226579 by dgarrett
post the file that fails (helpers are not clairvoyant)

Please Log in or Create an account to join the conversation.

More
15 Nov 2021 15:10 #226581 by NoJo
Files attached. Last line in hal file. Parameter g54Xparam in gn_userkins.comp
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 0.385 seconds
Powered by Kunena Forum