You’ve found the problem I most expected people to pick up on. I wanted the screw holes to be accessible in a straight line without the bulge of the bearing housing in the way - a pet hate of mine is not being able to mount/unmount tools easily. Keeping the linear bearings close together meant not having to push the bearings to far out from the tool mount. I figured the wall thickness outside the bearings would mean there was no problem but it’s not elegant I admit - novice designer
I realise now I totally didn’t make things clear - I guess I assumed more knew about Slicer.
Slicer is a stand alone app, that is a rewrite of 123D Make. Takes a model (STL or object) and offers a workflow of generating 2d cutouts for different construction types; flat slices, radial - tons actually. There is a workflow to use it from within F360, but’s really a closed system.
The cutouts can only be downloaded in EPS, PDF or DXF. It just happens that it exports DXFs with all the arcs as very short line segments. Since I posted, I found lots of reports about this causing issues with laser cutter software etc.
I am currently half way through trying out a workflow where you use the EPS option - looking good. I didn’t realise when you have the object browser in Inkscape open you can select elements within the imported EPS individually.
By the way, the whole reason for this knife is I’m trying to make these:
[attachment file=47458]
…and want one bigger than my laser cutter can do. Easy to do stuff like this in Slicer.
An stl by design is just a bunch of triangles, when you slice those you always get line segments, higher res smaller segments. To get away from that you will need to start with a real file not a stl. Or maybe that isn’t the issue?
I wonder if you could make some code that could find the segments and make either the arc or a polyline/polygon in the svg. They segments should be touching, so as long as there aren’t there line segments ending in one spot, you should be able to find them. I’d start with brute force, then speed it up with some pre sorting.
You could either make it read and write svg or do it in your gcode tools.
In this case the object being worked on is not an STL. I’d have to look at what happens when you start with an STL. I think the general answer is that just after the slicing gets done in the software, the object is still made up of arcs, and when the translation to DXF for output happens, these arcs are expressed as segments.
It seems strange that after much searching there isn’t an easily available function to derive arc vectors from sequences of segments. Just to be clear, there isn’t a general problem with Inkscape/Gcodetools in relation to generating 4th axis Gcode. It’s just that Slicer can’t output arcs, and the reason I’m clinging to Slicer is…well you just have to try it, and maybe you’ll also get the bug.
But, the gcodetools should be able to cut a polygon without lifting the blade at every corner, right? We were talking about a max angle before it would lift up. Something is keeping it from treating it as a continuous path. Arcs would be fine, but the cam should be able to handle this anyway. There are an awful lot of objects that aren’t just arcs or long lines.
I assumed the reason it was a problem was that they were treated as separate, unique objects.
You’re right, I failed to emphasise again that it’s not just that there are segments instead of arcs. It’s also that gcodetools thinks they’re not joined up, because it’s using a sub path for each one, causing a lift. Some debugging could be in order.
However, even if the segments were not treated as sub paths, there would still be a lot of gcode to do a circle. I guess that wouldn’t matter.
Are the 2 x 10mm x 120mm steel or aluminum rods in this design to give it more stability and tie the stepper mount to the machine mount? The reason I am asking is that I need to move the cutter at least 5mm towards those 10mm rods to be able to clear my quick disconnect mount. If that is the case, could I just use a couple of smaller M5, M6 or M8 screws and change the design of those 2 mounts?
I’m not 100% clear on the question, but the rods are there because spring loaded movement of the blade was a primary design goal. given the stepper needs to move freely in the z axis w.r.t. the mount, the two rods, two bearings arrangement was chosen to minimise X/Y slop.
My experience with cutting thicker material is that rigidity of the cutting head is key, but so is the spring loaded action, as it regulates the downwards pressure of the blade.
Do you have a video showing the movement of the whole assembly. Not sure I can explain my question properly, but from what I could tell from the assembly only the drag knife with spring moved relative to the 4th axis stepper motor. The stepper mount & machine mount look like they are fixed together and only move with the z-axis motor. Is that not true?
The 4th axis stepper is mounted to the stepper mount (obvs). The shaft of the stepper is coupled to the bolt of the knife holder assembly with a pineapple coupler. This assembly moves freely w.r.t. the machine mount, which is fixed in the usual way.
To put it another way, when mounted, if I grab the blade and push up, the bolt, pineapple, stepper and stepper mount all move as one.
If you un-screw the pineapple coupler, the bit with the stepper, stepper mount and rods will come right off.
Won’t be able to do a vid for at least a day, but will do so .
Incidentally, I’m moving to a smooth bolt rod from the knife mount through the skate bearings, much more freedom of movement, just need to find one with the thread in the right place
Been struggling for time, and struggling with issues on this thing. I need a bit more help I think. Or maybe just to share my problems.
jeffeb3, you were explaining why my circle was round and not segmented. I messed up, because that circle was cut with arcs. I forgot to set the minimum arc angle to prevent it using arcs for that one. It turns out, when gcodetools uses segments instead of arcs, it does the turn commands separate to the move commands, which doesn’t sound too bad, but the segment count for a circle is not easy to control.
It’s controlled with a parameter (biarc interpolation tolerance) but results in un-even segment length. So arcs would be so much nicer. Unfortunately, extensive testing has revealed that with arcs it seems steps are missed. Is this the expected behaviour with arcs?
Regarding the issue with slicer’s output, the segment vectors are there in the file as individual paths. Gcodetools doesn’t seem to know that even if the end point of one path is the start point of the next, it can be treated as a single cut path, hence why you end up with tons of sub paths in the gcode.
Ah, that’s the thing where you’re basically setting the maximum difference between arcs and line segments, right?
What do you mean? The steppers are skipping, or part of the process or gcode is missing? If the steppers are skipping, if try doing the moves in mid air, and see if you can see why they aren’t doing the right thing.
That gcode looks fine, but those two parts aren’t equivalent. I’m not sure what I’m looking for, exactly.
The gcode for movement always starts at the previous location (obviously) the arc commands and the line segments both end up at the x y locations. The Arc commands just go there by moving along the circle defined by the I and j values.
One thing that’s always bothered me is what happens when the i,j doesn’t fit with the starting location and the x,y location. But that’s neither here nor there.
Marlin thinks the E value is just the amount of plastic to push while following that path. If the path is 3mm long and it’s supposed to extrude 0.3mm, it will extrude 0.1mm when it’s travelled 1mm along the arc.
That actually works out for us, because if the angle starts at 0 and it’s ultimately going to end up at 90, will traveling 10mm, it will be at 45 at 5mm. That will work out as long as the arcs are generated the right way. If the path was clockwise and the cutter moved anticlockwise, then there would be problems.
If be curious to know if the slicer handles polygons differently than independent line segments. If the only way to make that shape work is arcs, then… Bummer.
Another note. You shouldn’t worry about the size of the gcode, just the runtime. Trochoidal milling uses a bunch of little arcs to make it’s circles, so it is huge. If it’s lifting 2mm everytime it moves 1mm, then that’s a problem, but the length of the file is no big deal.
This is awesome (not sure how I missed this). I want too try cutting dollar tree foam board. This could be great for cutting foam planes. Keep up the great work!
Thanks for sticking with this jeffeb3, I appreciate the support.
That parameter actually works whether gcodetools is generating arcs or segments to match the shape.
If you start with a circle path in inkscape, you can get gcodetools to do it with arcs or segments based on the value of the minimum arc radius. If you set this high enough, it will do your circle in segments.
Biarc interpolation tolerance controls something close to how you describe, but works for both arcs and segments. Even for arcs, they are approximated to the underlying path, and that param controls the tightness of the approximation. For segmented gcode, it effectively controls the segment length, as the higher the value, the less segments it will use to approximate a circle.
After I run the arc based gcode to draw a circle, which is drawn from 3 o’clock anti-clockwise back to 3 o’clock. Even in mid air, the orientation of the tool does not return to the starting orientation, but instead lags behind by a few degrees.
I calibrated steps per mm for E so that 10 rotations (pi * 20) return the blade to the original orientation after 10 turns. I also double checked this after the circle gcode was run. Hence my conclusion that arcs cause missed steps. As you say there is no physical resistance, so I assume it’s a processing failure.
I have also looked at the numbers in the gcode, and the blade should start and finish at 90 degrees or 1/2 pi. Somewhat unrelated, but in the simulation the arcs look correct.
I understand your point about the gcode size - if getting the software to produce a segmented circle was going well it would be ok, although it would be better if the segment moves also had the E moves, so it wasn’t move->turn->move->turn
This is all separate to the slicer problem. I’m just drawing a circle in inkscape and trying to produce gcode from it at the moment.
The slicer problem is that it produces arc free DXF’s (I am not very clear about arc support in DXF), and the segments are all as individual paths in Inkscape. Gcodetools sees these as sub paths. There would need to be code changes to accommodate this, and anyway I’ve found a work around - export to png and then centerline trace from Inkscape, which is working fine.
I did post that stuff on CNC Club RU. It was about something different thought, namely blade lifts. The forum is not active and I worked out the answer to that myself.
Thanks! Time will tell if this turns (turns!) out better for foam board than a needle cutter. My feeling is that maybe the needle cutter will be the ultimate tool for foam. I’ve bought my bits for that, and will make one soon.
I’m fairly obsessed with cardboard at the moment, although if I can solve the issues I’ve got, I will certainly be testing some very sharp angled cuts in vinyl, such as small lettering, where a drag knife suffers.
No problem, after your previous message I looked at the assembly a little closer & think I understand the movement now. I have moved on to some other interests this week & not sure when I will get back to this. I did get the 2 main parts remixed in openscad so they are close to fitting in the quick release bracket. I am thinking about using 2x 8mm rod instead of the 2 x 10mm x 120mm rod so it would be easier to fit within the quick release bracket. Do you see any problem with using 8mm versus 10mm?
