Home : Workshop : CNC :
The Estlcam controller software can be installed on boards with with ATmega328 (e.g. Uno and Nano) or ATmega2560 (Mega) processors. While an Arduino board and a simple screw shield is all that is required, there are numerous CNC specific shields and controller boards with added features (e.g. optoisolation) that can also be used. While there are only a few Estlcam specific boards, many of the GRBL boards can run Estlcam. The primary difference is the processor pin layout and Estlcam can be configured to use Estlcam or GRBL layouts.
The Estlcam Terminal Adapter is the only Estlcam specific control board (pictured), but it is only available in the EU (~50EUR) unless you make it yourself (complete open source documentation available). The only ready-made (or kit) Estcam specific shields, that I know of, are available from ArduinoClub.de (Germany). Tonio Grawe provides all the documentation needed to make a basic (no isolation) Estlcam Uno shield
...Slightly off topic at this point, but I noticed at the end of the Estlcam controller page he mentions increasing the responsiveness of the controller by having Windows check for new data from the controller more often than the default 16ms. This appears to only be an option with the FTL USB2serial driver, i.e. the Estlcam FT230XS and Nano (and old Mega) FT232R chips. The Uno and Mega 2650 use the Atmega16U2 (older = 8U2) and most of the cheap Arduino clones use a cheap CH340 chip which has no latency option.
While a common recommendation is to set the FTL USB2serial chip driver to 1ms intervals (e.g. Digi), FTL themselves do not recommend 1ms because it "is the same as the USB frame length"*. SeaLevel does "not recommend setting the latency timer below 4 msec" and 4ms is apparently the latency of the Uno Atmega8u2 (no hits on the 16u2) so 4ms sounds like a good starting point. I have no idea when/if the extra I/O might be an issue.
[ comment | link | top ]
Estlcam
Estcam contains CAM and (Arduino) CNC controller programs. Vector graphics files (dxf, svg and stl) can be imported and machined using Estlcam. While doing everything in Estlcam is the simplest and most reliable route, the programs can be used individually to generate/export G-code for another controller or to import/machine G-code generated by another CAM program. The Estcam controller is easy to install, it does not require any Arduino related setup and will backup anything currently installed on the controller. The Estlcam controller is free, the CAM program is free to try (becomes nagware w/ increasing wait times to generate/machine G-code) and ~$60 to buy.
Controller Hardware
The Estlcam controller software can be installed on boards with with ATmega328 (e.g. Uno and Nano) or ATmega2560 (Mega) processors. While an Arduino board and a simple screw shield is all that is required, there are numerous CNC specific shields and controller boards with added features (e.g. optoisolation) that can also be used. While there are only a few Estlcam specific boards, many of the GRBL boards can run Estlcam. The primary difference is the processor pin layout and Estlcam can be configured to use Estlcam or GRBL layouts. The Estlcam Terminal Adapter is the only Estlcam specific control board (pictured), but it is only available in the EU (~50EUR) unless you make it yourself (complete open source documentation available). The only ready-made (or kit) Estcam specific shields, that I know of, are available from ArduinoClub.de (Germany). Tonio Grawe provides all the documentation needed to make a basic (no isolation) Estlcam Uno shield
...Slightly off topic at this point, but I noticed at the end of the Estlcam controller page he mentions increasing the responsiveness of the controller by having Windows check for new data from the controller more often than the default 16ms. This appears to only be an option with the FTL USB2serial driver, i.e. the Estlcam FT230XS and Nano (and old Mega) FT232R chips. The Uno and Mega 2650 use the Atmega16U2 (older = 8U2) and most of the cheap Arduino clones use a cheap CH340 chip which has no latency option.
While a common recommendation is to set the FTL USB2serial chip driver to 1ms intervals (e.g. Digi), FTL themselves do not recommend 1ms because it "is the same as the USB frame length"*. SeaLevel does "not recommend setting the latency timer below 4 msec" and 4ms is apparently the latency of the Uno Atmega8u2 (no hits on the 16u2) so 4ms sounds like a good starting point. I have no idea when/if the extra I/O might be an issue.
[ comment | link | top ]
Autoselect and Layers
Even on simple projects, having CAM programs auto-select cutting paths can be hit and miss. If the project involves more than one type of cut, e.g. inside and outside of the line, auto-select will be weighted to one or the other and paths will probably need to be edited. Easel auto-selects by default and provides three unweighted options (in/out/on) when importing a drawing. Estlcam auto-select is optional, includes more cut types (e.g. drilling) and the options are weighted (e.g. holes/in) / constrained (e.g. holes under/over a specified size get drilled/routed). Unlike Easel, Estlcam can read DXF (and SVG?) layers which makes (auto-)selection so much easier.
The example image is a layered DXF generated by the BeeHome project and imported into Estlcam. The layer names provide all the information needed to auto-select (e.g. weighted inside/hole) and set the parameters for cutting the paths (bit size, cut depth and pocket). I spent a whole lot of time on just one part of that DXF trying to edit all the paths in Easel before deciding it was just too tedious for a one off project.
...While Estcam can lock/unlock layers to allow auto-selecting paths by layer, auto-select can only be run once. The layer lock only limits what parts of the drawing Estcam will run auto-select on, it doesn't lock/hide already created paths. Changing bits or DOC and running auto select again will redo/change any paths set during the first run... I haven't tried the Edit menu group and lock options which may negate the above. At a minimum, grouping the autoselected paths could help, e.g. deselecting those paths, when adding/editing more paths.
Using layers can make (auto-)selecting easy and reliable, great for single bit/DOC projects or - where multiple bits/DOC's are needed - layer by layer cutting (easy when the controller is also running Estlcam) - not so great when the goal is a single multiple bit/DOC g-code file.
[ comment | link | top ]
The example image is a layered DXF generated by the BeeHome project and imported into Estlcam. The layer names provide all the information needed to auto-select (e.g. weighted inside/hole) and set the parameters for cutting the paths (bit size, cut depth and pocket). I spent a whole lot of time on just one part of that DXF trying to edit all the paths in Easel before deciding it was just too tedious for a one off project.
...While Estcam can lock/unlock layers to allow auto-selecting paths by layer, auto-select can only be run once. The layer lock only limits what parts of the drawing Estcam will run auto-select on, it doesn't lock/hide already created paths. Changing bits or DOC and running auto select again will redo/change any paths set during the first run... I haven't tried the Edit menu group and lock options which may negate the above. At a minimum, grouping the autoselected paths could help, e.g. deselecting those paths, when adding/editing more paths.
Using layers can make (auto-)selecting easy and reliable, great for single bit/DOC projects or - where multiple bits/DOC's are needed - layer by layer cutting (easy when the controller is also running Estlcam) - not so great when the goal is a single multiple bit/DOC g-code file.
[ comment | link | top ]
Estlcam VS Easel
...Most of what I post in the Estlcam category will have some Estlcam VS Easel aspect. Both are CAM and control packages and I spent a lot of time with Easel before switching to Estlcam. While Estlcam has a lot more features than Easel, the interface is not as clean/intuitive as Easel and v-carving text is easier with Easel.
One of the key functional differences between Estlcam and Easel is that Easel can only cut inside/outside of a closed line/path (e.g. a circle). Any shape with ends that don't meet (e.g. a line) can only be "Cut on shape path". I'm guessing that the closed line restriction/awareness is why Easel will never cut past the line. Any irregular pocket cutting (e.g. text) with a straight bit is affected. If the space between two lines is smaller than the bit, Easel won't cut it.
Estlcam can cut to the right/left of any line and it is a very useful feature, e.g. being able to cut a shape on the end/edge of a board. Unlike Easel, Estlcam will cut past the line if the space between two lines (e.g. text) is smaller than the bit. As with Easel, zooming in and scanning the preview is important. Side note until it has a better place. Estlcam line (VS shape, i.e. engraving) cutting is bidirectional, i.e. very efficient, until one adds a finish pass. All passes are bottom to top when there's a finish pass, i.e. not very efficient. This also means that all left of the line cutting is climb cut and all right of the line cutting is conventional cut (regardless of cut setting)... a workaround is to manually set the point to point path (1st point = cut start). With bidirectional cutting any machine/bit flex will create noticeable ridges on the cut face because each pass flexes in the opposite direction. At least with hobby machines, bidirectional cutting only makes sense if it can be followed up with a finish pass.
Another area where Estlcam and Easel differ is when cutting pockets. The example is a complex maze and both programs were set to cut parallel/offset (Estlcam changed/Easel default). Both generated paths that jump around a lot and it isn't obvious which moves around more. Both appear to use an ~40% stepover, but Estlcam leaves an ~20% path around the perimeter. While this does result in an additional path in some places, that 20% path is cut last - no finish pass required... Side note: Estlcam set to parallel provides the best results on narrow pockets, but the algorithm is too conservative/safe, i.e. too many unnecessary and time consuming passes
The Easel generated path includes some full width cuts along the perimeter (more likely to leave wall marks and top tearout). While both can leave islands (which can break and tear grain) and it would be nice to see everything cut from center out, Estlcam saving the perimeter for a 20% wide final pass is a big plus.
TBC
[ comment | link | top ]
One of the key functional differences between Estlcam and Easel is that Easel can only cut inside/outside of a closed line/path (e.g. a circle). Any shape with ends that don't meet (e.g. a line) can only be "Cut on shape path". I'm guessing that the closed line restriction/awareness is why Easel will never cut past the line. Any irregular pocket cutting (e.g. text) with a straight bit is affected. If the space between two lines is smaller than the bit, Easel won't cut it.
Estlcam can cut to the right/left of any line and it is a very useful feature, e.g. being able to cut a shape on the end/edge of a board. Unlike Easel, Estlcam will cut past the line if the space between two lines (e.g. text) is smaller than the bit. As with Easel, zooming in and scanning the preview is important. Side note until it has a better place. Estlcam line (VS shape, i.e. engraving) cutting is bidirectional, i.e. very efficient, until one adds a finish pass. All passes are bottom to top when there's a finish pass, i.e. not very efficient. This also means that all left of the line cutting is climb cut and all right of the line cutting is conventional cut (regardless of cut setting)... a workaround is to manually set the point to point path (1st point = cut start). With bidirectional cutting any machine/bit flex will create noticeable ridges on the cut face because each pass flexes in the opposite direction. At least with hobby machines, bidirectional cutting only makes sense if it can be followed up with a finish pass.
Another area where Estlcam and Easel differ is when cutting pockets. The example is a complex maze and both programs were set to cut parallel/offset (Estlcam changed/Easel default). Both generated paths that jump around a lot and it isn't obvious which moves around more. Both appear to use an ~40% stepover, but Estlcam leaves an ~20% path around the perimeter. While this does result in an additional path in some places, that 20% path is cut last - no finish pass required... Side note: Estlcam set to parallel provides the best results on narrow pockets, but the algorithm is too conservative/safe, i.e. too many unnecessary and time consuming passes
The Easel generated path includes some full width cuts along the perimeter (more likely to leave wall marks and top tearout). While both can leave islands (which can break and tear grain) and it would be nice to see everything cut from center out, Estlcam saving the perimeter for a 20% wide final pass is a big plus.TBC
[ comment | link | top ]
Estlcam Screen Rounding
Most on screen number entries in Estlcam are rounded to two (mm) or three (inch) decimal places and the common assumption is that Estlcam is storing/using the rounded numbers. The rounded on screen numbers do not appear to be stored or used by Estlcam. Most of the numbers Estlcam stores/uses appear to have sixteen decimal places. To see some of those numbers view the 'Settings CNC... .txt' file in 'Program Data Estlcam...'.
While entering something like 8.016mm for X-axis distance per revolution will be rounded to 8.02 on screen, the stored/used number will be 8.0159997940063477. I have no idea where that number comes from, but it is only off by .0000002mm. For a frame of reference, the rounded .004 difference divided by 20,000 equals the .0000002 stored/used difference.
[ comment | link | top ]
While entering something like 8.016mm for X-axis distance per revolution will be rounded to 8.02 on screen, the stored/used number will be 8.0159997940063477. I have no idea where that number comes from, but it is only off by .0000002mm. For a frame of reference, the rounded .004 difference divided by 20,000 equals the .0000002 stored/used difference.
[ comment | link | top ]