toolchangez parameter is not in the parameter list for drillcncjob TCL command. Though, it's easy enough to add. Thanks for pointing it out, I will make this correction in my Nightly's :)
Thank you so much. During my testing I also found out there is two issues in the nightly version 10052018: 1) command line is not visible as the default setting, 2) the not enough time between commands millholes and cncjob during execution ... the problem is that cncjob shows following error: ERROR: Object not found: Drill.drl_mill while executing "cncjob Drill.drl_mill -z_cut -2.0 -z_move 1.0 -feedrate 300.0 -tooldia 1.6 -spindlespeed 24000 multidepth true -depthperpass 1" But when I divide executing of the whole code into the two parts, everything is doing well. All the code to execute: new open_gerber C:/CAM/Edges.gbr open_gerber C:/CAM/Bottom.gbr open_excellon C:/CAM/Drill.drl mirror Bottom.gbr -axis X -box Edges.gbr mirror Drill.drl -axis X -box Edges.gbr isolate Bottom.gbr -dia 0.18 -passes 1 cncjob Bottom.gbr_iso -z_cut -0.15 -z_move 1.0 -feedrate 300.0 -tooldia 0.18 -spindlespeed 24000 multidepth false write_gcode Bottom.gbr_iso_cnc C:/CAM/01_Engrave.tap drillcncjob Drill.drl -tools 1,2 -drillz -2.5 -travelz 1.0 -feedrate 300.0 -spindlespeed 24000 -toolchang e true write_gcode Drill.drl_cnc C:/CAM/02_Drill.tap millholes Drill.drl -tools 3 -tooldia 1.6 HERE IS THE ERROR, WHEN THE WHOLE CODE IS EXECUTING ... BUT WHEN YOU DIVIDE THE PROCESS INTO 2 PARTS - BEFORE AND AFTERTHIS POINT, EVERYTHING PASSES WELL cncjob Drill.drl_mill -z_cut -2.0 -z_move 1.0 -feedrate 300.0 -tooldia 1.6 -spindlespeed 24000 multidepth true -depthperpass 1 write_gcode Drill.drl_mill_cnc C:/CAM/03_Mill_holes_1_6_mm.tap cutout Edges.gbr -dia 1.6 -margin 0.0 -gapsize -1.6 -gaps tb cncjob Edges.gbr_cutout -z_cut -2.0 -z_move 1.0 -feedrate 300.0 -tooldia 1.6 -spindlespeed 24000 multidepth true -depthperpass 1 write_gcode Edges.gbr_cutout_cnc C:/CAM/04_Mill_edges_1_6_mm.tap
And next issue ... the right bracket is missing in the change tool comment in g code (in nightly version 10052018), i.e. for example: ... M6 (MSG, Change to Tool Dia = 0.80 M0 ... This code doesn't pass in Mach3 software, you have to add brackets manually.
Command line is o visible as the default setting: is by design, I personally prefer to not have it open until I need it. In the near future, once I will consolidate all the app setting into a EDIT -> Preferences entry, I may make it this behavior optional. About the issue with not enough time between jobs, this is a bit too hard for me. I think it may have to do with the multiprocessing implemented in the VisPy edition by Dennis. About the right bracket, you are right, it is already fixed. I found this, too, when looking to improve the toolchange command. It is in the code because initially I just copy-paste the postprocessor "default.py" file from newcamlib_2 branch and it did contain some issues. I am in the process of redesigning a bit the multiprocessing (adding the multiprocessing combobox in the Excellon objectUI), after that I will release a new Nightly with the fixes and enhancements.
Thank you again for your effort. It is excellent project. BR, Josef.
Hi Josef, I'm only playing around with what other people have done. To be honest, for every change I am doing in the program I'm more and more amazed of the hard work that JP and the rest of the contributors have already done ... Marius.
Hi Marius, thanks for implemented changes. Unfortunately, "drillcncjob" command still doesn't do the job perfectly: a) first hole in every diameter is written 2x in the resulting G code. b) -toolchangez (thank you for adding this feature) probably moves machine to "End move Z" position instead of "Tool change Z" position ... it is very interesting, that this behaviout is visible only from command line c) I would expect that -endmovez parameter should be also available for "drillcncjob" command The issue with time between "millholes" and "cncjob" is persisting, as you suspected. BR, Josef.
Hi Josef, In the latest Nightly I implemented the persistent status of TCL shell window at startup based on a setting in the Application Defaults. It was interesting you last time we discussed. About the issues named above: a) this is an unfortunate side effect from introducing the Excellon move optimization based on the "Travelling Salesman" algorithm. But should not be a problem, after all it's just one extra drill action among many drill actions .... Once I will use the Rtree optimization this should not be present anymore. But it's not a priority. b) there was a bug in the drillcncjob, which I solved, that used the endz parameter as the toolchange z and the endz parameter ended up having a default value = 1 c) due to the above solved bug, the endz parameter was not used correctly. The parameter was there (and it is in the "cncjob" command, too) but things were messed. About the issue with the required time between "millholes" command and "cncjob", I've looked into the source code and someone made a note there "# This runs in the background... Is blocking handle d?". Guess no, so until it is fixed (I don't know how, yet), you have to cope with it. The "cncjob" command had a bug itself, it was using always multidepth = True. Solved. All of those and many other improvements (mostly in GUI) are in the latest Nightly. One "command line" improvement that might interest you is that after creation of a new object, the name is saved to clipboard so all you need to do is CTRL+V in the TCL window and you have pasted that name in the command line. :)
Hi Marius, yes, I foud out this change in Defaults previously, but I forgot it to mention in my previous reply, thank you very much. It is really helpfull. Just a question rises on my mind - there is a choice in the menu: "Edit" - "Preferences". Is there any reason for that? ad b) thanks a lot, it is now really fully usable. Just an idea for improvement: new tool after it's change (generally also after start of G code) could move to "Travel Z" with rapid move (G0) and after that speed could slow down to G1 (feed rate). Also getting out from the holes could be realized by G0 to minimize time of drilling tool in the PCB. But it can be perceived as the preference of course. ad c) ok, you are super hero :-) ad a) and "time between “millholes” command and “cncjob” ... it will be perfect to solve these issues, but you are right, it is not priority.
Hi Josef, The problem in solving the issue with not having blocking handled for the millholes command is my lack of knowledge on how to do it, more then the low priority of things. I still don't understand a lot in the program structure. The Edit -> Preferences is there because I believe it will be better for FlatCAM if all the various settings will be centralized out of the Options TAB into their own window. For now, I linked the Preferences choice from EDIT to the Options TAB but in the future all those settings should be put together into a separated window. Regarding the way "startup code" and "drill hole is handled. That's the reason why the concept of "postprocessor" was introduced. To allow implementation of those things. It's limited in the sense that the postprocessor files are not available for user change. Regarding the speed of drill exiting out of the hole. It's been discussed a while back ... I too, lobbied for having the return move out of the hole as fast as possible (to minimize the drill usage and also to speed things up - it can dramatically lower the total drill time) but there were arguments against and in the end JP settled for a compromise: drill down with G01, drill up from cutz depth to Z0 with G01 and then from Z=0 to Travel Z with G00. In my experience, for drill bits with diameter more than 0.6mm, you can get away with having G00 speed for the entire move out of the hole, but with drill bits less than that, I've broken some. It's still unclear if there were other issues that broken my bits but I choosed "better safe than sorry" policy.
Hi Josef, Try the Nightly that I will post very soon. I think I solved the issue with the milling command by disabling the usage of multithreading for the milling command (it was running in background and the other processes didn't know when it was finished). In one of the latest builds I already added a new optimization, Rtree indexing, for the drill moves. If you select it in the Options Tab -> Excellon Options, you should no longer see that twice drilling for the first hole. In any case, by porting to Python3 I previously broke the generate milling command and I fixed it and will post the fix soon. This port to Python3 brought an spectacular increase in performance ... but I still have to solve things. Hopefully not many.
Dear Marius, thank you for good news. I can confirm timing issue is solved now and problem with first hole is also out. What I found out is feedrate parameter "Feed Rapid rate" in the excellon object processing ... this parameter is not available form the shell command (or I don't know it's name) and therefore every G1 movement is interpreted with the speed F3.0 ... and it is really very slow movement, you know ... Is there any chance to influence it? Thank zou in advance. BR, Josef.
Feedrate_rapid parameter has influence only if the postprocessor allow it. In our case, only the Marlin postprocessor is using it. I've remade the cncjob and drillcncjob Tcl commands. They should work now. I am adding a new Nightly right now.