Home : Workshop : CNC : Estlcam :
The Estlcam controller firmware 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 more than the cost of the board, but it is ...once again (nov21) available from Rocketronics (~$113 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's ~$83 when shipped to the US. I'm too cheap so my latest DIY is a custom Nano shield
...Slightly off topic at this point, but I noticed that at the end of the Estlcam controller page Christian 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 (right) chips. The Uno and Mega 2650 use the Atmega16U2 (older = 8U2) and most of the cheap Arduino clones use a cheap CH340 chip (left) 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... Somehow I missed that Christian suggests 2ms. I have no idea when/if the extra I/O might be an issue.
[ 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 (e.g. spindle run and PWM). 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/EMI issue. While the cause could have been a single bad connection (...a loose mini USB plug/socket), 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 ]
Estlcam storing the X/Y origin scores another point and I'm kicking myself for not noticing it earlier. After tweaking the the distance per revolution (DPR) setting and rewriting the ATmega, the controller window that pops up is updated to reflect the change. In my case, bumping up the DPR by .001mm moved me .08mm closer to my 650mm target (origin @ 100) - no math required :).
I used what I hope is an accurate steel rule and fixed one end securely to the spoilboard. Eyeball measurements aren't very accurate so I used a 10/20 degree engraving bit, a flashlight and a magnifier. Getting the flashlight centered behind the bit, getting the bit as low as possible and rotating the bit (because of the flutes, the tip appears to move from side to side and centering it in the grove can be tricky) all helped.
[ comment | link | top ]
Hardware
Controller Hardware
The Estlcam controller firmware 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 more than the cost of the board, but it is ...once again (nov21) available from Rocketronics (~$113 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's ~$83 when shipped to the US. I'm too cheap so my latest DIY is a custom Nano shield
...Slightly off topic at this point, but I noticed that at the end of the Estlcam controller page Christian 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 (right) chips. The Uno and Mega 2650 use the Atmega16U2 (older = 8U2) and most of the cheap Arduino clones use a cheap CH340 chip (left) 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... Somehow I missed that Christian suggests 2ms. I have no idea when/if the extra I/O might be an issue.
[ 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 (e.g. spindle run and PWM). 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/EMI issue. While the cause could have been a single bad connection (...a loose mini USB plug/socket), 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 ]
Axis Calibration
Estlcam storing the X/Y origin scores another point and I'm kicking myself for not noticing it earlier. After tweaking the the distance per revolution (DPR) setting and rewriting the ATmega, the controller window that pops up is updated to reflect the change. In my case, bumping up the DPR by .001mm moved me .08mm closer to my 650mm target (origin @ 100) - no math required :).I used what I hope is an accurate steel rule and fixed one end securely to the spoilboard. Eyeball measurements aren't very accurate so I used a 10/20 degree engraving bit, a flashlight and a magnifier. Getting the flashlight centered behind the bit, getting the bit as low as possible and rotating the bit (because of the flutes, the tip appears to move from side to side and centering it in the grove can be tricky) all helped.
[ comment | link | top ]