Home : Workshop : CNC :
A center origin is used when you want to center a project/drawing on the material being cut. It's easy if your drawing has a center point mark (Zero/origin first 2 options), but there are a lot of shapes (3 shown) that have a circumcenter (three point/triangle circumcircle center) which makes for a pretty flexible third option.
You can either mark the center of the material, so you can manually center the bit and zero X/Y, or use the Estlcam center probe options to precisely center the bit and automatically zero X/Y. Note: The probing options work on parts/outside and holes/inside, e.g. zero probing inside and outside corners. Probing at 45 degrees also works and can be handy when probing circles.
[ comment | link | top ]
With no relatively inexpensive Estcam (or GRBL) pinout shields available to the US I've been making my own. The pictured Nano shield (w/o Nano) is the latest and currently supports drivers, probe, DC-AC relay/VFD run and VFD speed - all but the probe are isolated via external optocouplers. While I have no need for them, I may add a daughter board for isolated limit switches (via 6 pin stacked header).
While I had been using pins and plugs and was planning on upgrading to latching plugs, the layout seemed to work better with screw terminals (the driver gnd pins/plugs were an as-built change). Especially on the crowded top row, using crimp ferrules makes it much easier to (re)hook things up reliably. The primary purpose of the design was having the signal and ground terminals next to each other to maximize shielding and minimize mess (not possible w/ a basic screw shield).
The motivation was Estlcam USB errors, which it appears can be caused by any signaling/wiring issue. While the cause could have been a single bad connection, I decided to rewire everything with shielded cables. I used two shielded pair 22awg sound/security cable for everything not in the drag chain. The cable allowed shielded signal/ground pairs from all external components (e.g. driver step/gnd and dir/gnd) all the way to the adjacent signal/ground terminals on the shield. The cable was also convenient for shielded 24v and ground pairs between the power supply and drivers - 2 x 22awg = 19awg.
[ comment | link | top ]
The Estlcam controller software can be installed on boards with with ATmega328 (e.g. Uno and Nano) or ATmega2560 (Mega) micro controllers. 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 (optoisolation, adjacent sig/gnd pins, etc.) that can make them more reliable. While there are only a few Estlcam specific boards, Estlcam can be installed on most? GRBL boards. 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)... Shipping to the US is expensive, but it is now available from Rocketronics (~$91 shipped). 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. The YRCNC UNO shield w/ isolation looks like a good Estlcam compatible GRBL shield, but it could cost as much as the Estlcam board when shipped to the US. I'm too cheap so my latest DIY is a custom Nano shield (external optocouplers, e.g. VFD run and speed).
...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 ]
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 multiple (de)selectable options are weighted (e.g. image) / constrained (e.g. holes under/over a specified size get drilled/routed). Unlike Easel, Estlcam can read DXF layers which makes (auto-)selection so much easier.
This 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.
10-23-21: While Estcam can lock/unlock DXF layers to allow auto-selecting paths by layer, running auto-select multiple times (e.g. on multiple layers for multiple bits/DOC's) requires locking (Edit menu lock and View layers lock) the already selected/configured paths and layer so that they don't get modified or re-selected on subsequent runs.
Since it took me a while to get it:
The View Layers DXF layer lock only prevents the creation of (new) paths on that layer.
The Edit menu layer lock only prevents the modification of that layers set/configured paths.
Using layers makes (auto-)selecting easy and reliable, great for any project with any combination of cut types and bits/DOC's.
[ comment | link | top ]
Estlcam
Estcam contains CAM and CNC controller programs. Vector graphics (dxf and svg) and 3D (stl) files 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 program is easy to install on a lot of ATmega microprocessor/GRBL compatible hardware (e.g. Uno/Nano) and Estlcam will backup anything currently installed on the hardware. If the hardware isn't recognized, USB drivers may need to be installed (drivers for FTDI or WCH serial chips are the most common). 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.
Center Origin
A center origin is used when you want to center a project/drawing on the material being cut. It's easy if your drawing has a center point mark (Zero/origin first 2 options), but there are a lot of shapes (3 shown) that have a circumcenter (three point/triangle circumcircle center) which makes for a pretty flexible third option. You can either mark the center of the material, so you can manually center the bit and zero X/Y, or use the Estlcam center probe options to precisely center the bit and automatically zero X/Y. Note: The probing options work on parts/outside and holes/inside, e.g. zero probing inside and outside corners. Probing at 45 degrees also works and can be handy when probing circles.
[ comment | link | top ]
Nano Shield
With no relatively inexpensive Estcam (or GRBL) pinout shields available to the US I've been making my own. The pictured Nano shield (w/o Nano) is the latest and currently supports drivers, probe, DC-AC relay/VFD run and VFD speed - all but the probe are isolated via external optocouplers. While I have no need for them, I may add a daughter board for isolated limit switches (via 6 pin stacked header).
While I had been using pins and plugs and was planning on upgrading to latching plugs, the layout seemed to work better with screw terminals (the driver gnd pins/plugs were an as-built change). Especially on the crowded top row, using crimp ferrules makes it much easier to (re)hook things up reliably. The primary purpose of the design was having the signal and ground terminals next to each other to maximize shielding and minimize mess (not possible w/ a basic screw shield).
The motivation was Estlcam USB errors, which it appears can be caused by any signaling/wiring issue. While the cause could have been a single bad connection, I decided to rewire everything with shielded cables. I used two shielded pair 22awg sound/security cable for everything not in the drag chain. The cable allowed shielded signal/ground pairs from all external components (e.g. driver step/gnd and dir/gnd) all the way to the adjacent signal/ground terminals on the shield. The cable was also convenient for shielded 24v and ground pairs between the power supply and drivers - 2 x 22awg = 19awg.
[ comment | link | top ]
Controller Hardware
The Estlcam controller software can be installed on boards with with ATmega328 (e.g. Uno and Nano) or ATmega2560 (Mega) micro controllers. 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 (optoisolation, adjacent sig/gnd pins, etc.) that can make them more reliable. While there are only a few Estlcam specific boards, Estlcam can be installed on most? GRBL boards. 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)... Shipping to the US is expensive, but it is now available from Rocketronics (~$91 shipped). 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. The YRCNC UNO shield w/ isolation looks like a good Estlcam compatible GRBL shield, but it could cost as much as the Estlcam board when shipped to the US. I'm too cheap so my latest DIY is a custom Nano shield (external optocouplers, e.g. VFD run and speed).
...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 multiple (de)selectable options are weighted (e.g. image) / constrained (e.g. holes under/over a specified size get drilled/routed). Unlike Easel, Estlcam can read DXF layers which makes (auto-)selection so much easier.
This 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.
10-23-21: While Estcam can lock/unlock DXF layers to allow auto-selecting paths by layer, running auto-select multiple times (e.g. on multiple layers for multiple bits/DOC's) requires locking (Edit menu lock and View layers lock) the already selected/configured paths and layer so that they don't get modified or re-selected on subsequent runs.
Since it took me a while to get it:
The View Layers DXF layer lock only prevents the creation of (new) paths on that layer.
The Edit menu layer lock only prevents the modification of that layers set/configured paths.
Using layers makes (auto-)selecting easy and reliable, great for any project with any combination of cut types and bits/DOC's.
[ 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. Many 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 ]