Printable View
Hello. Help solve the problem: On a lathe has 3 independent Z axis in sequence on the same axis X.
I need to axes Z1 and Z2 copying but movement of the Z-axis offset by the distance between them. How can you make such a KFlop?
Here is a sample video that I need.
https://www.youtube.com/watch?v=2EaBNVQw9dI
Hi vektor_z,
Interesting how that system works entirely mechanically without numerically controlled paths. Nice music too :)
Seems like the simplest solution would be to just create the proper GCode to drive all the axes properly. That would move the problem from KFLOP to the CAD system.
It isn't clear to me the optimal way to control the feed rate. The video appears to use a constant rate of motion along the part (I think that type of system would be more commonly described as a system with one Z axis and 3 X axes). That seems to restrict them from being able to perform square cuts so there is a need for the special shaped tools . But again any feedrate along the path could be controlled using GCode and inverse Time Feedrate.
I suppose it would also be possible to create a KFLOP type of Slaved axis that would be delayed in time (or position) using a KFLOP C Program. A circular memory buffer could be used to delay the commanded destination of one of the Axes to drive another axis. A buffer of the last 10,000 Z positions would easily fit into KFLOP memory (gather buffer holds 1 million doubles) and could store the path over 1 inch with either 0.1 millisecong or 0.1 inch resolution.
Hi Tom. Thanks for the quick reply.
About the synchronization speed, too, is unclear. After all, the scheduler Kflop linear interpolation, as in the movement to add more slave axes and sync them all the time, I do not know. Maybe you have some ideas?Quote:
It isn't clear to me the optimal way to control the feed rate. The video appears to use a constant rate of motion along the part (I think that type of system would be more commonly described as a system with one Z axis and 3 X axes). That seems to restrict them from being able to perform square cuts so there is a need for the special shaped tools . But again any feedrate along the path could be controlled using GCode and inverse Time Feedrate.
I thought at the expense of such an option, but I could not find the CAM program to create the desired me G code. Such CAM program seems to me there is no ... It is easier to create a standard G code 2 coordinates X and Z axes Z1 and Z2 to manage controller Kflop offset. That's why I asked for help here and I hope you can help me solve this problem by using Kflop. Can write a test with the С program, so I can check how it will work. thank you in advance.Quote:
Seems like the simplest solution would be to just create the proper GCode to drive all the axes properly. That would move the problem from KFLOP to the CAD system.
Hi vektor_z,
Please use the more standardized lathe axis terminology so we use the same terms. The Z axis is normally along the spindle Axis. So you would then have multiple X axes.
I'm thinking the better and simpler way to solve this is to do it at the GCode or CAD level. You didn't answer my question about how you think feed rate should be handled. I think if you generate the proper GCode it will work better than the machine in the Video because the Z axis feed rate will not need to be constant. This would allow square corners. Although it isn't clear to me how well this would work. If stopping or nearly stopping Z to allow one of the X axes to plunge to make a square cut might slow the feedrate of the other cutter too much causing an artifact (burn)?
I would suggest the following approach:
Use some standard CAD package to generate a normal GCode X Z Path as small G1 line segments.
Write a Visual basic, C#, or some other programming language of your choice to process the GCode in the following manner:
#1 read in the Gcode as X Z line segments
#2 recursively subdivide each line segment until it is very small (ie less than 20um long)
#3 save the resulting small line segments into a memory array
#4 output the line segments as a new GCode file
#5 as the new GCode is output include A and B Axis values for the new offset X1 and X2 positions
#6 the X1 X2 positions can be determined by searching backward through the Array to find the first segment with a Z coordinate some OffsetZ distance away, then use the X coordinate of that segment.
Run the GCode in KMotionCNC+KFLOP as a X Z A B Axis system.
What skills do you have? Are you able to write programs? Or do you know anyone willing to do this for you?
Regards
Hi Tom,
OK, I will use a standardized description of the axes of the lathe.
I think that the feed rate should be uniform for the tool, and not for Z axis, but if one of the X-axis will do a straight neckline, the second and third X-axis can slow down or stop, nothing bad will.
An interesting option you suggested about handler standard G code.
I do not know how to program in C, but I can ask a friend.
I understand the logic of the program, but do not understand the step # 2
# 2 recursively subdivide each line segment until it is very small (ie less than 20um long)
Can you explain more about the dividing line?
Regards
Hi vektor_z,
That sounds good. Performing feed rate control through XZAB space (where A and B are linear axes) will not be exactly correct but I think reasonable enough. They will all be treated as orthogonal Axes. So for example if both cutters are plunging at the same time (and the other axes are not moving) then they will both move at 0.707 of the commanded feed rate (as if it was an orthogonal XY motion).Quote:
I think that the feed rate should be uniform for the tool, and not for Z axis, but if one of the X-axis will do a straight neckline, the second and third X-axis can slow down or stop, nothing bad will.
You can divide a line segment into two haves by using the midpoint of the beginning and end of the segment. Below is some KFLOP C Code to do this (also attached as a txt file). The code will repeatedly divide the segment into two haves until it is smaller than a specified threshold.Quote:
I understand the logic of the program, but do not understand the step # 2
# 2 recursively subdivide each line segment until it is very small (ie less than 20um long)
Can you explain more about the dividing line?
Code:#include "KMotionDef.h"
#define MAX_POINTS 300000
#define MAX_ALLOWED_LENGTH 0.1
int pindex=0; //point index
double *Xpoints;
double *Zpoints;
// find line segment length
double FindLength(double x0, double z0, double x1, double z1)
{
return sqrt((x1-x0)*(x1-x0)+(z1-z0)*(z1-z0));
}
// compute mid point
double MidPoint(double x0, double z0, double x1, double z1, double *xm, double *zm)
{
*xm = (x0+x1)/2.0;
*zm = (z0+z1)/2.0;
}
// if segment is short just store it, otherwise recursively divide it and store those
// return 0 if saved, return 1 if error
int StoreDividedSegment(double x0, double z0, double x1, double z1)
{
double xm,zm;
if (FindLength(x0,z0,x1,z1) < MAX_ALLOWED_LENGTH) // short?
{
// yes it is short
if (pindex >= MAX_POINTS) // too many segments?
{
printf("Too many segments\n");
return 1; // return error
}
// yes, save it
Xpoints[pindex] = x1;
Zpoints[pindex] = z1;
pindex++;
}
else
{
// no it is long split it
MidPoint(x0,z0,x1,z1,&xm,&zm);
if (StoreDividedSegment(x0,z0,xm,zm)) return 1; // first half
if (StoreDividedSegment(xm,zm,x1,z1)) return 1; // 2nd half
}
return 0;
}
main()
{
int i,result;
Xpoints = gather_buffer;
Zpoints = gather_buffer+MAX_POINTS;
// put starting point
Xpoints[pindex] = 0.5;
Zpoints[pindex] = 0.0;
pindex++;
result = StoreDividedSegment(0.5, 0.0, 1.0, 2.0); // subdivide and store one long segment
if (result==0)
printf("Segment divided successfully total points = %d\n",pindex);
result = StoreDividedSegment(1.0, 2.0, 0.5, 4.0); // subdivide and store one long segment
if (result==0)
printf("Segment divided successfully total points = %d\n",pindex);
for(i=0;i<pindex;i++)
printf("N%d G1 X%f Z%f\n",i,Xpoints[i],Zpoints[i]);
}
Here is the program output:
HTHCode:Segment divided successfully total points = 33
Segment divided successfully total points = 65
N0 G1 X0.500000 Z0.000000
N1 G1 X0.515625 Z0.062500
N2 G1 X0.531250 Z0.125000
N3 G1 X0.546875 Z0.187500
N4 G1 X0.562500 Z0.250000
N5 G1 X0.578125 Z0.312500
N6 G1 X0.593750 Z0.375000
N7 G1 X0.609375 Z0.437500
N8 G1 X0.625000 Z0.500000
N9 G1 X0.640625 Z0.562500
N10 G1 X0.656250 Z0.625000
N11 G1 X0.671875 Z0.687500
N12 G1 X0.687500 Z0.750000
N13 G1 X0.703125 Z0.812500
N14 G1 X0.718750 Z0.875000
N15 G1 X0.734375 Z0.937500
N16 G1 X0.750000 Z1.000000
N17 G1 X0.765625 Z1.062500
N18 G1 X0.781250 Z1.125000
N19 G1 X0.796875 Z1.187500
N20 G1 X0.812500 Z1.250000
N21 G1 X0.828125 Z1.312500
N22 G1 X0.843750 Z1.375000
N23 G1 X0.859375 Z1.437500
N24 G1 X0.875000 Z1.500000
N25 G1 X0.890625 Z1.562500
N26 G1 X0.906250 Z1.625000
N27 G1 X0.921875 Z1.687500
N28 G1 X0.937500 Z1.750000
N29 G1 X0.953125 Z1.812500
N30 G1 X0.968750 Z1.875000
N31 G1 X0.984375 Z1.937500
N32 G1 X1.000000 Z2.000000
N33 G1 X0.984375 Z2.062500
N34 G1 X0.968750 Z2.125000
N35 G1 X0.953125 Z2.187500
N36 G1 X0.937500 Z2.250000
N37 G1 X0.921875 Z2.312500
N38 G1 X0.906250 Z2.375000
N39 G1 X0.890625 Z2.437500
N40 G1 X0.875000 Z2.500000
N41 G1 X0.859375 Z2.562500
N42 G1 X0.843750 Z2.625000
N43 G1 X0.828125 Z2.687500
N44 G1 X0.812500 Z2.750000
N45 G1 X0.796875 Z2.812500
N46 G1 X0.781250 Z2.875000
N47 G1 X0.765625 Z2.937500
N48 G1 X0.750000 Z3.000000
N49 G1 X0.734375 Z3.062500
N50 G1 X0.718750 Z3.125000
N51 G1 X0.703125 Z3.187500
N52 G1 X0.687500 Z3.250000
N53 G1 X0.671875 Z3.312500
N54 G1 X0.656250 Z3.375000
N55 G1 X0.640625 Z3.437500
N56 G1 X0.625000 Z3.500000
N57 G1 X0.609375 Z3.562500
N58 G1 X0.593750 Z3.625000
N59 G1 X0.578125 Z3.687500
N60 G1 X0.562500 Z3.750000
N61 G1 X0.546875 Z3.812500
N62 G1 X0.531250 Z3.875000
N63 G1 X0.515625 Z3.937500
N64 G1 X0.500000 Z4.000000
Regards
Hi Tom, thanks for the help.
* Now I understand the structure of the construction program, if I even knew C # programming then no problems would write the program ... He turned to friend for help in writing a program, but he is busy, says a little later try to help me.
* I have another question. I need to put on a CNC router where the 6 independent Z axes and one X-axis, and it turns out 7 axes, that's such a machine as video ?????: ????????????-????????-???????????? ?????? FC-6/2500 - ??????@Pro?????? obtained principle of operation is the same as on a lathe with three axes of X, but there is still the other three sides. The G code can only go with one of the first axis and on the other hand, the following axis must first copy the movement offset. Manage all axes through G code does not work because you need to 7 axes and K motion only 6. advise me in this case?
Regards
Hi vektor_z,
You are correct if you change things to 7 Axes then I can't see a simple way to handle it in our 6 axes GCode.
The other approach with the "Offset Z" position algorithm written in a KFLOP C Program may work. You would need to somehow handle the feed rate along the main XZ path in a way that wouldn't exceed the allowed velocities of the "Offset" axes.
Regards
Hi Tom,
As C program will offset Z1 and Z2 axes? Just in time, or the offset with the axis X?
* if time is at a different feed rate X axis will be different penetration length offset Z1 and Z2 axes. Obtain a uniform feed speed X-axis seems to me impossible, since the scheduler KMotion to calculate the feed rate depending on the trajectory of the tool path.
* if C program Z1 and Z2 shifts with the longitudinal axis of the X-axis, I can in the G code after deep cuts Z axis prescribe a lower feed rate to offset axis able to repeat the same low-cut without exceeding the allowable acceleration.
Regards
Hi vektor_z,
The C program will do whatever you program it to do. But yes, I agree the C Program should save the Z position as a function of X and replay the Z to the Z1, Z2 positions as function of shifted X.Quote:
As C program will offset Z1 and Z2 axes? Just in time, or the offset with the axis X?
I agree uniform X speed would be difficult. Maybe not impossible if you calculate the feedrate differently for each segment along the path in order to keep the x direction constant. There may still be some slight acceleration errors. And also as we discussed before the X speed should really not be constant to allow sharp cuts.Quote:
if time is at a different feed rate X axis will be different penetration length offset Z1 and Z2 axes. Obtain a uniform feed speed X-axis seems to me impossible, since the scheduler KMotion to calculate the feed rate depending on the trajectory of the tool path.
Yes, you would probably need to do this.Quote:
if C program Z1 and Z2 shifts with the longitudinal axis of the X-axis, I can in the G code after deep cuts Z axis prescribe a lower feed rate to offset axis able to repeat the same low-cut without exceeding the allowable acceleration.
Regards
Hi Tom,
Glad to hear it. Can you help me write a C program to Kflop, or can you have any examples of writing C programs to offset the Z axis. I can write a C program only examples, combining them and inserting the appropriate values.Quote:
Originally Posted by TomKerekes
What do I need for this?
Regards
Hi vektor_z,
If you contact our support we can give you a quote for writing the custom software needed for your machine. Otherwise we can answer specific questions to help. The example that we already provided for you could be a basis for what you need. That code could create a tabular record of the Z positions and then play them back out to the other axes in a delayed manner.
Regards
There are only 5 axis at most in that video that I can tell. A Z axis along the length, three X axis and a possible spindle axis (the spindle speed appears to change dynamically, but really hard to tell for sure to what degree from the video). The additional "axis" are really what you would do with an M code, not an axis. You can get servo driven programmable rams that would move those finish profile cutters into position at a programmed speed and then back again just with a signal triggered by M code. Since the cutter only has to go to a fixed position and then back, there is no need for an axis. You could even use a pneumatic ram, but I think having the option to program the distance specifically as well as the feedrate with a servo driven ram would be more useful. Setup would be a pain to change between parts (you'd have to reprogram each ram each time), but once you are set up, you could run a ton of parts reliably. It would even make life easier if there is a micro adjuster on whatever plate the ram is mounted to, so that you can fine tune the destination point without reprogramming (would be handy when changing cutters with the same as they dull or after a resharpening).
In theory, you don't even strictly need to use an M code either. If you did it like an edgebander (which uses saws to trim the front and back of the edgeband), you could even just use a roller switch that signals the finish profile ram to operate. This would prevent collisions with the multi-cutter carriage if done right, since the carriage would physically have to be out of the way to trigger the motion.
As for programming, I would go a completely different route. You can see that the machine they have uses a copy carriage to follow a template. The easiest way to program X,X1, and X2 simultaneous motion would be to record the positions along a template manually or digitally. Essentially, a point cloud recording of where the cutters are in relation to the profile at all three positions simultaneously. This really could be done manually since the cutters are only roughing cutters. The final surface is generated by the stationary profile cutters anyways, so the precision of the roughing just has to be OK, not perfect. You could hand code this program in a couple hours once you set up your template measuring device/system. I'd use three dial indicators mounted the same distance apart, move them over .perhaps 1 mm at a time and take a reading at each position. There are significant gaps between profiled regions in what the video shows, so you'd just be recording perhaps 400 points of data per design. I would guess they are just getting the stock down to an average of .5mm remaining, so the roughing tolerance would not have to be that tight and 1mm straight line moves should be plenty good.
If you really have the budget for it, you can probably make a digital capture device to record the motion of all three cutters at intervals along a template instead of recording the data manually, which would give you quite a high degree of resolution. If you really were doing this as a production type machine, I don't know that it would be worth it over hand programming since you shouldn't have a lot of custom shapes. If you aren't doing production, then I really don't see any sense in using three cutters that require custom programming as opposed to just running an extra two passes with the first cutter that could be programmed in any off the shelf lathe CAM software. You'd only be saving a few minutes on each unit, which just doesn't add up enough unless it's a production run of thousands.
Just my thoughts.