Gadget work in VCarve Pro and Cut2D Pro as well not just in Aspire. The Desktop versions don't support gadgets.ZipperHead55 wrote: ↑Thu Feb 16, 2023 2:42 amThe OP isn't using Aspire, so he can't use Gadgets.Rcnewcomb wrote: ↑Wed Feb 15, 2023 9:56 pmThere is no need to do this if you use the Milo Scott method.Take a rotary raster gcode and turn it into continuous raster, essentially reversing every other raster line.
Raster Disaster (Or - How to avoid Conventional direction)
- Adrian
- Vectric Archimage
- Posts: 14544
- Joined: Thu Nov 23, 2006 2:19 pm
- Model of CNC Machine: ShopBot PRS Alpha 96x48
- Location: Surrey, UK
Re: Raster Disaster (Or - How to avoid Conventional direction)
- SteveNelson46
- Vectric Wizard
- Posts: 2282
- Joined: Wed Jan 04, 2012 2:43 pm
- Model of CNC Machine: Camaster Stinger 1
- Location: Tucson, Az.
Re: Raster Disaster (Or - How to avoid Conventional direction)
Also, the Milo Scott method of rotary turning isn't a gadget. It's a technique used to carve 3D with a spiral instead of a 3D toolpath.
Steve
- adze_cnc
- Vectric Wizard
- Posts: 4325
- Joined: Sat Jul 27, 2013 10:08 pm
- Model of CNC Machine: AXYZ 4008
- Location: Vancouver, BC, Canada
Re: Raster Disaster (Or - How to avoid Conventional direction)
I guess the confusion lies in the "1001 Vectric Continuous Turning Round 27 Mar 2021.pdf" file. Section 6 (6.1 especially) mentions the use of the "Wrapped Spiral Layout" gadget.
- TReischl
- Vectric Wizard
- Posts: 4584
- Joined: Thu Jan 18, 2007 6:04 pm
- Model of CNC Machine: 8020 48X36X7 RP 2022 UCCNC Screenset
- Location: Leland NC
Re: Raster Disaster (Or - How to avoid Conventional direction)
Just some terminology clarifications:
The term "post processing" is not unique to Vectric products. This term has been used since the earliest days of NC/CNC dating back to at least 1974 when I first started with NC machines.
The term "pre processing" was/is used to describe modifications to a g-code file after post processing but before loading it into the machine control. I know, I know, it makes no logical sense whatsoever to call "pre". But that is what it has been called for as far back as I can remember. For a frame of reference, way back in the day I worked for MDSI, Numridex and Encode. So I am not the one making these terms up.
Frankly, I always thought it should be called post-post processing. . . . .
Edit, a little more info on these terms: It was called post processing because the computer software prepares what is commonly known as a "CL" (cutter location) file that is not machine specific. Then that file is "post" processed into machine specific g code. So, internally, there are two "processing" passes to create a gcode file. These days a file is generally not used, just memory. But back in the day of 8Kb and 16Kb RAM computers, files had to be used. Yup, the first programming system I used had a Data General 8Kb RAM computer, and 8 inch floppy disks. Forget about a hard drive, at the time, a 10Mb hard drive was north of $10K. How times have changed!
The term "post processing" is not unique to Vectric products. This term has been used since the earliest days of NC/CNC dating back to at least 1974 when I first started with NC machines.
The term "pre processing" was/is used to describe modifications to a g-code file after post processing but before loading it into the machine control. I know, I know, it makes no logical sense whatsoever to call "pre". But that is what it has been called for as far back as I can remember. For a frame of reference, way back in the day I worked for MDSI, Numridex and Encode. So I am not the one making these terms up.
Frankly, I always thought it should be called post-post processing. . . . .
Edit, a little more info on these terms: It was called post processing because the computer software prepares what is commonly known as a "CL" (cutter location) file that is not machine specific. Then that file is "post" processed into machine specific g code. So, internally, there are two "processing" passes to create a gcode file. These days a file is generally not used, just memory. But back in the day of 8Kb and 16Kb RAM computers, files had to be used. Yup, the first programming system I used had a Data General 8Kb RAM computer, and 8 inch floppy disks. Forget about a hard drive, at the time, a 10Mb hard drive was north of $10K. How times have changed!
"If you see a good fight, get in it." Dr. Vernon Johns
-
- Posts: 15
- Joined: Sat Dec 31, 2022 11:25 pm
- Model of CNC Machine: CNCEST 6090
Re: Raster Disaster (Or - How to avoid Conventional direction)
Hello friends! Hope you're having a lovely weekend
I have results for you. Though I didn't yet write the script that I promised, I did find a way to create a climb-only raster toolpath, using existing tools. I simply do (an over-extended) rectangular offset toolpath, then I clip the parts that I don't want, using this tool: https://www.scorchworks.com/Gcoderippe ... pper.html . The end result is very similar to my original plan, which was to take a raster, reverse every other line, and start from the middle outwards.
I did a test run, with deliberately bad circumstances, to emphasize the effects. (bad circumstances: 0.25mm TBN, 40% step-over rate. Other settings: 18k rpm, 1000 mm/min)
I made the following runs:
(1) Cross-grain raster
(2) With-grain raster
(3) Climb Offset
(4) Climb-only raster (using With-grain orientation). I'm aware there are errors in the GCode. The point is to assess the fuzzies
(5) 2-pass raster: With-grain raster, followed by cross-grain raster
(6) Climb-only raster (using Cross-grain orientation).
Offset looks the best IMO, but it does have this obnoxious "X". Surprisingly, the 2-pass looks worse than I thought.
(1) Cross-grain raster
(2) With-grain raster
(3) Climb Offset
(4) Climb-only raster (using With-grain orientation).
(5) 2-pass raster
(6) Climb-only raster (using Cross-grain orientation)
I have results for you. Though I didn't yet write the script that I promised, I did find a way to create a climb-only raster toolpath, using existing tools. I simply do (an over-extended) rectangular offset toolpath, then I clip the parts that I don't want, using this tool: https://www.scorchworks.com/Gcoderippe ... pper.html . The end result is very similar to my original plan, which was to take a raster, reverse every other line, and start from the middle outwards.
I did a test run, with deliberately bad circumstances, to emphasize the effects. (bad circumstances: 0.25mm TBN, 40% step-over rate. Other settings: 18k rpm, 1000 mm/min)
I made the following runs:
(1) Cross-grain raster
(2) With-grain raster
(3) Climb Offset
(4) Climb-only raster (using With-grain orientation). I'm aware there are errors in the GCode. The point is to assess the fuzzies
(5) 2-pass raster: With-grain raster, followed by cross-grain raster
(6) Climb-only raster (using Cross-grain orientation).
Offset looks the best IMO, but it does have this obnoxious "X". Surprisingly, the 2-pass looks worse than I thought.
(1) Cross-grain raster
(2) With-grain raster
(3) Climb Offset
(4) Climb-only raster (using With-grain orientation).
(5) 2-pass raster
(6) Climb-only raster (using Cross-grain orientation)
- adze_cnc
- Vectric Wizard
- Posts: 4325
- Joined: Sat Jul 27, 2013 10:08 pm
- Model of CNC Machine: AXYZ 4008
- Location: Vancouver, BC, Canada
Re: Raster Disaster (Or - How to avoid Conventional direction)
The acronym GIGO comes to mind.eitantal777 wrote: ↑Sun Feb 19, 2023 2:49 amI did a test run, with deliberately bad circumstances, to emphasize the effects.
In those TReischl links I posted earlier he goes emphasizes using deliberately good circumstances.
-
- Posts: 15
- Joined: Sat Dec 31, 2022 11:25 pm
- Model of CNC Machine: CNCEST 6090
Re: Raster Disaster (Or - How to avoid Conventional direction)
But it's not garbage-in-garbage out, tho. You can see how going in the climb direction, even with the grain, results in a reasonable work with almost no fuzzies, while going raster with grain results in garbage. It would stand to reason that under better conditions, the same effect still applies, except on a smaller magnitude: You'll get Good work vs. Excellent work. (Or, alternatively, if you use climb-only-raster, you can pick larger stepover % for the same quality of work)
Not only that, common wisdom says that the maximum stepover% is 50. So according to this, my conditions weren't techinically garbage in the first place.
Fair enough. I will repeat the same experiment twice: Using reasonable conditions (20%), and using favorable conditions (10%). It is possible that the effect will disappear entirely, and you get Excellent work vs. Excellent work, in which case climb-only becomes a must, only when using 40% step-over. climb-only-raster becomes a must if you don't want the X mark you'd get from offset.