Oh Great. Now I undersand. I always tried to setup the Stock by job-Dialogue.
Now, doing this by the parameters directly, it is a charme. Also I undersand that it is not possible, to wrap the stock in the correct way by dialogue. I didn’t get it and as soon as I change the stocks ange and axis by parameter it works nice.
Thank you for explaining, relaly nice!!! And at least, thank you for debugging!
Might be slightly off-topic but didnt want to make a new thread.
Is it possible to do 4-axis indexing programming in Path? The axis dressup feature seems to only take a radius as input therefore making it suitable for round objects only.
Thanks
The original post mentioned “engravement” which reminded me of Axis Wrap. The actual goal was more complex.
As a simple example of indexing imagine a square post cut from a round pole. Logically it would be a face path > rotate 90 degrees > repeat face path > etc. As far as I’m aware these rotations must be manually added into the g-code.
cylinder_rs.png
For an another simple example a hex from a square post. Here the amount of stock to be removed varies so it may be face path > rotate 60 degrees > an altered face path > rotate 60 > etc. Again the rotations are manual edits.
hs_rs.png
hs_tp_rs.png
In both examples the rotational center is the origin. These examples are 2.5D paths rotated, not 3D paths.
If that does not answer the question bmsaus4ax has a good grasp of this topic and will spot your post.
Thanks jbraun, what you showed pretty much sums up my suspicions with the software. Indexing isn’t too complex so I don’t mind having to stitch together code. I suppose each setup in path would correspond to a particular side to machine, and I can just stitch them all together, adding in the A axis rotation.
I suppose it will all be integrated eventually but this workaround is fine for me. Axis wrap can work for the circular stuff I need.
Cheers
Hello everybody,
after playing around, doing some fun stuff, I found an easy solution to handle my originally problem of the 4th axis mapping.
After loads of testing, the most suitable way for me, was to use “curves” addon. This will bring up the function “Sketch on surface” which will do exactly what I need for dummies (or old sinumeric minds) Anyway, I guess there will be a nice solution in FreeCAD itself in future as it is a very common functionality.
This helpes me a lot. Just to complete
1.png
I just started playing with 3D Surface and I’m wondering what people actually use this on.
LinuxCNC only accepts angular units for a rotary axis but it seems that the output must be in linear units?
The angle is in comments but the only way I can make sense of those A-axis movements is if they are in inches. I don’t see a way to change this behavior. I attached the Gcode of a part that runs the first op with the drop-cutter direction in X, the 2nd op with it in Y. I did this to try to work around another issue I saw. I attached the Gcode from the part I was working on. The first op has the drop-cutter direction in X, the 2nd op has the drop-cutter in Y.
With drop-cutter in Y the feedrate changes with the part diameter. I have the tool horizontal set to 6in/min and the feedrate starts @ 12in/min. by the time its at final depth, about 1/2 the diameter…the feedrate is at 200in/min? Where is the feedrate actually coming from? It doesn’t correspond with anything.
I dried to work around this on this program my first running along X with multi-pass, then in Y with single pass. Unfortunately that doesn’t help since the A movements are in inches and in practice when it thinks it’s moving all the way around the part, it’s actually only moving a tiny amount and then moving back.
I know this is an “experimental” operation but it’s implemented so oddly. I’m a little surprised I don’t see any of this mentioned here.
Microscope camera arm adapter OP2.txt
Could you post the .FCStd file you are using, and FreeCAD version info. See https://devtalk.freecad.org/t/important-please-read-first-before-asking-for-help/1295/1
The A-axis figures appear to be the real state of the g-code, the comment angles are out of context with them.
If the g-code is run in NC Viewer the machined angle appears to be about 7 degrees either side of zero , in rotation axis.
.
NC Viewer is at https://ncviewer.com/ if you are not familiar with it. The internal FreeCAD simulator will not display rotation of path.
.
Screenshot from 2023-11-16 19-36-22.png
.
The feed rate can be affected by the unit settings in preferences, this would be easier to assess with your file also.
Well it’s good to know it’s not supposed to be like that. I can’t find any other CAM that does 4th axis and runs on Linux so hopefully we can get this worked out.
Microscope camera arm adapter.FCStd
I would guess the postprocessor does not really know how to deal with angles. It seems to be treating the numbers as mm and dividing by 25.4.
Multiply the angles by 25.4 and you will have angles in degrees that match the comments.
No doubt this can be done with an easy modification to the postprocessor.
(I suspect this sort of difficulty is the reason the 4th axis work was paused.)
Gene
That’s a good observation and you’re right. Removing the --inches flag from the postprocessor argument and the mm output has the A angle from -180 to 180. Any tips on how I can modify the LinuxCNC post to fix this? I am NOT a Python guy, or any other code for that matter. I would assume for someone who knows what they’re doing it would be pretty trivial to ignore A, B, C axis when converting
I’m not very familiar how most machines handle the rotary position but mine is setup as a “wrapped rotary”, it’ll run infinite degrees in either direction so It’s a bit odd to see the 180degree split. That might be normal, I can probably reconfigure the A axis in LinuxCNC to fix this but is that a part of the postprocessor too? All things being equal I suppose I’d expect it to run 0-360 and only invert the sign to reverse.
I have attached a modified linuxcnc post processor file that reverts the 4th-Axis to continuous rotation. This was the original operation, the 0 to 180:
0 to -180 action has come in since the code restructuring a while back. ( Post processor problems are still appearing as more people try features )
If you put this in your local directory ( I use Macro under .FreeCAD directory/Folder ) and select as Job Output processor it should solve that issue.
I also found I could not edit the Job or Operations in the OP2 ROTARY Job of the uploaded file , but a newly created Job was fine,
For those interested:
In the distributed file at line 359
for c in PathUtils.getPathWithPlacement(pathobj).Commands:
In the modified file reverted line 359 back to pre-restructure :
for c in pathobj.Path.Commands:
Will need to follow up with developer as to other side effects.
@LarryWoestman
.
Thanks for the help.
I have no idea why the surface OPs keep locking out, that’s the 2nd time that happened. It’s an easy enough op to setup so no big deal.
I gave it a try, takes care of the 180deg thing, is there anything that can be done about the other 2 issues? The --inches argument still converts the A axis angle and the feedrate still gets out of hand, I’m not even sure where that feedrate comes from. Can these issues be fixed in the postprocessor?
G1 X-25.000 Y0.000 Z20.000 A-255.816 F3027.412
is scary
G1 X-18.750 Y0.000 F3027.412
is even more scary
It looks like when this was written someone was trying to impliment some sort of surface speed thing by increasing the feedrate as the diameter decreased. The slow feedrate of a rotary axis is an issue that comes from the NIST gcode standard, which it seems like whoever wrote this was trying to work around. I’ve seen this discussed many times, the common solution if the CAM is just outputting the tools set feedrate is to use a filter or converter program to convert it to G93. IMO until the devs get around to having a reasonable way to adjust rotary feedrates, they should just stick to the tool feedrates. There are free programs to handle this (RapidRotary).
For the time being I might be able to get a useable gcode file from this, the feedrate only changes each time there’s a stepdown do I can just find/replace that. If the angle-inch thing can’t be fixed in the postprocessor maybe someone can help me with a regular expression to multiply the angle by 25.4 to undo the effect of --inches. I use Kate editor which will find and replace with a regex but I’m about as clueless with that as I am with Python
I will try to test with old and new code, I never normally use inches.
May take a few days, weekend tends to be busy.
Just as a side note, I used to work with Mazak Mazatrol and it used radians for rotary feed rates.
LinuxCNC can use degrees, radians, or gradians internally but AFAIK RS274 NGC (the NIST Gcode standard) only allows for degrees. I’m not a CNC expert, I’ve only used LinuxCNC on various machines but the NIST standard is also “wrapped rotary”
2.1.2.2 Rotational Axes
The rotational axes are measured in degrees as wrapped linear axes in which the direction of
positive rotation is counterclockwise when viewed from the positive end of the corresponding X,
Y, or Z-axis. By “wrapped linear axis,” we mean one on which the angular position increases
without limit (goes towards plus infinity) as the axis turns counterclockwise and deceases without
limit (goes towards minus infinity) as the axis turns clockwise. Wrapped linear axes are used
regardless of whether or not there is a mechanical limit on rotation.
Clockwise or counterclockwise is from the point of view of the workpiece. If the workpiece is
fastened to a turntable which turns on a rotational axis, a counterclockwise turn from the point of
view of the workpiece is accomplished by turning the turntable in a direction that (for most
common machine configurations) looks clockwise from the point of view of someone standing
next to the machine.1
A fella on the LinuxCNC forum helped me get a workaround into this PP script. It basically just re-converts the A axis values if --inches are in effect. I think I can run the output after I manually alter the feedrates which shouldn’t be too difficult.
linuxcnc_full_rotation_4axis_post.py
Yeah, surface has some kind of bug. It just locked me out of editing the operation again. This will be the 3rd time I deleted it and started over. Since this isn’t in active development should I even bother with a git issue?
Yes that solves it for this PP, the point where this is happening in the program code will still need to be tracked down to solve it for all PP’s or each one will need a similar edit.
I am getting the feed rate output correctly for the X dropcutter Op ( 6 in/min), and just under double the rate for the Y dropcutter ( 11.5755 in/min ) still a problem there.
I am not having problems getting locked out of Operations except for that particular Job in your uploaded file.
I went back an edited this post like 20 times so hopefully I don’t say anything confusing or contradictory here…
As for getting locked out, you don’t get locked out of OP1 right? It’s the same setup just no surface op. If you set surface to multipass along Y it will lock you out eventually. I’ve deleted all the operations several times and it always eventually locks up.
This is actually probably a good part to use for reference for the surface operation, it exposes alot of the issues that might crop up.
I edited all the feedrates by hand which wasn’t an easy (or safe) task on a program with 31k lines. I’ll attach my original output to the post.
When I setup the surface ops it always says “no gaps detected” I didn’t really think much of that but then I realized that when it gets down to the height that the flats start, it runs the cutter all the way down to the bottom of the pocket/flat in 1 pass ignoring the stepdown. I assume that the “gap” thing is supposed to fix this? I didn’t notice this right away because I cleared the deeper pocket in the first operation but if I didn’t it would have been bad. I eventually ruined the part when I ran it because I didn’t realize this was happening and I didn’t clear the flat on the other side. and it tried to sweep across it in a single pass.
Another issue is it seems to start the first pass at safe height maybe? It should be starting the Z entry from safe height, the first pass should start at “start height”
There is also alot of moves at the end of the program that just run back and forth along the XZ with no feedrate. Since the last feedrate set is F212 it would basically just whip back and forth up and down without even moving the rotary.
I am getting the feed rate output correctly for the X dropcutter Op ( 6 in/min), and just under double the rate for the Y dropcutter ( 11.5755 in/min ) still a problem there.
6in/min is only correct if it’s only moving horizontal. So yeah, dropcutter X that’s probably right but 6 is not “just under double” for dropcutter Y because dropcutter Y never moves horizontal when moving the A axis, it only moves vertical with the A axis, so the tool’s vertical feedrate of 2 would be correct if that’s what it was going for, but even that’s not what it’s doing, like I said if you turn on multipass you will end up with F212 by the end of the program which can only be explained by it trying and failing to calculate the linear feedrate of the rotary axis but based on the diameter of the cut plus what else?
The output suggests it’s not considering how G1 actually works when a rotary is run by itself, whenever only an angular axis is moving the feedrate is commanded in degrees per minute. Whenever a linear axis is involved the feedrate is in linear units per minute even when the angular is also involved.
I know that’s confusing but that’s how it works. So the question is, do you (or whoever develops for this) want to keep that linear feedrate calculation or simplify it? If you want to simplify it, I think there needs to be an entry in surface for the rotary feedrate. That rotary feedrate should only be used when there is an A-only move. Alot of smaller CAM programs mess this up by using just the tool feedrate for everything which is why there is a common fix to convert the program to use G93. The problem with the output from the 3D surface op in dropcutter Y/multipass is that the feedrates are all over the place so you can’t even fix it with a program, you have to do it manually. In this output, moves start at F12 and end with F212. There are XY only moves that use these feedrates too. I don’t know about anyone else but my machine can’t handle an G1 Xxx Yxx F212 (in inches). For example:
G1 X-3.9370 Y0.0000 Z1.0436 A-2.1413 F12.9696
G1 X-3.9370 Y0.0000 Z1.0436 A-4.2825 F12.9696
This is basically unusable because it’s too slow. It’s runnning at 12 degrees/min
G1 X-3.9370 Y0.0000 Z1.0436 A-359.7341 F12.9696
G1 Z1.2404
G0 A0.0000
G1 X-3.7402 Y0.0000 F12.9696
G1 Z1.0436 F12.9696
This move here would damage the cutter. The first G1 Z has no feedrate so it uses the last feedrate of 12 but since it’s a linear axis move it is 12inches/minute. I can’t plunge a cutter into a piece of aluminum @ 12/ipm, which is why my vertical is set to 2
I just used those lines to demonstrate that the moves with the lowest feedrates are still wildly different. Those 2 cuts are actually above start height (bug mentioned above). When you get further down the file it’s far worse when you have linear moves commanded at F212 (inches per minute)
Like I said, I think something is trying to calculate linear feedrate based on an cut diameter. In a perfect world that is the best way to do it but it needs to be calculated correctly and it needs to apply the calculation to the angular-only moves separate from the linear+angular moves, linear only moves should obviously just follow the tool. Another option is it could also get rid of the linear feedrate calculation (if that’s actually what it’s doing) and allow an angular feedrate entry that the output switches to anytime there is an angular-only move. That’s still a fairly safe bet if it’s adhered to unless somebody is trying to use the A like a lathe spindle or something.
Microscope camera arm adapter OP2-orig.zip
Another thing I never use is Multi-pass, … so I was not seeing what you were in the output. Apologies I should have picked that up from parts of your original post.
I am not a developer or even proficient with Python. The code for the 3D Surface operation is way above my understanding but I would like to understand it, not there yet!!
As you say multi-pass is not a good option in it’s current form.
It would be worth putting your observations forward as an issue so it gets looked at by the right people. The developer of this feature is still around I think @russ4262
Single-pass has been quite usable for me as is.
Yeah I posted one. That’s the 3rd git issue I posted for path this week.
If you’re not using multipass I can’t imagine you’re using it with anything other than plastic or soft wood, it’s pretty much impossible to get a reasonable cut if it’s going to run full depth especially with the feedrate bugs.