Some people may have seen where a few of us hijacked a drag knife thread to talk about hardware off topic. Sorry OP.
I was able to remix a drag knife to increase the offset by a couple of mm’s, which effectively enabled me to cut lots of circles in 7mm double wall cardboard pretty reliably. Useless for anything with corners because the huge offset trashes the minimum radius of cut.
The answer for thicker material seems to be a tangential cutter. I thought I would share my progress working on this. Two problems; hardware and software. As Ryan said, the hardware is the easy part, but I’ve had a go at it, and built on my Fusion 360 skills a bit. I had some linear bearings and 10mm rod to hand and came up with this:
[attachment file=46888]
The main idea is that the knife is set to a zero offset position, and retains the spring loaded capability. I had to borrow Ryan’s pineapple! It seems to function well enough, so that leaves the software.
Generating the gcode might take a bit more work, but I have found this, which may help:
The trouble is, so far it just eats all my memory and dies. I will get into a bit of debugging with that next I think.
Assuming either with that method, or another method of producing gcode with tangential a axis moves (and corner moves), the next problem for me will be electronics and any firmware changes needed. I assume some tinkering with Marlin will be needed.
I haven’t got around to trying Gcodetools yet. I’m still trying stuff out with TCNC. Link above. No joy running it within Inkscape, but it works perfectly well on the command line. All the options are undocumented but they’re listed in the Python files.
Marlin has a bunch of checks on the extruder. Specifically, I’m thinking about the operating temperature. It’s worth a try. The non-3D printing firmware Ryan publishes simulates a temp of 170, so that might just work.
Dude! That might work? Right? Slick idea for sure, you will probably need to adjust the max feedrate, accel, jerk as well.
Oh please try this, I am pretty booked up right now but I would love to see if this works, if not we can probably figure out what extruder safety’s are kicking in.
Ok so I found some time to work with this one now. It looks like there are two viable tools to do this, as this one too looks like it produces the right gcode. All you actually have to do is to go into the tools library and select the tangential knife, then do a path to gcode
Thanks to Ryan for spotting that the next video button from the vid I posted brings up this (silent) workflow:
Both tools actually output an SVG which shows the gcode paths. Gcodetools actually works from inside Inkscape, and seems powerful, if a little unintuitive and messy.
Since the source code is available for both, I’m confident that TCNC can be debugged to work as expected, and both can be modified to output gcode to control the extruder and process the values as needed.
The only unresolved issue I have now is understanding what implementation exists for blade lifts for tight corners. The TCNC config options are not clear to me, but seem to suggest support might be there. As for Gcodetools, it’s going to take some more digging. It’s a start.
I will be looking into that, but in the mean time, what is the bottleneck on arcs? The arduino clock speed? Are any of the higher powered arduinos a solution for this?
I’ve always been willing to move to another control board, but have never understood the benefits. If someone told me upgrade to smoothieboard and you can use this arc laden gcode with no problems, I’d probably do it.
When you study the gcode produced by Gcodetools for a simple geometric shape, you can see that the g1 commands are preceded by the A moves, so the trick will be to get the code to break the arcs down into lines and handle them this way. I’d have to experiment further to see where the lifts are generated and where they are not. You wouldn’t want the lifts in there for every section of arc!
Yup, found that same video last night and ran Gcodetools in inkscape on a rectangle. Think I’m going to plug a stepper into the extruder port on my MiniRambo and see if I can get it to spin.
Also found this:Tangential PDF Still noodling what its trying to tell me…
Gcodetools in Inkscape
%
(Header)
(Generated by gcodetools from Inkscape.)
(Using default header. To add your own header create file "header" in the output dir.)
M3
(Header end.)
G21 (All units in mm)
(Start cutting path id: rect159)
(Change tool to Tangent knife)
G00 Z5.000000
G00 X17.067725 Y44.162743
G01 A0.0
G01 Z-0.125000 F100.0(Penetrate)
G01 X40.109154 Y44.162743 Z-0.125000 F400.000000
G01 A-1.57079632679
G01 X40.109154 Y20.267930 Z-0.125000
G01 A-3.14159265359
G01 X17.067725 Y20.267930 Z-0.125000
G01 A-4.71238898038
G01 X17.067725 Y44.162743 Z-0.125000
G00 Z5.000000
(End cutting path id: rect159)
(Footer)
M5
G00 X0.0000 Y0.0000
M2
(Using default footer. To add your own footer create file "footer" in the output dir.)
(end)
%
Gcodetools can be made to almost eliminate the arcs by allowing for a minimum arc angle. Set to 360, it’s pretty much all straight lines. Strangely enough there are still 4 arc commands in the file (7k lines in total).
Also, I found an option to ‘lift knife at corner’. This is where the software is strange. When you ‘apply’ on the options panel, it pops up a vector drawn green rectangle which looks like debug information. In fact if you edit the text in that rectangle with the text tool, you’re changing parameters that are not available in the dialogs, and affect the operation. Odd.
End result we have:
File with almost no arcs
Lift at corners - every corner, which is not much fun for circles
You have to be careful how fast you send commands…to many and it chokes if you do super high res the SD card can not keep up and you have to use USB, faster than that and the board will just reset. Making smaller arcs usually means more commands so it will slow down or reset on a corner. Just try it with arcs and see what happens it will either work or not but nothing will be permanently broken. Try not to solve a problem until you are sure it is a problem.
My anticipated problem with arcs is that it thinks angle is the extruder dimension. It’s doing math to decide which steppers to move and how much for an arc, but it doesn’t know the A or E stepper is the angle, so what will it do for that motor when it’s doing an arc? It’s not a speed issue, it’s a logic issue.
Maybe I’m being paranoid. The difference may not be substantial. Seems reasonable to try it either way. Worst case, you drag a knife the wrong way, maybe chip the tip.
Hmm, I wonder if that’s what happened on my drag knife test. It was when it went to do a curved corner that it crashed. I keep forgetting to look at the gcode and see what it was trying to do at that point…
Yes you’re right, changes will be easy now I’m in the code. It may already be available as an option somewhere to be fair. Where do you think we need the F commands? On the z moves?
It is best to have them on every line for now. In marlin at least. As it is right now whatever F command you used last will carry over to all moves as far as I can tell, until it receives another F command.
Dry run looking very promising. I’m pretty sure this is all going to cut fine tomorrow when I put it all together.
Back in the shop… plugged in the stepper to E0, and did encounter some errors moving it 360 degrees, because the firmware thinks it’s too much extrusion in one move. Heat threshold checks not a problem with my firmware, although I did start by setting the min to 1 degree.
So the A axis gcode generated is in radians. To make things easy, I wanted 1 full rotation of the E stepper to be 6.28319 rad, or 360 degrees. The answer was to set the steps per mm to 6705. This was arrived at by doing g1 e125.6638, so 20 full rotations and tuning until it came back to 12 o’clock on the nail. I will probably look to do this more scientifically to dial it in perfectly, but it will do for now.
Because the values in the generated gcode for A moves do not need translating, it was a simple matter of a regex to replace the A moves with E moves:
s/A(-*[0-9.]+)/E$1/g
I just ran the above gcode through after applying that regex, and it did the turns and lifts exactly as expected. We can update gcodetools to send the E, and it will produce correct gcode off the bat.
The high steps per mm mean the extrusion length checks don’t kick in, which is an added bonus. I also set the feedrate of E0 to 1mm/s which seemed about right.
