Kinematics for XYZAB mill
13 Feb 2023 13:47 #264430
by Aciera
I'm not very familiar with the internals of the trajectory planner but I believe, as you say, that it does indeed calculate everything in machine coordinates, so it strips the offsets from the input and adds them back to the result.
Replied by Aciera on topic Kinematics for XYZAB mill
The work offset (eg G54) does not influence the rotation center. You can set your work offset anywhere you like. The rotation center is defined by setting the 'rot-point' values that define the offset of the rotation point from machine zero. Without the 'rot-point' offset the center of rotation is the machine reference point.3. The kinematics module using switchkins assumes the G5x coordinate frame has its origin at the rot_point offset which is given in the original machine MCS coordinate frame. This is done by setting the G54 offset to the rotation center point at the start of the Gcode in the example NGC file made by Aciera in the XYZAB sim config.
I'm not very familiar with the internals of the trajectory planner but I believe, as you say, that it does indeed calculate everything in machine coordinates, so it strips the offsets from the input and adds them back to the result.
Please Log in or Create an account to join the conversation.
13 Feb 2023 18:45 #264449
by Aciera
Replied by Aciera on topic Kinematics for XYZAB mill
I suggest that for a clearer picture of how offsets are applied in respect to the kinematics component you add an 'rtapi_print' statement to the kinematic component so you can monitor the values of 'pos->tran.(x,y,z)' which is the coordinate position used in custom kinematics.
Please Log in or Create an account to join the conversation.
22 Feb 2023 07:22 #265015
by automata
Replied by automata on topic Kinematics for XYZAB mill
Just found a paper that talks about making a post processor: "A postprocessor for table-tilting type five-axis machine tool based on generalized kinematics with variable feedrate implementation"
www.researchgate.net/publication/2573371...drate_implementation
It talks about redundancy resolution for selection of B and C axis angles and also talks about re-sampling the tool location data points from the CLData for a higher resolution output using spherical interpolation for the tool orientation vectors.
-automata
www.researchgate.net/publication/2573371...drate_implementation
It talks about redundancy resolution for selection of B and C axis angles and also talks about re-sampling the tool location data points from the CLData for a higher resolution output using spherical interpolation for the tool orientation vectors.
-automata
The following user(s) said Thank You: Aciera
Please Log in or Create an account to join the conversation.
18 Mar 2023 12:31 #266989
by HansU
Can we add that document somehow to the documentation?
Replied by HansU on topic Kinematics for XYZAB mill
As promised the document to the XYZAB-TDR kinematics:
C
Can we add that document somehow to the documentation?
Please Log in or Create an account to join the conversation.
18 Mar 2023 16:20 - 18 Mar 2023 16:27 #267013
by Aciera
Replied by Aciera on topic Kinematics for XYZAB mill
As far as I'm concerned sure.
But from what I understand about the build process for documentation an asciidoc format would be preferred to a PDF as that is automatically built in the LinuxCNC build process. While I can export the jupyter notebook in asciidoc format all the math is spit out as 'latexmath' which in turn does not show in the auto built documentation (I think). So looking at other mathematical documentation (like Rudys trt-kinematic docs) the math formulas seem to be cut out of the pdf as images and then pasted into the asciidoc document and that is a lot of work for which I have not had time or motivation. If there is a less time consuming way to add it to the documentation please advise.
This is the raw export as asciidoc:
Note how the math from the python output is not included as latexmath at all so that would have to be reentered manually which is real pain.
But from what I understand about the build process for documentation an asciidoc format would be preferred to a PDF as that is automatically built in the LinuxCNC build process. While I can export the jupyter notebook in asciidoc format all the math is spit out as 'latexmath' which in turn does not show in the auto built documentation (I think). So looking at other mathematical documentation (like Rudys trt-kinematic docs) the math formulas seem to be cut out of the pdf as images and then pasted into the asciidoc document and that is a lot of work for which I have not had time or motivation. If there is a less time consuming way to add it to the documentation please advise.
This is the raw export as asciidoc:
Note how the math from the python output is not included as latexmath at all so that would have to be reentered manually which is real pain.
Attachments:
Last edit: 18 Mar 2023 16:27 by Aciera.
Please Log in or Create an account to join the conversation.
Time to create page: 0.079 seconds