lcd dro+ sdcard+ keypad =autonomous lathe

[how-eee]

Almost finish combining this project with https://github.com/bdurbrow/grbl-Mega Everything is working on the table. Here is what I have for the moment https://youtu.be/N7hlYoIhV2g Here you can see what parts it consist of https://youtu.be/8M4gzLkSXls

• Need to check control pins masks and logic.
• Add new threading related settings into lcd menu.
• Check that eeprom save these settings correctly.
• Try it on real lathe.

Feel free to comment and ask if you have something. If you want to be betatester I'll appreciate your help.

[HuubBuis]

I have seen the video's and it is looking good. Place a link to the video's in your text so others can benefit.

I think the way you made your encoder (big red knob) is also usable for a spindle encoder.

Good work

I hope to see a video testing on a lathe soon.

[how-eee]

Have tried it on lathe. It has so many issues. Sad (

• Limit switches. I solder NC mechanical switshes with pullup 5kohm to +5 and 0.1mF (104) capasitor to ground. Since that I need to invert limit pins logic. $5=1 invert it and Y pin (which unused) get triggered. But XZ pins still triggered regardless their switch position. Cant figure out whats wrong.
• When started job gcode containing many lines from Sdcard, it cuts too deep. display dro shows x=13mm, but actual position is x=13.5 for example. Steps per mm is correct. Single line like G1X13F200 moves axis exactly to x=13. Not sure whats wrong with it. Maybe that due to 3 digits after point (0.001) in Gcode file, but 4 in firmvare (0.0001). Errors become accumulated? not sure. Also didnt tried to seng that file via USB
• Interferiance and electrical noises inducted in all lines. So many. I use shielded control box, shielded wires, RC filters.. Grounded lathe base. But sometimes bugs appears on display.
• I cant debug my code. Arduino 2.0 useless for the moment. I need additional hardware to debug 2560 with it. I have no any for now...

I am very disappointed. Understood that cant figure out it all by myself only. Need help of someone who did it many times...

Here is short video in the begining of testing, so no any issue is on video. https://youtu.be/dcXR74F-ByY When time permit I'll shoot video with my issues. Thanks

[HuubBuis]

I am very disappointed.

Developing software and hardware isn't easy. It takes a lot of effort to get things working. Solve problems one at a time until they are all done.

Interference and electrical noises inducted in all lines. So many

To avoid interference:

• I have my 2560 controller connected to my tablet using WiFi or Bluetooth. On the mini lathe, USB worked also but on the bigger BF290 I couldn't get it stable and industrial automation was part of my job for 20+ years.
• I use optocoupler on the controller digital inputs.
• USB cables with a ferrite filter (big round blok at one end of the cable) helps sometimes

Grounded lathe base

Make sure all parts are grounded at one point (star ground) to avoid ground loops through the control cables. Keep the sensitive logic signals far away from the high voltage/current cables.

Limit switches. I solder NC mechanical switshes with pullup 5kohm to +5 and 0.1mF (104) capasitor to ground.

You can use 1k pullups on the input, works just a bit better

But XZ pins still triggered regardless their switch position. You should connect unused inputs to GND (NC) or +5V (NO)

it cuts too deep. display dro shows x=13mm, but actual position is x=13.5 for example

• This could be a backlash problem, always zero after moving in the same direction as when cutting thread
• Mark the position of the stepper axis and check if it returns always to the exact same position. Maybe you pickup interference on the stepper pulse signal.

Try first to get normal turning and facing working. Then move on to threading. You could usage a caliper on the lathe to check the repeatability of the positioning.

[HuubBuis]

There is also a grbl compiler option to reduce noise GRBL-L-Mega WiKi, the chapter Changed Compiler options:

in file config.h Electrical interference caused by powering the lathe on and off (starting the spindle motor), can trigger the limit switches. By enabling GRBL software debounce, false triggers can be prevented.

define ENABLE_SOFTWARE_DEBOUNCE // Default disabled. Uncomment to enable

[how-eee]

try first to get normal turning and facing This lathe worked good enoth with plain arduino uno and clean grbl via usb. No any issues was detected. NO any backlash also.

I will check one more time all that items you pointed to. Thanks for the help.

[HuubBuis]

This lathe worked good enoth with plain arduino uno and clean grbl via usb

This is very good to hear. First try the setup that has proved to be working OK. If it still is working OK, than you must be able to get your software working. The procedure to follow is to start by using the good working code and implement your changes one by one. Test after every change if it is still working OK.

Enabling debouncing was the only way I could get may larger lathe working stable. It is worth to try first!!!

[how-eee]

Main problems was solved/

• Checked Limit switches inverts in code. Works fine now.

• Found reason why it cut too deep. My fault. Wrong measure of stock diameter and wrong gcode. But there was a positive side => checked all axis backlash with micrometer dial. Tightened all bolts and nuts. Found that I need to increase microstepping. Now it has 1/8steps and only 320 steps/mm.

• Separeted Ground and minus wires.

• Found another portion of software issues :) Which is:

• [x] State_alarm is still active after homind with menu. Cant find reason.

• [x] Reset control button acts wrond when in feed hold. It stops spindle, but didnt stop moving until press twice. Cant find reason.

• [x] Part_Zero key in jog menu zeroing machine position instead of active coord system ("G10L20P0"). Solved ("G10L2P"+ gc_state.modal.coord_select + 1) like this.

• [x] SD ard failed to detect card inserted after homing. Again that cfking homing!

[how-eee]

Noticed that sd_detect (port L0) pin on same port as CTR_Door(L6) CTR_FeedHLD(L4) CTR_reset(L2). Maybe here is problem somewhere...

[HuubBuis]

Now it has 1/8steps and only 320 steps/mm

320 steps/mm is enough for decent turning.

State_alarm is still active after homind with menu. Cant find reason.

Homing on a lathe is normally 2 axis. Grbl defaults to 3 axis. You should set the homing sequence for a lathe: https://github.com/MetalWorkerTools/grbl-L-Mega/wiki/Changed-Compiler-options

It is important that grbl is in an error free state before sending commands. I sometimes use UGS (platform version) for diagnostics. The output window can be set to verbose (right mouse button) so you can see all errors reported by grbl. It also shows the pin states that makes it easier to identify pins that are in an alarm or active state.

Depending on homing settings in config.h grbl could require homing first before running any commands.

I have no experience in using a sd card on grbl controllers.

[how-eee]

I have created repository with a project here on github. https://github.com/how-eee/grbl_lathe_UI_threading

have read out almost all code. cant find difference of parsing $H sended via usb and via lcd menu. But via lcd menu I have alarm in the end of homing cycle, via usb all is ok.

[HuubBuis]

have read out almost all code. cant find difference of parsing $H sended via usb and via lcd menu. But via lcd menu I have alarm in the end of homing cycle, via usb all is ok

I remember I had such an issue using grbl_ESP32 sending commands using USB and Bluetooth was OK, using WiFi didn't work. The cause was the line termination used. cr of lf didn't work. I don't remember witch caused the problem. The solution was sending crlf.

[how-eee]

I have fixed almost all issues. Tested on my lathe. No any remarks at the moment. But I didnt test threading on machine yet. On the table it was good. I hope next week Ill make video with all main features demonstrated.

[HuubBuis]

Sounds good