changing the orientation of the design

[deHarro]

Hi Martin, is there already an option to rotate the design loaded into OCP 90° CW or CCW?

If not, might it be possible for you to implement such a feature?

Background information: I use tools to generate the gcode which allow for rotating the design and I use such features (and have to use) since the X- and Y-axes of my router are different in length. On the other hand I use pcb-gcode.ulp to generate designs for routing PCBs and this tool doesn't allow rotating the design.

I once changed the orientation in the editor (EAGLE) , just to generate a rotated design for routing, but that is no fun for just generating the gcode. It's not only "select all" and "rotate left 90". If you do this, all components end up outside the allowed area for placing components (at least in the free version). So you will have to move the design a certain amount to the right before rotating it, here also observing not to exceed the boundaries (8 x 10 cm). And first you have to gather the complete design in a group. Missing that, all components will rotate each by itself. Funny but useless :)

I dare to ask since you already juggle with the coordinates in a dreamlike way, so adding this feature may not be very complex for you?

Oh well, just to be sure: I'm not referring to the possibility to rotate the viewport but to transpose X and Y coordinates, respectively.

Harald

[edit] Found something featuring my needs: Gcode rotator It's an online tool and does what I want. But having this feature on hands in OCP would definitely be nicer :-) [\edit]

[canbaytok]

I just took a little look into the code and it seems like Martin already layed out all the things that are needed to achieve gcode rotation. I edited the GUI a bit and sure enough it works flawlessly!

I am pretty sure that implementing stuff like rotating by a custom angle and changing the center of rotation is no problem. Just depends on the proper usage of vector maths :D

[deHarro]

Sounds good :) Sounds even better if one is keen in vector maths ;-) The example you attached shows exactly what I need to get my job done. I assume, you only "implemented" some sort of "rotate 90° CW"?

Are you willing to provide us with your GUI extension? Harald

[edit] perhaps we should wait for Martin to officially support this feature... [/edit]

[canbaytok]

I assume, you only "implemented" some sort of "rotate 90° CW"?

Yes I did, just to try and get a proof of concept.

perhaps we should wait for Martin to officially support this feature...

Same opinion here. I dont want to interfere in Martins development. I was just bored :D

[deHarro]

Hi sirsenor,

I was just bored :D

Nice excuse ;-)

I'm not bored, I just routed another board for my DCC railroad project (http://www.harald-sattler.de/html/eisenbahn_tt.htm - in german).

It's far from being ready, just one step beyond the situation described on my homepage (as of 2004). I started in 11/2018 and switched from MERG parts to DCC++, using Arduinos and off the shelf parts for most of the electronics.

Perhaps again a word about routing boards with OCP (not for you, for ALL):

Every now and then there are complaints in the issues section of OCP according bad results and to deep or to shallow carvings.

I always get good results when I first start the macro "probe and set Z=0" Martin provides us with out of the box.

When I omit this probing, OCP also probes the surface, but the coloring is not very expressive (not very much difference in colors).

The height map is generated too, I assume and one can start right away with carving, since OCP should recon the bigger values into the gcode, using absolute values.

But I think I get no good results in this case. Theoretically both approaches should achieve the same results (my opinion).

Recently I omit the tool change by probing the height map with the carving stylus (formerly I always used a spring loaded test pin to avoid crashes in case of a failure, but now I trust in OCP and my own actions ;-)

Gruß

Harald

---

Modellbau&Elektronik

http://www.harald-sattler.de/ www.harald-sattler.de

Von: sirsenor [mailto:notifications@github.com] Gesendet: Freitag, 21. Dezember 2018 20:49 An: martin2250/OpenCNCPilot OpenCNCPilot@noreply.github.com Cc: deHarro harry0001@satharo.de; Author author@noreply.github.com Betreff: Re: [martin2250/OpenCNCPilot] changing the orientation of the design (#85)

I assume, you only "implemented" some sort of "rotate 90° CW"?

Yes I did, just to try and get a proof of concept.

perhaps we should wait for Martin to officially support this feature...

Same opinion here. I dont want to interfere in Martins development. I was just bored :D

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/martin2250/OpenCNCPilot/issues/85#issuecomment-449482266 , or mute the thread https://github.com/notifications/unsubscribe-auth/AZFIJiUvZT1oBDHT4IQsfDpKtuoi9xvCks5u7TsSgaJpZM4Zajp6 .

[martin2250]

Hi Harald and @sirsenor,

sorry for not replying earlier, been kept pretty busy with uni. Adding a rotate feature is pretty easy, the math is already there. I could support choosing an arbitrary angle, but I'd have to limit it to only support arcs in the XY plane. Not sure how useful it would be anyways (I'm mostly too lazy to create a new dialog, the code is easy). In the next days I'll have some time on my hands and I can finally catch up on all the new issues here.

Cheers! Martin

[deHarro]

Hi Martin, no big thing (your "late" response" ;-)

As explained above I would be very happy if you would implement this feature. My tool chain generates designs in fixed orientation and this orientation does not fit for my router layout, so I allways have to rotate my designs in one or the other way - sometimes generating headaches, as suffered on my latest router jobs, a wordclock. The design is a little bit too big for my router so I had to route in sucesessive jobs in different orientations (vertically, horizontally and 45° for the corners) and I often found me hitting the stop button since I got it wrong :(

For my purposes a simple "rotate CW" button and perhaps an additional "rotate CCW" button would do the job, as sirsenor already has implemented that as proof of concept.

Harald

[martin2250]

Hi,

I just added a simple rotate button (e9eabf12e6e5365fefe3bd0e0a1d6828b8ea0ef0). It still has some limitations (only supports arcs in the XY plane). If anyone absolutely needs G18/G19 arcs, use the arcs to lines feature for now and let me know.

Martin

[deHarro]

Hi Martin, sorry for reusing this closed topic.

Am I right in assuming, that all of us who use OCP solely for routing PCBs, are completely fine with the current solution? I think of "only support arcs in the XY plane". I'm pretty sure there are no other arcs in dealing with PCBs. Did I miss something?

Harald

[martin2250]

Hi Harald,

I don't know about everybody else, but I'm using OpenCNCPilot for every job on my machine. That includes gcode from Fusion 360, which pretty much always contains G18/19 for lead-in/out. Then again you can choose your coordinate system freely in any good CAM software, so you wouldn't need a rotate feature anyways.

By the way, I highly recommend you to try KiCad for PCB design. I switched a few months ago and while it was quite annoying to learn at first, I wouldn't want to go back to EAGLE again. Then you also don't have to worry about size limitations.

Also pcb-gcode.ulp doesn't produce very nice results, I use pcb2gcode now, as it also gets rid of the tiny strands of remaining copper in the center between traces.

Martin

[deHarro]

Hi Martin, ok, you're right, in the meanwhile I also use OCP for every job, I'm away from SerialComCNC for a while now since the author seems to have stopped further development (and had missing features, still). But this rotating feature I need only for PCBs (up til now, at least).

Concerning KiCad and pcb2gcode How long did you use Eagle before you switched? My first encounter with Eagle was back in 1998, so in conjunction with my advanced age ;-) I'm not sure whether I should give me the thrill of changing a well-rehearshed team. But as always... I fear, I will give it a try anyways.... Thanks for the hint!

"tiny strands"?? This is only a matter of parameters. Increasing the minimal space between traces gets rid of those remains. The only draw back of pcb-gcode.ulp I'm aware of is the missing opportunity to define different depth for drilling the holes and the marking of holes with the carve stylus. There is only one parameter for both, what is totally useless. Perhaps I didn't understand that feature, but so it is for me.

So again: Perhaps I should have a look on the other tools... At least, Eagle can produce Gerber output as well :-)

Harald

[martin2250]

You've been using EAGLE since the year I was born, I can't quite match that with my four years of experience :)

You may be right, pcb2gcode normally uses a smaller spacing between the individual passes, but I think it also adds another pass where one wouldn't fit when using pcb-gcode or FlatCAM (both only allow closed loops as toolpath, pcb2gcode also creates "zero-width" lines when a loop doesn't fit anymore, as illustrated on the right).

As for marking the drilling spots: I don't remember having this issue, I might have edited the files by hand but I think there was an option... let me check There is an option next to "spot drill holes", are you using an older version?

Greetings Martin

[deHarro]

Hi Martin,

thanks for diving into "my" tool! I have the same version and I have no problem with spot drilling the holes, that works like a charme. But the generated file for drilling the holes uses the same depth as specified for "Spot drill holes" and that results in nothing useful. The drill bit dives into the surface for the same amount as the carving stylus already did.

nota bene: you get broader spacing between traces if you uncheck "single pass", but I suppose you already know that.

Harald

[edit] Just found my failure :) Drill depth is set on the "machine" tab under "Drill Depth" (Huch! 8) Now chances are that I stay with pcd-gcode... :-) [/edit]

[martin2250]

Hi,

in my illustration, both programs would use multiple passes. In the left one, there is not enough space left to fit a second loop, so no additional toolpath is created there (at least with pcb-gcode and FlatCAM). I tend to use four or five passes, but still get these strands when not using pcb2gcode.

Martin

[deHarro]

Mhmm, then I use "better" distances between traces by chance? I have no such strands if the distance is smaller than the minimum gap parameter, but I get the point.

Anyway... Frohes Fest und einen guten Rutsch! :-)

Harald

[martin2250]

Dir auch, genieße die Feiertage! :)

Martin

[deHarro]

Hi Martin, some days ago I struggled over the already mentioned problem of pcb-gcode.ulp again.

I told you that defining the spot drill depth is one thing, defining the drill depth is another. That's exactly what everybody should expect and so did I, after having "found" the two different parameters.

I changed my parameters accordingly and found that pcb-gcode.ulp uses the spot drill parameter for drilling, too. Just as I raised in the linked topic above.

This is definitely an error in pcb-gcode.ulp and I remember having found this issue earlier but forgot about it.

Just to keep you uptodate :-)

[edit] Just looked it up at pcb-gcode.ulp forum: This issue is known since around 2015 and there is no solution available from the authors, but some sort of workaround from a user. I will give that workaround a try ... [/edit]

[edit2] The hack of Alexander Arkusha works like a charme :) [/edit2]

Harald

[martin2250]

may be fixed two ways. A. By switching on "Use simple drill code" checkbox in Setup/Gcode Options tab;

that would explain why I never noticed that. But shouldn't you also be using simple drill code?

[deHarro]

Perhaps I should have but never did... This might be the cause for several breakes in the drill job (for tool changes).

If I check "Use simple drill code" the ULP will use one and only one drill bit, so all tool change pauses will vanish? If so: COOL :-) I will check that. That would have the benefit of getting less warnings on loading the xxx_drills.nc file into OCP.

By the way... Can you please explain the meaning of "ignoring empty move..." as seen in the pic

What (and WHERE) is the error causing this message? I tried to spot this "move" but as you write, there is nothing wrong with (and around?) the given number (interpreted as line number)... Thanks!

But again: The hack runs fine, I yesterday routed boards with that fix and besides the tool change pauses (and my fault of not adjusting the bit properly) all went well, I had spot drills with -0.1 mm and drills with -1.6 mm, just as set in the parameters... Nicht zu glauben, kaum macht man's richtig, geht's!!

Harald

[martin2250]

If you ever tried to use pcb2gcode with "simple drill code" unchecked, it should have used G81 canned cycles to drill holes, which is not supported by grbl. So I think you already did that -> I wonder why Alexander wrote that this would fix it.

It will still output tool changes.

The empty move warnings are places where the code does something like

G0 X0 Y0 Z10
G0 Z10

OpenCNCPilot will remove the second line as it wouldn't actually do anything (Only if you use a command in the Edit tab, if not OCP will send the code directly from the file). Usually you can ignore this warning, this is only a precaution.

Martin

[deHarro]

Perhaps this

If you ever tried to use pcb2gcode with "simple drill code" unchecked

is the vital clue... I only gave pcb2gcode a short try after your proposal to use this tool and then clung to pcb_gcode.ulp. So perhaps there is no checkbox for "simple drill code" in this EAGLE ULP? That would explain why I didn't find such an option... Harald

[martin2250]

sorry, I meant pcb_gcode all along, not pcb2gcode. I always confuse the both :sweat_smile:

[deHarro]

Ok, I found the check box in the g-code options (should have been clear enough ;-) When checked, the two warnings "ignoring empty move..." where gone, but the tool changes are still there.

Ok, I can live with that.

But talking about this very messagebox with warnings... The first time I read this box I was astonished that you implemented an editor, knowing that you refused that eons ago. Then I realized that you might have meant "edit functions" in the sense of routing the board, since there was no means of editing the gcode, still. Am I right?

Harald

[martin2250]

So "simple drill code" really was unchecked? Then maybe it does behave differently than how I remember. Which post processor (if it can be called that) do you use? I am positive that this had something to to with canned cycles.

Exactly, I didn't change my mind about the editor, I meant "Simplify", "Apply Height Map", "Arcs to Lines" etc.

Martin

[deHarro]

What post processor? I feed the result of pcb-gcode.ulp directly into OCP, no intermediate steps (since you added this fantastic "rotate CW" button ;-)

Oh, and yes, "simple dril lcode" wasn't checked the last 30 years.

Harald

[martin2250]

I remember there was an option to choose between EMC2, Mach3 and some others. Is there a new "GRBL" option that doesn't use canned cycles regardless of the other settings?

[deHarro]

There are options to choose between on the tab "GCode style" , I use "generic", stating "Tries to be very compatible". The others are emc, isel, mach and turbocnc, respectively. Since GRBL is not listed, I thought this generic one will fit best. Harald

[edit] I do not expect the author of pcb-gcode.ulp to change anything on this tool, since he didn't change his code back in 2015 but forwarded the solution of an user for all to hack the code by themselfes. So I think I have to live with the status quo, which is not so bad. (ok, provided not switching to pcb2gcode ;-) [/edit]