[Jack000]

zealouse: wow nice! Is it made in flash/as3? How did you do the drag and drop from the explorer window?

I've added a \r\n to the end of the gcode post (you might need to refresh), let me know if it works!

[Jack000]

I opened my first file in it and found a bIIIIg obstacle: I work in mm, not inches. Is there a way to work around that?

oeps found it! Sorry!

Let me know how it works in mm. I always use inches, so there may be a few bugs lurking in the metric stuff.

[Jack000]

zealouse: got your pm, but it didn't let me reply for some reason.

I've changed every \n to \r\n, see if that works for ya.

Is there a plugin to convert as2 to c++? how does it work for flash-native functions, like the bitmap and rendering stuff?

[Jack000]

beta 005 has been released!

New features:
- speed improvement! rendering of complex files should be significantly faster
- new tools - vector pointer and pen tool
now there is a move tool and a vector pointer tool. That way you won't accidentally grab a point and distort your path like before. The pen tool works the same way as inkscape and illustrator.

- more intelligent SVG importing, detects and corrects vectors during import.

Lots of people were having problems with the requirement that each closed loop be a separate path, so this is done automatically on import. A lot of CAD programs also seem to output tons of small segments instead of a continuous loop, now the cleanup routine welds them automatically.

- tons of bugfixes!

check it out at the new location: www.launchpad.net/partkam (click the big green button)

[Khalid]

Zealuse.. Wonderful job on the Editor.. Your programming and aesthetical skills are awesome..
Regards

[Jack000]

update: found a few bugs in new features, just uploaded fix.

if you were seeing strange behaviour before, it should be fine now.

[Jack000]

update: fixed a few more issues.

I've found that in daily use I sometimes need to edit a bunch of toolpaths at once, so now there's a batch modify feature. Also the dialog boxes were stacked way too high, now I've laid it out side-by-side to save space.

[CaptainVee]

Let me know how it works in mm. I always use inches, so there may be a few bugs lurking in the metric stuff.

Did the first real trials. Besides getting to learn lingo in English it works realy well!

I want to use it for milling logos and the conversion seems very quick.

One thing I noticed is that some millimetres in the code are off. When I set teh depth to 3 mm, it ends up in the code as 2.998347 or similar. No big deal for me but on bigger sizes this could become a problem?

[Jack000]

sorry for the delay. Was at a student business competition for the weekend. (I won tons of money! :rainfro

anyways, that sounds like floating point error. Does this happen after you switch from inches to mm, or does it happen even if you stay in mm the entire time? Does it happen in the interface or only in the g-code?

thanks

[CaptainVee]

Not sure about the lingo

But it seems to happen the entire time. F.I., when exporting the toolpath it says: folow toolpath 1 (0.10007600000000001) which seems to be an overly precise way of saying 0.1

Oh, congrats on the tons of money!

[Jack000]

I see the problem, will upload fix shortly. Thanks for the report!

[pshouse]

hm.. this is an interesting issue. Here's what the path command in that file looks like:

m -134.95033,290.58497 0,-478.37546 -124.53182,0 0,-64.00537 299.598286,0 0,64.00537 -125.047461,0 0,478.37546 z

to me that looks like a bunch of move commands (which won't draw anything), but apparently the unnamed operations are all line commands in svg short-hand.

Yeah, here is the SVG standard:
http://www.w3.org/TR/SVG/paths.html#...MovetoCommands
wich states:

If a moveto is followed by multiple pairs of coordinates, the subsequent pairs are treated as implicit lineto commands.

Suggestions on how to implement this in the parser.

SUGGESTION A
Didn't look at code for SVG parser. As most parsers, it may include a "current command" state variable or such holding current command while parsing. Add the capability of switching the current command from m to l if the previous command was m and on current coordinate pair there is implicit command: should not carry along m, but switch to l. Shouldn't be that hard, I think.

SUGGESTION B
If your parser if of the "split this string in coordinates on blanks token delimiter, and hold in this data structure", should be even easier: associate m command with first coordinate, then l command with subsequent coordinate pairs. I think you get the idea.

SUGGESTION C
Another approach would be adding a pre-processor wich adds the l after first m in the imported svg before doing the actual parsing. I tried to manual edit inkscape outputs adding the missing l where implicit and partkam then reads the file correctly. This implicit l is part of the standard, not some weird shortand peculiar to inkscape. If your program opens SVG's, should support it. And solution to support it is so nearby (just a missing, implicit "l" that when manual added fixes the issue), that would add great value if incorportated with minimum effort.

WHY IT'S IMPORTANT TO SUPPORT THIS FEATURE
Please, support svg import from inkscape output. Since inkscape can read dxf, it would let anyone open their dxf's (this file format is widely used for machining) by simply "passing it through" inkscape (open dxf, save svg).

[Jack000]

pshouse: that particular problem was fixed in october (actually just a few posts down).

I haven't seen any other svg quirks since then, but if you come across one please post it so I can fix it for ya.

[pshouse]

I'm trying to pre-process inkscape svg output with EditPadPro regular expressions search-and-replace, so that partkam will open them. EditPadPro is a notepad substitute wich supports regular expressions, but any other regex-supporting notepad-like program will do.

I had success with my SVG file with this:
SEARCH: (M [\d.,]*) ([\d.,]+)
REPLACE: \1 L \2

It searches for M followed by digit,dots,commas, then a blank, then again coordinates. And inserts an L between the two when replacing. It worked for my file but obvious it's not a general solution and could be buggy. I just posted in case someone wants to play with inkscape svg files using this approach. This is the pre-processor approach suggested in previous post. For now I'm happy that I can machine my part :-) but a more extensive SVG syntax understanding in partkam is a must, since it's the only file format it opens!

[Jack000]

hm.. that shouldn't be necessary since I implemented the fix. Could it be that you are using an older version?

try this url: www.partkart.com/partkam

I keep that url updated with the latest build. All the original links forward there as well.

if you are having trouble with a file, could you post it so I can examine it? I'm fairly certain inkscape output works fine, but there are always corner cases so you never know.

[pshouse]

Thanks for replying. Attached DXF file, then SVG file produced by InkScape (open dxf, save svg). PartKam will only show circles, but not lines. RegExp-based L inserting in M commands will let PartKam read everything.

Attached zip file with:
drawing.dxf -> my part file in DXF
That I want to machine today with your software :-)
inkscape-output.svg -> inkscape pass-through (open dxf, save svg)
PartKam will show circles but not lines of this file
processed-with-L.svg -> Reg-exp processed
Processed with RegExp search/replace above. Added explicit L in M commands.
PartKam will show everyting of this file.

Yes, I'm using latest version of partkam.

[Jack000]

alright, I see the problem. Will upload fix along with the metric thing. But first, sleep!

[pshouse]

Thanks for all the efforts put into this great app.

Since you're touching the app, I put to your attention another bug. Apparently app gets confused about what are island boundaries and external boundaries in some situations. See the attached print-screen. I included also svg file zipped.

The 5 island on left side are ok and get profiled inside. While the 5 island on the right side are profiled on the wrong side, as if they were not islands but external boundaries.

Similar issue with pocketing on the same image: algorythm gets confused too, perhaps in an even weirder way.

[Jack000]

ah.. I think that's because the inside outness algorithm assumes a constant winding direction, but that path is in pieces. No problem, just have to reset winding direction before doing that stuff.

will upload fix this afternoon.. but first, school! :rainfro:

[Jack000]

all is fixed! check it out at the partkart url (you may have to refresh a few times to clear your cache)

let me know if you find anything else fishy.