2 added features?

[tarmon01]

Hi,
This is an excellent program. Two added features though would help me a lot.

1. would be to only allow a single copy of the program to be run . ie if it’s already running , don’t open another copy of the program and 2) a way to open a Gcode file automatically when the program is started, (or called again like in 1) above.

This would allow a smooth way of sending the gcode file from the generating program to your program.

I can probably figure a clunky way to do it with python for 1) and a macro recorder for 2) but it sure would be better solution in your program directly.

Thanks,
-TomH-

[martin2250]

Hi Tom,

that's a great idea! That way, we could also use a file association to open gcode files by double-clicking. Right now I'm short on time, so I don't know when I'll get around to implementing this. If you (or someone else) want to take care of this in a PR, I'll gladly accept it.

Cheers
Martin

[martin2250]

Implemented it in 8440f04
Cheers!

[tarmon01]

Thanks!

…

-TomH-

On Mar 19, 2020, at 7:05 PM, Martin Pittermann ***@***.***> wrote:  Implemented it in 8440f04 Cheers! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[deHarro]

Hi Martin, tarmon!

When I double click on a xxx.nc file in windows file explorer (I associated *.nc files with OCP in Win 8.1), OCP gets started, but the file is not loaded.
Have I to do something further to make it work like expected?
Thanks!

Harald

[martin2250]

Hi Harald,

I'll have to test that later. I only tested drag'n'dropping files onto OCP, which worked. I assumed that file associations work the same way...

Martin

[deHarro]

Hi Martin,
no hurry... ;-)

D&D already worked since 2018 (or so :) this is nothing new.
I understood that from Toms question/proposal you implemented something like I explained isn't working... Obviously I misunderstood his Idea.
But it's ok for me.

Harald

[tarmon01]

Harold, What you described is what I wanted. As I’ve been busy, I haven’t been able to try it until now but I think it is working correctly. Make sure to get the latest top level executable that’s contained in “openCNCpilot-1.5.7.zip”. And make sure that the File association is not running the older copy of openCNCpilot. Thanks again Martin! I may open a new issue 🧐as I’m building a multi-headed pcb etcher/drill/mill/plotter for making the whole board without changing bits. This does require probing the board in the gcode code itself as well as the Gcode offsets and Mcodes to provide muxing of the 4 spindle/ motor control. It uses commands that Grbl supports, but you eliminate when you apply heightmap to the gcode. Commands like G49, G38.3, G10, G92,G54-G57, M9,M8,M7 that I wish you would just pass through, instead of deleting from the code. Anyway thanks again! And don’t be surprised if you get a new request ( Perhaps with a check box that says “ “pass thru unknown gcode” vs “ Ignoring(aka deleting) unknown gcode” box <grin>. Thanks,

…

-TomH-

On Mar 21, 2020, at 11:47 AM, deHarro ***@***.***> wrote:  Hi Martin, no hurry... ;-) D&D already worked since 2018 (or so :) this is nothing new. I understood that from Toms question/proposal you implemented something like I explained isn't working... Obviously I misunderstood his Idea. But it's ok for me. Harald — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[martin2250]

Hi Harald, Tom,

Harald, I tested drag'n'drop with the last released version and it didn't work. Still I have to admit, you almost convinced me that I implemented it before and forgot about it 😉

Also I tested associating OCP with .nc files, which works flawlessly (at least on Windows 10).

Tom, your second request is a lot harder unfortunately. OpenCNCPilot ignores work offsets completely, it processes all coordinates relative to the current work offset (the "sum" of G54-G57+G92+G43). So when I allow G54 etc, the position of the tool above the height map is no longer well defined (should it be calculated in absolute machine coordinates, in the current G54... or G92?). Just passing through these commands could lead to some funny behaviour.

G49, G43 should be ok to add as these commands only affect the Z axis IIRC. M-codes are already passed through.

Martin

[tarmon01]

Martin, What you do now is perfect for my use. If you just let the other commands through that would fix it. For instance right now you throw away parts of the command G10L2P010x10y that sets the actual offsets in grbl which is a problem. That is addition of course to completely removing the other codes that I use for the tool change does present a challenge. All M codes go through? I missed that. Will take advantage of that in my next version of the python script. You also filter out the probing commands G38.3 Which I need to use to set each tool height when I switch tools. My workaround at moment is to send 4 unused codes that make it through openCNCpilot filter, add the height map , save it, run a python script on the saved file to replace the unused codes with the tool change work offsets/ probe commands , and reload the patched code in openCNCpilot and run it with no changes. Not an ideal work flow as you can see. Also where do the macros store their data? Basically I lost the macros when I used the updated program. ( fortunately I had saved them elsewhere but it was surprising as I was going to use the older program to cut and paste in the new version but alas that wasn't possible.) BTW I think the program is great. I did poke around the source code a bit and I think it *may* be as easy as commenting out one line in the parser that eliminates unknown commands. But then again, it may be not. Thanks,

…

-TomH-

On Mar 22, 2020, at 4:30 AM, Martin Pittermann ***@***.***> wrote:  Hi Harald, Tom, Harald, I tested drag'n'drop with the last released version and it didn't work. Still I have to admit, you almost convinced me that I implemented it before and forgot about it 😉 Also I tested associating OCP with .nc files, which works flawlessly (at least on Windows 10). Tom, your second request is a lot harder unfortunately. OpenCNCPilot ignores work offsets completely, it processes all coordinates relative to the current work offset (the "sum" of G54-G57+G92+G43). So when I allow G54 etc, the position of the tool above the height map is no longer well defined (should it be calculated in absolute machine coordinates, in the current G54... or G92?). Just passing through these commands could lead to some funny behaviour. G49, G43 should be ok to add as these commands only affect the Z axis IIRC. M-codes are already passed through. Martin — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[deHarro]

Hi Martin,
you are right, on my Win10 milling PC it works as expected.
Thanks to MS there seems to be a different behavior on Win 8.1, which is my development system running with.
This is absolutely no killer for me, you don't have to put work into getting it running on Win 8, too.

Harald

@tarmon01
Yes, I replaced the complete code by the new files in place, there is no older version on the PC. Thanks anyway for the hint :-)

Harald

[deHarro]

Hi Martin, Tom,

I just tested the new version of OCP on my office PC (Win 8.1).

Keeping eyes open and beeing concentrated on the job (double clicking the xxx.nc file and staring at the screen) I realized, that directly after the double click, there appears a window which very quickly is replaced (actually superimposed) by the OCP GUI.
Nearly every one of my .NC files contains one or more g-codes OCP doesn't want to deal with. So it pops up a warning message.
Sadly, this message window is not topmost (on my PCs), so I missed it and claimed OCP is not loading the file.
After quitting the message box, the file is loaded as expected.
-> your implementation is perfect ;-)

In the given case the messagebox raises:
"1 > ignoring zero-length move from line number 1931"
which seems to be safe enough to being ignored.

Other messages often deal with tool change codes (T1..T5)
"1 > ignoring unknown word (letter): "T1". (line 38)
2 > ignoring unknown word (letter): "T2". (line 61)
3 > ignoring unknown word (letter): "T3". (line 90)
4 > ignoring unknown word (letter): "T4". (line 182)
5 > ignoring unknown word (letter): "T1". (line 196)"
or this
"1 > ignoring unknown command G94. (line 10)"

This behavior again leads me to my already raised proposal:
Perhaps you can implement a user definable list of g-codes, where the user - on it's own responsibility - can enter codes, OCP should ignore silently.

To circumnavigate those messages, I searched and found some locations where I could change the generating tool (namely Estlcam), so G94 should be no point anymore.

The Tx commands came from pcb-gcode ULP of EAGLE. There I now am using a drill file which tells pcb-gcode to always use the same drill bit for all occuring diameters. So no tool change commands any more.

Harald

[deHarro]

Perhaps you can implement a user definable list of g-codes, where the user - on it's own responsibility - can enter codes, OCP should ignore silently.

All the above mentioned warnings have no negative impact on the milling process, I proved this for me, I usually click on ignore and do the job without errors or unpredictabilities.

Harald

[martin2250]

Hi Harald, Tom,

good workaround, though I can see that it's pretty annoying to do. I like Haralds idea of giving the user the option to accept the responsibility. I think the easiest way to do that would be to just copy lines that contain unknown commands verbatim to the output file. Also I think it would be best if you had to establish the position of the tool again after commands that lead to an indeterminate position, that means after a G38 or G54 etc. you'd have to use G0 moves to unambiguously position the tool in all three axes before using G1/2/3 etc again (just like you currently have to do at the start of a file).

Macros and all other settings are stored as an xml file in %appdata%/martin2250/OpenCNCPilot. You shouldn't loose your settings when upgrading to a more recent version though.

Martin

[deHarro]

Hi Martin,

you'd have to use G0 moves to unambiguously position the tool in all three axes before using G1/2/3 etc again (just like you currently have to do at the start of a file).

that sounds pretty good.
I do not use home switches, but perhaps someone else does, so I would ask:
Will homing also "rearm" OCP?

You shouldn't loose your settings when upgrading to a more recent version though.

That I can confirm.
You changed the behavior of OCP some versions ago and since then I had no problems with vanishing macros.

Harald

[tarmon01]

Hi Martian and Harald, I’ll add a separate “issue” to ask for a “pass through unknown gcode” option. I don’t think you need anything that requires explicitly calling out each type that are allowed through. Just let em all pass through and let Grbl complain if it’s a problem. Perhaps To Harald’s point, perhaps allow the “Uknown ” pop up message to be logged to a file instead of a separate window that has to be okayed? That way you can check it once and doesn’t become a pest factor each time it is loaded. But i’m okay as it is. Or what Harald said. I do use homing switches. As Grbl does support these work offsets, I’m against you adding any additional commands or behaviors when you encounter an work offset command ie. causing it an grbl “alarm” would be not good for instance. Thanks all,

…

-TomH-

> On Mar 25, 2020, at 8:07 AM, deHarro ***@***.***> wrote:  Hi Martin, you'd have to use G0 moves to unambiguously position the tool in all three axes before using G1/2/3 etc again (just like you currently have to do at the start of a file). that sounds pretty good. I do not use home switches, but perhaps someone else does, so I would ask: Will homing also "rearm" OCP? You shouldn't loose your settings when upgrading to a more recent version though. That I can confirm. You changed the behavior of OCP some versions ago and since then I had no problems with vanishing macros. Harald — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[martin2250]

@deHarro, @tarmon01 I've explained what I mean by "use G0 moves to unambiguously position the tool" better in #125, you don't have to home your machine and it won't raise an alarm.

Martin