2 DRO and display issue

[UberChmonya]

Hi, I really like your project! Is it possible to create an encoder for each axis (MPG) in the project? It would be very nice. I completely removed the mechanical control of the axes from the machine. Also, I could not find a display module for sale. What can replace it?

[hobbymachinist]

Thanks.

Sorry, I don't plan on adding support for multiple MPG encoders - I need the extra pins for additional features I'm working on. You can customise the code to suit your needs though, but I most likely will not be able to add support for it.

I could not find a display module for sale. What can replace it?

Did you check AliExpress or eBay ? ILI9481 based 480x320 TFT modules are fairly common

e.g. https://www.aliexpress.com/item/1984270730.html

[AndreyFly007]

Good day friend.

I need the extra pins for additional features I'm working on

Maybe there are details about which pins and interrupts will be occupied?

I started to repeat your device. I changed the printed circuit board, placed the connectors that are convenient for me. Aliexpress did not have the recommended screen. Therefore, the screen had to be ordered without an arduino shield. The screen will connect directly to the ELS, without a shield. Soon I will be able to share the printed circuit board (it remains to finish a few little things). I would be very grateful if you could expand the list of which pins and interrupts will be used.

At the moment, to use the second MPG, I have used pins PC0, PC1, as well as an interrupt on PC0. until the PCB is ordered, I have time to adjust the circuit for further compatibility with your project.

[AndreyFly007]

[hobbymachinist]

@AndreyFly007

I've left PC0, PC1, PC10, PC11, PH0, PH1 free for now. Rest are reserved, I might be able to free up some more pins after I change the board design to convert differential DRO signals to single ended.

The primary (MPG) encoder is used for menu selection and along with MPG for X and Z travel, I'd be interested to see how you're using 2 encoders in the user interface.

[AndreyFly007]

[AndreyFly007]

The primary (MPG) encoder is used for menu selection and along with MPG for X and Z travel, I'd be interested to see how you're using 2 encoders in the user interface.

the first MPG works without changes, menus, moving the Z axis. The second MPG will only be for the X axis. My machine does not have mechanical manual movement handles. The Z and X axes can only be controlled electronically.

[AndreyFly007]

[hobbymachinist]

@AndreyFly007 I don't want to discourage you, but it looks like you've done extensive changes. I would pause and think about what you really want in the end. It sounds like conversational wizard with Linux CNC, Mach 4 or Acorn would be much better. You can do everything this project does and much more. You can also use 2 MPG wheels for dual axis control.

This project is quite experimental and I'm doing it for fun, you're more than welcome to do the same but in terms of investing time and money to get the features you're after the above mentioned options could be better.

[hobbymachinist]

@AndreyFly007 See Kent's channel for how he's done it, https://www.youtube.com/watch?v=JdhNRhK3TCY. You can reach out to him to ask for tips if that's the route you want to take.

[AndreyFly007]

I like your project. This project has great potential for development. Superficially looked through the code, found many interesting solutions for synchronizing the spindle with the feed. There is almost everything for working with Gcode, the only thing left is the parser procedure. I know about all ready-made solutions (mach3, mach4, linux cnc), but they are not interesting to me. I love DIY projects. Your project is a great opportunity to plunge into the world of STM32.

[hobbymachinist]

There's a lot of scope for improvement, especially with PWM and DMA but that will need remapping of GPIO pins. For what it's doing at the moment, it's good enough. I might revisit optimisations once I have all the basic features implemented.

[AndreyFly007]

there is a very good example of Gcode parser on 2 axis on Github. For G0, G1, G2, G3 Gcode already has all the functions in your code. Code with a good description for Arduino, and can help you get started with GCode

https://github.com/MarginallyClever/GcodeCNCDemo/tree/master/GcodeCNCDemo2Axis

[hobbymachinist]

@AndreyFly007 thanks, I'll take a look. There are couple of good options for GCode but I'm leaning towards a modified version of GRBL and a complete rewrite of the ELS functions to use the motion controller in GRBL. This would allow it to keep up with any newer versions of GRBL as a GCode processor, motion & stepper / servo controller allowing it to work with CAM post processors.

[AndreyFly007]

I spent a lot of time looking for GRBL firmware for a lathe. None of them work with spindle synchronization. All I found is GRBL HAL, but even there it says that support for synchronization with the spindle is in test mode. After reading many forums, I have come to the conclusion that 90% of lathe operators write Gcode by hand in notepad. for CNC lathe it is enough to have G0, G1, G2, G3, G4, G32, G33, G76, G90, G91, G92. To execute these codes, your program already has everything. You have code for moving linearly and along a radius, these are G0, G1, G2, G3. It's very easy to implement G4, it's a pause. G32, G33, this is threading. G76 is thread cutting in a cycle with multiple passes. The remaining commands are commands for working with the coordinate system. All CAM post processors are set to Gcode supported by the machine. 1 set up CAM post processors and create Gcode for your machine for any, even very complex details. Your firmware is 1 step away from CNC.

[hobbymachinist]

There are a fair few issues to work out before I can be confident of using the motion controls for full GCode

1. linear xz movements aren't accurate, i.e. the final taper angles are incorrect.
2. the acceleration profiles are very naive, I'd like to get that fixed first.
3. fully automated threading loses DRO position at speeds over 400 rpm, not critical if you're not using closed loop backlash compensation but it's a deal breaker for me.
4. I'd like to have native tool radius compensation in the motion planner, but that's not a show stopper, most CAMs have this built-in
5. servo spindle control, possibly just PWM based to start with for constant sfm