Question : 5axis simultaneous setup in LCNC

More
18 Jan 2019 11:00 #124394 by andypugh
The Axis Preview assumes that the centre of rotation is the G-code origin. There is no way to tell it differently, so it is rarely accurate with 5 axis G-code.
It can still do the job of giving you something to look at to spot rapids through the stock and that sort of thing.
It isn't easy to think of a good way to inform the preview of the true rotation centre. Possibly it could be done with a "magic comment" in the G-code.

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

More
18 Jan 2019 11:57 #124396 by KevKim
ahhhh got it.
Tnx a lot, I learned one more thing today.
It seems like current state is the best that I can pull unless someone modify the source code and make input windows for the offset values of rotational axis coordinates.
A'way, very well ackowledged and I appreciate it.

regards,
Kevin

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

More
18 Jan 2019 16:20 - 19 Jan 2019 00:23 #124405 by KevKim
One last question about kinematics...if anyone can answer me..

Sample gcode(impeller) is displayed in preview window perfectly, and runs with sample kinematic model perfectly while my cam generated 5axis motion displays normal in vismach window only.

So I can guess gcode should be generated upon a specific rule.
What is standard procedure to generate gcode to be used in kinematics model?
is it xyz and conversion into 5axis or xyzac on a specific machine setup and then conversion into more generalized machine?

Either way, there should be a conversion step between two, is that right?

Kevin
Last edit: 19 Jan 2019 00:23 by KevKim.

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

More
18 Jan 2019 23:54 #124423 by Leon82
I have experience with the matsuura mx 520 at work. While not Linux in 5 ax there are ways to program
TCP and twp(tilting work plane fanuc) the kinimatics are mapped in the machine and you can program where ever you want and set the work offset, even if it's way off center. Our programs run on the 520 and 330 with no changes to them even though they have a different table offset from the center of rotation.

Now if we wanted to program without TCP or twp we would have to change the location of the part in the cam system and Regen the program, or use many work offset.

So if you are able to get TCP working, it is the best way
The following user(s) said Thank You: KevKim

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

More
19 Jan 2019 00:21 - 19 Jan 2019 00:22 #124424 by KevKim
tnx for quick response Leon,

I am very new to these stuffs, though I have used simple xyz machine with a basic template a few yrs ago, never digged deep into LCNC at that time. It's been like one week at the moment that I started this study so please forgive my lack of understanding...

I have read many ppl talking about TCP and I do not know what that is. Google returns this page whenever I searched for LCNC 5axis kinematics ;
linuxcnc.org/docs/devel/html/motion/5-axis-kinematics.html
and that page looks like a study page to me, nothing is executable there.
Does TCP mean some high level math that needs to be implemented by the form of programming language? Any sample TCP module available that I can start playing with?

Kevin
Last edit: 19 Jan 2019 00:22 by KevKim.

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

More
19 Jan 2019 01:17 #124425 by Leon82
Every machine tool builder calls it something different but it it tool center point or tool posture control.
The control, knowing where the center of rotation is, can go from a0c0 and map the position thru the rotations. So you would only use one worknoffser g54 for example.

On the fanuc controller it is rather interesting to watch the number as it moves. Our machine has a trunion so the spindle is fixed. At a-90 in TCP when the physical y axis moves the z axis in the controller is moving.

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

More
19 Jan 2019 01:37 - 19 Jan 2019 01:38 #124426 by Leon82
So linux cnc needs to know the center of rotation.

The distance e from z0 to the center of rotation. The distance from the COR to the face of the table. And also the x and y position of the COR.

Then it needs to use those values to calculate the position of where the program tells it to go. There is logic somewhere, i have no idea where however. I just know how much easier it makes programming
Last edit: 19 Jan 2019 01:38 by Leon82.

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

More
19 Jan 2019 03:25 #124430 by KevKim
right,
I saw that action in vismach simulation model and that's exactly what I am wondering about at this moment.
To make such behavior useful, with what kind of tool do I have to make the g-codes? I don't think machine-specific cam software will do that for me, and that is the main question.
Once I digged it, it goes deeper and deeper which is embarassing >.<

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

More
21 Jan 2019 10:22 #124518 by andypugh
The Vismach / Impeller sample is TCP G-code running in a TCP Kinematics.

TCP means that the C-code XYZ is the position of the tool tip in XYZ space, and the tool ABC is the angle that the tool axis makes to the XYZ coordinate system So it is tool position and too tilt.

In non-TCP G-code the XYZ position looks very much the same, but it is axis position commands (with a trivkins machine this is pretty much exactly the same thing) but the ABC commands move the tilt axes directly.

It is probably easier to think of the difference by considering a robot arm. You can imagine programming the tool tip position either as an XYZ position + orientation in space, or program each joint of the robot individually. And in the latter case the limitations of G-code mean that you would need to still use XYZ ABC to program the joint positions regardless of the fact that they don't directly map to XYZ cartesian positions in space.

TCP G-code is a lot more portable, One program should work in all machines.
Joint-based G-code will only ever work in the machine it was created for, and furthermore the CAM system needs an exact internal model of the machine in order to make the G-code.

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

More
21 Jan 2019 14:50 #124548 by KevKim
ahhhh

I think I grabbed the concept.
Cam-output from an imaginary setup having rotational axis at zero will produce the Gcode and that gcode will work with tcp kinematic machine each having their own offset settings, is this correct?
I'm gonna try this with a virtual machine setup in solidcam.

regards,
Kev

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

Time to create page: 0.135 seconds
Powered by Kunena Forum