Advanced Search

Hi Arciera,

optionally create feed optimized roughing paths
You mean, check until a minmal given feed is valid over the path? This feed input creates the fillet size's?
This is holy grail? Haha.

Regarding spline roughing.
I'm not sure if you envisioned using the filleting algorithm to optionally create feed optimized roughing paths but if you did this we could then abandon the max-deviation value and use a minmal-curvature value instead. The algorithm would then increase the trim-back until either
a) minimal-curvature value is reached
b) one of the original path segments gets too short.

Hi Arciera,

The G64 P.. value stands for max path deviation.

Current implementation uses the P value as a trim value for corners and then
create fillet. This results in a deviation less then should be.

It's done this way for now, to keep it simple and get things to work. Adding loops to the code to get as close
to the real path deviation is possible for sure. This code change is on the todo list.


say 25%, 50% and 75% of the total length of the trimmed segments and compare those to the 3d coordinates
Path deviation check at progress t=0.5 of the fillet segment to original path is ok to find closest value of P..
If that is what you mean?

I don't think this is practical as the operator would have to keep this in mind for every possible machining operation.
Yes, and on the other hand, i showed an exceptional case. Normally a travel height would be like 1 up to 50mm and
a G64 P0.01 for the fillets. This will not be a problem at all.

Here we tested a velocity profile based on current curvature along the path.
The red line is a interpolated velocity offset along the path based on the shape's curvature input.
This is interesting.

*Note that the line has zero curvature and speed is constant.
*Note in the lower left of the picture the red line has sharp transition corners, this has a reason i figured out.
The maxvm for the path is set at 250. The clothoid at curvature=0, may have a higher speed and it lowered down.
This results in a sharp speed transition edge.

 

This should also solve the current problem that the angle between two path segments will greatly influence the deviation of the fillet to the original path. With a constant trim-back value and a decreasing angle the fillet moves further and further away from the intersection point.
While a constant maximum deviation will create a shorter fillet with higher curvature. This will of course mean a decrease in tool velocity but brings the necessary certainty about maximum path deviation.

Also I wonder if the trim-back length could be the variable driven by the max-deviation calculation result:

Start the iteration with a very small trim-back value and increase until either
a) the deviation exceeds the maximum set by the P value
b) one to the original path segments gets too short

Hi,
You should add the correct values for idProduct and idVendor.
The values You entered are not listet by lsusb.

Regards, hanskuster

Regarding the calculation of maximum path deviation, I wonder if it were enough to calculate the 3d coordinates at say 25%, 50% and 75% of the total length of the trimmed segments and compare those to the 3d coordinates at the same percentages along the replacement clothoid/spline. Then calculating the 3d distances between the resulting pairs of points would be easy.

One solution: In cam programs, the travelheight has to be at least the G64 P..

I don't think this is practical as the operator would have to keep this in mind for every possible machining operation. Checking the filleting result in a GCODE file with thousands of lines is simply not possible and even if this were a settable global cam option it would mean that a change in G64 P value required running everything through the CAM again.

The G0 z line from z1 to z0 is 1mm. This line is then trimmed by the algo on both sides
back to minimal lenght ~0.001mm, as it can not be trimmed back 20mm.

So, if the algorithm realizes that the segment cannot be trimmed by the required distance it would seem possible to handle these cases separately. Either just don't create a fillet at all or create a fillet with a bigger curvature.

Something else I would like to ask is the meaning of the P value, currently it seems to be the distance a segment is trimmed back but really what the operator wants to know is the maximum deviation from the end/start point this is going to create. In the papers I've read about filleting algorithms the process is actually iterative. After a fillet is created the maximum deviation is calculated. If the deviation is over the acceptable limit the filleting parameters are changed, the fillet is created again and the deviation is again checked. This runs until the maximum deviation is below the limit (ie below the P value).
To be honest, I have no idea how difficult it is to calculate the maximum deviation a clothoid fillet creates from the original line segments but without the ability to precisely define a maximum value for path deviation I'd be _very_ reluctant to use a filleting algorithm.

Hi,

When the travelheight is 20mm and the fillet radius is 20mm the result is valid :
 

When travelheight is 1mm and the fillet radius is 20mm "G64 P20",
The G0 z line from z1 to z0 is 1mm. This line is then trimmed by the algo on both sides
back to minimal lenght ~0.001mm, as it can not be trimmed back 20mm.

The attached line on the xy plane, the next gcode line,
is long enough to be trimmed back 20mm on both sides,
so when this happens, the clothoid curve will go below the xy plane in z.

Technically this is correct to do so for the algoritme. In practical sence this is unwanted for the workpiece.
As it damages the surface.

One solution: In cam programs, the travelheight has to be at least the G64 P..

Another solution: In the fillet algo, we could measure the rapid heights for G0's rapids and use this as a max for the G64 P.. value.
We have to do this for each plane, G17, G18, G19. But then still if you use G1 rapids, it still create's a fillet that
damages workpiece.

If your problem is to only view LinuxCNC on Windows and you are not interested in the desktop of the Linux machine I recommend using an X-Terminal like MobaXterm
mobaxterm.mobatek.net/

Alternatively you can see how this new feature works

www.raspberrypi.com/documentation/services/connect.html

 

I just tested it. Changing the fifth axis to B or C axis will also change the corresponding picture. Perfect, great

Channel conflict was the issue. Bug fix release now available in the repo. Tested with standard stepgen and DMA stepgen with NVMPG.

github.com/scottalford75/Remora-RT1052-c...ora-rt1052-3.1.3.bin

Please share any issues. Thanks

Well, it depends:
For coordinated moves in X,Y and/or Z there is advanced lookahead but for a coordinated move that includes any other axis letter ie (A,B,C,U,V and/or W) the trajectory planner falls back to one line look ahead where short segments can be problematic.

No need it's all done via the ini settings automatically now, it's up and running all sorted out! Enjoy

hanskuster wrote:

Hi all, hi scotta,
I still have a problem with my NVMPG, like in forum.linuxcnc.org/18-computer/44828-rem...rd?start=1710#298883 already stated. I have the same behaviour.
I can control the axis with the NVMPG, switch the axis and scales, but I don't see anything useful on the NVMPG.
Did someone succeed in making the display work?
I use a EC500 with the firmware Remora-RT1052-cpp version 3.1.2.

Regards, hanskuster

Some good news. I've found what's broken the NVMPG... just need to figure out how to fix it. The DMA stepgen implementation is the issue with most likely a channel conflict or something happening..... head scratching time.