Estlcam v12

Neither the default or user entered secondary path (Group) names are used in v12 Previews or G-code. Preview paths have to be clicked line by line to insure the machining order will be correct. Descriptive G-code block names make it easier to see what's happening when running or manually editing the G-code. They also make controller pauses for partial block skipping (v12 Start depth bug) and starting with end of the program blocks (that need to, but cannot be, machined first in v12) easier. An all purpose workaround is to find/'go No. n' G-code block numbers, e.g. 'go no. 9' to drill first.
[ comment | link | top ]

V11 has dedicated 'CNC Presets', 'Post Processors', and 'Tool Lists' subdirectories (in C:\ProgramData\Estlcam\V11) for saving/opening multiple/different configuration files and tool lists. V12 has no such subdirectories and will default to the directory of the last opened drawing, project, etc.

A workaround is to create a C:\ProgramData\Estlcam\V12 subdirectory for saved files and pin it to Quick Access in File Explorer so that its relatively easy to get to. A single directory works because all open/save/restore functions use files with different file extensions and only the applicable files, e.g. .tl tool lists, will be shown.
[ comment | link | top ]

This is a big and hard to cover topic. The primary issue is that v12 forces all secondary pocketing tool paths to the start of the program while v11 placed them in front of the associated primary tool paths. Any two-sided or complex project where something else needs to be machined first pretty much requires using v11 or multiple project files*. Both v11 and 12 force all secondary finishing/profiling paths to the end of the program. If they need to be machined earlier than at the end of the program they can be set as separate primary paths.

Only primary tool paths can be machined in a specified order using the No.: field. Secondary tool path machining order is determined by Estlcam which pretty much totally ignores any user set primary path machining order, i.e. there is no way to fix simple/logical things that Estlcam gets wrong because it ignores the user set machining order.

*When using the Estlcam controller and any/all finishing/profiling paths are set as primary paths, all need to be machined first (before pre-pocketing) blocks can be placed at the end of the program. Instead of starting the program from the beginning, start with an Estlcam controller 'go No. [block #]' command where 'block #' is the first of the need to be machined first blocks. When the program finishes with the need to be machined first blocks Estlcam will automatically go back to the top of the program and machining can be resumed with the forced to the beginning pre-pocketing blocks.
[ comment | link | top ]

Edit Drawing is an easy way to edit a single layer project drawing. Apparently Estlcam cannot (re)build a DXF with layers because of how it stores/uses the layers it retrieves from DXF files. Projects with more than one layer need to be edited externally and reloaded w/ Update drawing to preserve the layers. I have not been able to confirm other reported (@ v1e) Edit Drawing issues.
If the edit includes adding new layers they will be preserved. It's kind of roundabout, but if the edit is all on new layers, the old layers that were grouped into a single layer can be deleted and the old layers can be restored using the Add drawing function. This would work better with v11 because it automatically registers the added drawing. In v12 the added drawing has to be manually moved/registered which may require adding registration marks.
[ comment | link | top ]

Part to Part Island pockets are useful to insure full face machining on material edge to edge pockets. They don't work in v12 (do in v11). A workaround is to Resize the perimeter. Stepped object faces would be easiest as a separate layer, e.g. a layer with an Island object and a duplicate oversized perimeter object.
[ comment | link | top ]

Since there isn't much in the way of documentation, my assumption that macros can have comments may have been wrong. In any case, lines in parenthesis are parsed and if they include a valid command it is executed. Something changed some version back when I started seeing 'invalid command' messages for a "<" character in a comment. Either error messages were added or Estlcam started parsing comments. The workaround is to make sure comments don't include (in)valid commands.
[ comment | link | top ]

For some time now I have seen some odd little inexplicable X/Y/Z axis jumps on random rare occasions when using a touch plate (probe menu or macro). In most? cases they appear to be harmless (e.g. it has zero effect on the X/Y/Z 0 macro used for the video), but I have seen other end of the macro numbers not being exactly what they should be. The issue may be more likely to occur when testing a macro multiple times in a row. It also appears that jogging X/Y and/or Z before probing/running a macro is a way to avoid the issue.

YouTube video (turn on subtitles)
[ comment | link | top ]

The ability to create an STL DXF mask from within Estlcam (STL > 2D > Edit drawing > Save as) is invaluable. In short, changes in v12.119 broke this functionality. There are two issues, a missing perimeter line (e.g. image) and, in some cases, the extra drawing lines have to be removed before the file is usable as a mask (e.g. my post @ v1e). The tested workaround is to temporarily install v12.117 (anything < v12.119).

...The first half of the YouTube video shows how to create a DXF mask using Inkscape (Setup > Basic > Editor) and v12.117. The second half of the video goes through the same steps using v12.125 (doesn't work).
[ comment | link | top ]