Conversational module for lathe

[staskaaa-netizen]

Hello. First - big thank for making this uCNC. I am in a way of adding simple conversational for lathe on top of it. Highly inspired by heidenhain/ gildermeister pilot things. And mazatrol too. On its own display, not as yet another grbl sender thing. So for now- display is on ra8876 chip and it is connected, keyboard is on i2c and it is connected. It does take some time to proper config pinouts if not using standart ones for spi / i2c. but now it is ok. All is implemented as separate modules. The only one trouble is taking current g code lines does make esp32 to panic. And yes, now it is on tinybee by mks. All fits, no extra wires, exp1 for display connector, exp2 for keyboard. th1/th2 for cs / hold buttons.

f->axes_valid = true;
    if (cnc_get_exec_state(EXEC_RUN))   // or whatever uCNC uses
    {
        f->runtime_line = itp_get_rt_line_number();
        f->line_valid = true;
    }
    else
    {
        f->runtime_line = 0;
        f->line_valid = false;
    }

This is progress so far.

https://www.youtube.com/watch?v=yRCTqcnAhGE&feature=youtu.be

G code is generated on the fly from conversational block, and is send to grbl stream. And i was able to add a sim for it.

At the end I will also have a g41/g42 added to core. But this is long term one.

Cheers.

[Paciente8159]

Looking awesome 👀

[staskaaa-netizen]

It would not happen if not you nice and clean code. Sometimes its beats me when i am not up to the innards, but after some head scratch - it is ok. Like spi setup - its checks to some some hard coded pins tied to cs line to decide which hardware spi to connect to spi1 and and spi2.
This peice of code in mcumap
`#if (SPI_CLK_BIT == 14 || SPI_CLK_BIT == 25)
#define SPI_INSTANCE HSPI
#else
#define SPI_INSTANCE VSPI
#endif
#endif

// SPI2
#if (defined(SPI2_CLK) && defined(SPI2_SDI) && defined(SPI2_SDO))
#define MCU_HAS_SPI2
#ifndef SPI2_PORT
#define SPI2_PORT 2
#endif
#ifndef SPI2_MODE
#define SPI2_MODE 0
#endif
#ifndef SPI2_FREQ
#define SPI2_FREQ 8000000UL
#endif
#if (SPI2_CLK_BIT == 14 || SPI2_CLK_BIT == 21)
#define SPI2_INSTANCE HSPI
#else
#define SPI2_INSTANCE VSPI
#endif
#endif
`
And still puzzled after i2c refused to work on 13 pin :) sounds like it still have its inversion enabled somewhere. I will try to reach you later to comment / review my spilt of core1/core0.

[Paciente8159]

SPI is meant to be used via the soft_spi module.
That module allows you to use either uCNC SPI, SPI2, bit-banged or if you want your own custom SPI (like Arduino SPI library or some architecture purpose)

[staskaaa-netizen]

And i am using.
`#include "../../cnc.h"
#include "../softspi.h"
#include "ra8876_ll.h"

#include <stdint.h>
#include <stdbool.h>
#include <string.h>

#define RA_CS_PIN SPI2_CS

// Start slow for transport debug first
HARDSPI(ra8876_spi, SPI2_FREQ, 0, mcu_spi2_port);
#define RA_PORT ((softspi_port_t *)&ra8876_spi)`

Problem is if pin combination of SPI_CLK_BIT SPI2_CLK_BIT lead to using same HSPI or VSPI for both SPI_INSTANCE and SPI2_INSTANCE

[staskaaa-netizen]

I am got a challenge to solve. I try to offload core1 as much possible, especially on sending blocking jobs like spi for display, but now after putting it all together conversational - i can't find a good solution to for working file. I tried to use two separate places - flash card (as is for core1) and internal flash chip (for core0). Many configs later - they do not want to work together. tied both via file_system, no luck. But i do have seen usage of internal flash on wifi setup. Which on its own sits on separated core / task.

Plan B - will be to move all conversational stuff (editing + g code generation) and i2c keyboard back to core1, and left core0 only for graphic display. On cam i need ability to list folder, open file, append to it. Edit.

Any ideas are welcomed.

[staskaaa-netizen]

This one helped (in cnc.c) g_file_io_critical - is set while i am doing file operation :

// #ifdef DISABLE_RTC_CODE
mcu_limits_changed_cb();

	if (!g_file_io_critical)
	{
		mcu_controls_changed_cb();
	}

// #endif

[Paciente8159]

Do you have your work in any public repo?

[staskaaa-netizen]

I will add it fully after initial build will make.
uCNC-master.zip

This is my current state, but it is not near completion, only one conversational module implemented, sim removed, but all pieces sorted out.

[Paciente8159]

I have not had the time to look at your code, but I will try to do it this afternoon.

[staskaaa-netizen]

Sort of milestone:

https://www.youtube.com/watch?v=unlrz15nxMg

https://youtu.be/Q7zOdEHRoRk?is=tB2vD2B3BRnflOZG

[staskaaa-netizen]

added bte to draw in hidden ram area, now image is sharp.

https://youtube.com/shorts/KIohR5udyGI

[staskaaa-netizen]

Added windows version to play with.

https://github.com/staskaaa-netizen/uCNC/pull/new/leancam-win-tool

[Paciente8159]

Amazing!!

[staskaaa-netizen]

Builded zip https://github.com/staskaaa-netizen/uCNC/blob/leancam-win-tool/tools/leancam_win/dist/LeanCamWin.zip

Was you able to run ? it was purely agent build thing from my conversational generator included. . A little more than ugly but works,

[staskaaa-netizen]

Added live run - so lcam code is translated to g code and streamed to core, and drawing is done using real x/z coordinates. Triple buffered.
https://www.youtube.com/watch?v=2_JV7I2gnh4

Tried to add chamfer/rnd feature to od turning, and i am puzzled with G7/G8 mode and this code
G2 X31.000 Z-25.000 I3.000 K0.000 - seems to work without 33 error only if i break g7 module :

Do not multiply after motion. Parser look ahead is wrong ? Or its got confused ? And of course without multiply my g0 goes to x18.5 instead of 37.

G code below:

G0 X37.000 Z1.000 (OD rough stock 10.000) G0 X26.000 Z1.000 G1 X25.000 F120.000 G1 X25.000 Z-22.000 G2 X31.000 Z-25.000 I3.000 K0.000 G0 X37.000 G0 Z1.000 (OD rough stock 5.000) G0 X21.000 Z1.000 G1 X20.000 F120.000 G1 X20.000 Z-22.000 G2 X26.000 Z-25.000 I3.000 K0.000 G0 X37.000 G0 Z1.000 (OD rough finish-stock 1.000) G0 X17.000 Z1.000 G1 X16.000 F120.000 G1 X16.000 Z-22.000 G2 X22.000 Z-25.000 I3.000 K0.000 G0 X37.000 G0 Z1.000 (OD finish DT 15.000 D2 15.000) G0 X16.000 Z1.000 G1 X15.000 F60.000 G1 X15.000 Z-22.000 G2 X21.000 Z-25.000 I3.000 K0.000 G0 X37.000 G0 Z1.000

[staskaaa-netizen]

Got it. So for g18 and diameter mode target b should divided by 2. No idea how to pass diameter mode to parser. now it looks only to live in g/_g8 module :

[Paciente8159]

@staskaaa-netizen G7 and G8 were implemented according to LinuxCNC description and might need some revision. I made it along time ago. I'm currently reviewing G33 with the help of @HuubBuis and also some parts of the main core, so be aware of that.

[staskaaa-netizen]

I'm currently reviewing G33 with the help of @HuubBuis and also some parts of the main core, so be aware of that.

G33 was the reason why i chose Ucnc over grblhal. No plans to use pcnt on esp32 ?

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/pcnt.html it was upgraded to have 32 bit (half software but still ..) counter in place of 16 bit before. +i2s shift registers make this all truly asynchronous machine / cheap man fpga.

Will need to make some sort of spindle emulator with encoder.

And i try to change/ touch core as little as possible, to stay in separated module.

[Paciente8159]

Thanks for the pcnt tip. I will look into it. µCNC uses a generic input ISR based implementation as a the base for the software encoder and general G33 control...but custom encoders are allowed.

The ESP32 suffers from ISR jitter induced by the FreeRTOS control...the pcnt may help on this task.

[staskaaa-netizen]

Thanks for the pcnt tip. I will look into it. µCNC uses a generic input ISR based implementation as a the base for the software encoder and general G33 control...but custom encoders are allowed.

The ESP32 suffers from ISR jitter induced by the FreeRTOS control...the pcnt may help on this task.

Is it ok to discuss here or you have special thread on it ? I am sort of interested in els solution where you transcribe spindle encoder pulses to drive z axis servo directly. So it is just directly driven by spindle.

[HuubBuis]

I am sort of interested in els solution where you transcribe spindle encoder pulses to drive z axis servo directly

My first thought about this was a digital PLL although it will not be so simple. Linux CNC probably has a provision for this so reinventing the wheel is not needed.

Will need to make some sort of spindle emulator with encoder.

10+ years ago I build a motor driving a 8 PPR encoder. For uCNC I used an ESP32-C3 to simulate index and sync pulses. I added a logic level converter board to connect 5V and 3V3 processors. If you need, I can upload the eagle files also.
ESP-32-C3-SpindleSimulator (2).zip

[staskaaa-netizen]

My first thought about this was a digital PLL although it will not be so simple. Linux CNC probably has a provision for this so reinventing the wheel is not needed.

You can always feed correctly divided signal per your required thread to two outputs and add some tri state buffer to choose output to work from. But it sort of working from other end. Or do it all in software. So you get this manual lathe behavior. Sort of.

My goal is advanced manual lathe with ability to run g code too. But first one is convenience to work as is. I was fan of linux cnc for a long time, till i tried other heidenhain method. On old tnc407. It is super convenient for 99% for shop floor tasks.

[staskaaa-netizen]

Did.

#define ENCODERS 1

#define ENC0_TYPE ENC_TYPE_PCNT

#define ENC0_PULSE_GPIO 36 // A
#define ENC0_DIR_GPIO 39 // B
#define ENC0_PCNT_UNIT PCNT_UNIT_0

#define ENC0_IS_INCREMENTAL

staskaaa-netizen@dd696a8

https://youtube.com/shorts/tGNik359ZSM?is=HzwlqB0k_1Y84spg

[staskaaa-netizen]

Will check it. Btw - if i do choose esp32 board in ucnc configurator and add some encoders - it does fail to export config. I think i need to add this enc0 as spindle rpm / position encoder ?

[Paciente8159]

for G33 you simply configure an encoder and then assign the encoder to G33 module. This should work out-of-box even with a custom encoder implementation. But I will test it and let you know. You also need to assign the encoder to the tool being used

[Paciente8159]

I found a couple of bugs in the encoder module that I will address but the basic idea of making a custom encoder as a module is this.

You can create a esp32_pcnt_encoder module for example and add this code:

#include "../../cnc.h"
#include "../encoder.h"
#include <stdint.h>
#include <stdbool.h>
#include <float.h>
#include <math.h>

#if defined(MCU_ESP32) || defined(MCU_ESP32S3) || defined(MCU_ESP32C3)
#include "driver/pcnt.h"

#if (UCNC_MODULE_VERSION < 11501 || UCNC_MODULE_VERSION > 99999)
#error "This module is not compatible with the current version of µCNC"
#endif

static void encoder_esp32_pcnt_init(uint8_t unit, int pulse_gpio, int dir_gpio)
{
	pcnt_config_t ch0 = {
		.pulse_gpio_num = pulse_gpio,
		.ctrl_gpio_num = dir_gpio,
		.lctrl_mode = PCNT_MODE_REVERSE,
		.hctrl_mode = PCNT_MODE_KEEP,
		.pos_mode = PCNT_COUNT_INC,
		.neg_mode = PCNT_COUNT_DEC,
		.counter_h_lim = 32767,
		.counter_l_lim = -32767,
		.unit = (pcnt_unit_t)unit,
		.channel = PCNT_CHANNEL_0,
	};

	pcnt_config_t ch1 = {
		.pulse_gpio_num = dir_gpio,
		.ctrl_gpio_num = pulse_gpio,
		.lctrl_mode = PCNT_MODE_KEEP,
		.hctrl_mode = PCNT_MODE_REVERSE,
		.pos_mode = PCNT_COUNT_INC,
		.neg_mode = PCNT_COUNT_DEC,
		.counter_h_lim = 32767,
		.counter_l_lim = -32767,
		.unit = (pcnt_unit_t)unit,
		.channel = PCNT_CHANNEL_1,
	};

	pcnt_unit_config(&ch0);
	pcnt_unit_config(&ch1);

#ifdef ENCODER_PCNT_FILTER
	pcnt_set_filter_value((pcnt_unit_t)unit, ENCODER_PCNT_FILTER);
	pcnt_filter_enable((pcnt_unit_t)unit);
#else
	pcnt_filter_disable((pcnt_unit_t)unit);
#endif

	pcnt_counter_pause((pcnt_unit_t)unit);
	pcnt_counter_clear((pcnt_unit_t)unit);
	pcnt_counter_resume((pcnt_unit_t)unit);
}

int32_t read_encoder_esp32_pcnt(uint8_t unit)
{
	int16_t value = 0;
	pcnt_get_counter_value((pcnt_unit_t)unit, &value);
	return (int32_t)value;
}

DECL_MODULE(esp32_pcnt_encoder){
    encoder_esp32_pcnt_init(ENC0, DIN0_BIT, DIN0_BIT);
}

#endif

Then in the cnc_hal_overrides.h you can for example define your encoder and load your encoder module and assign it:

#define ENC0_TYPE 255
extern int32_t read_encoder_esp32_pcnt(uint8_t unit);
#define ENC0_READ read_encoder_esp32_pcnt(ENC0)
// load the module
#define LOAD_MODULES_OVERRIDE() ({LOAD_MODULE(esp32_pcnt_encoder);})

Something along these lines. The module can be improved to allow proper pin assignment and configuration

[staskaaa-netizen]

Tahnk you, G33 will work via current encoder.c and this is only exposing read_encoder_esp32_pcnt to encoder.c ? + init of course.

[Paciente8159]

Correct. This only exposes the underlying api functions. This is a dummy/example template. This can be developed and make it more complete.

[HuubBuis]

My goal is advanced manual lathe with ability to run g code too. But first one is convenience to work as is. I was fan of linux cnc for a long time, till i tried other heidenhain method. On old tnc407. It is super convenient for 99% for shop floor tasks.

There are more implementations for "conversational lathe programming". Arie Kabaalstra has made a GUI for EdingCNC. I have made a program for grbl, grblGRU can do lathe work and there are a lot more.
In the past 10+ years I have only use my CNCL application for the lathe.
On the CNC router, I probably do 99.9% using a CAM module (FreeCAD, FlatCAM). EstleCAM is an easy to use program for simple 2.5D milling.

[staskaaa-netizen]

There are more implementations for "conversational lathe programming". Arie Kabaalstra has made a GUI for EdingCNC. I have made a program for grbl, grblGRU can do lathe work and there are a lot more.
In the past 10+ years I have only use my CNCL application for the lathe.

Nice. Will need to dig this E++ more. And - they all do run on something separated. No opposing on this (10.1 smart lcd with beffier esp on board is cheaper than ra8876 or lt7683 + lcd). My goal was to go a little more back then nc controller was nc controller and programming station. No touch screen (hate it in workshop) and mechanical buttons custom keyboard (not this ugly mebrane thing). Sort of like this one :

[HuubBuis]

(10.1 smart lcd with beffier esp on board is cheaper than ra8876 or lt7683 + lcd).

I think the cheapest commonly available hardware would be an android tablet.

No touch screen (hate it in workshop)

I love my 10" tablet on the lathe.

mechanical buttons custom keyboard (not this ugly mebrane thing).

The mechanical keyboard on my CNC router (12" touch laptop) has problems with the chips.

So many users, so many preferences.

[staskaaa-netizen]

I love my 10" tablet on the lathe.

mechanical buttons custom keyboard (not this ugly mebrane thing).

The mechanical keyboard on my CNC router (12" touch laptop) has problems with the chips.

I have problems with smartphone and dirty hands. Cant imagine how does it work on controller. So till now it is this small ugly cherry mx things which are easily replaced if needed.

[HuubBuis]

My tablet screen isn't clean but seems to have no problem with my dirty hands. Of course I only need to set a few parameters to get started and do this as a hobby so most of the time the lathe is switched off.
In a production environment a larger screen and decent keyboard would also be my first choice.

[staskaaa-netizen]

[staskaaa-netizen]

[staskaaa-netizen]

And if you want to change layout - it is 10 minutes job. Yes for a starter i should make it 8x8 with all hole cut.

[staskaaa-netizen]

I cant get isr firing on my encoder index pin. or it is wrong idea in ucnc world ?

[HuubBuis]

Ok will need to skip it and use just proper 3.3/5v ic which are on board

Which MKS-TinyBee pins do you want to use?

On J1 there are the RXD2/TXD2 pins + 5V and gnd. That could be used to connect index and pulse pins. Beware that these RXD2/TXD2 pins are 3V3 so a level converter is needed. These pins are also routed to EXP1 (LCD D7/D5) using a level shifter as output.

I use this level shifter on my boards. It may be usable in stead of a schmitt-trigger. I will hook it up to the outputs of my index/pulse signal (12V) after the optocouplers (3v3) and see if the signal improves.

[staskaaa-netizen]

Shame on me. Tried to use u10 - naive thinking if it was build for 3d probe it is multidirectional level shifter. no it is not. it hc125 chip..

Pins was 15 17 for ab and 2 for index. Will wire some resistors and call it i day.

[Paciente8159]

One more thing about the ESP32 that is worth a note and we are still trying to figure out how much influence it will have on G33 behavior. IMHO the ESP32 is not a good true realtime stuff candidate. There are lots of under the hood stuff that I do not have direct control that is handled by FreeRTOS. One example of this is the ESP32 Timer interrupt jitter issue and makes it less of an ideal solution for normal operation. The I2S (used in several CNC ESP32 firmwares including µCNC) and RMT solutions come with a tradeoff of a mandatory (usually in DMA) buffer to store precomputed step pulses, that add some milliseconds lag to the response of the driver.

Unfortunately we are bounded to the FreeRTOS and it's not an optional feature (like for example is the case of the RPi Pico or the ESP8266).

But we are trying to solve the input ISR issue before getting there. The ESP32 (family in general) as been by a long stretch the most problematic core of all that I've added support to µCNC. I know it's appealing due to it's price and it's good solution for IOT stuff..for this?..It has it's drawbacks.

[staskaaa-netizen]

The ESP32 (family in general) as been by a long stretch the most problematic core of all that I've added support to µCNC. I know it's appealing due to it's price and it's good solution for IOT stuff..for this?..It has it's drawbacks.

On price way it is as appealing as any other. If i remember my -20 years adventure on using atmega328 - because it was cheap, now it is always cheaper to buy faster one / more io etc. But yes, esp32 have so many features it is getting really hard. But - i am still on this one big monolithic cnc controller / cam combo. I need few years ago an scara controller - and skipped all project, except marlin. non was working nicely with scara. And marlin is two tier solution. Btw - how mature is scara on µCNC?

Btw - now i was able to use pcnt for idnex too. not the most elegant solution, but it is uses other pcnt unit as edge detector and it checks in main loop its state. not the best solution, but quite stable. and for only index - it is ok imho. So it is isr free.

[Paciente8159]

The scara as very little testing but should work. If you want to give it go, go ahead. Some feedback on that would be appreciated. Kinematics on µCNC are just another HAL aspect of µCNC. It's basically 3 things:

• a world position to step position and vice-versa conversion rules
• homing pattern rules
• and software limits checking rules

The core remains the same (it may activate underlying options like for example inform the motion controller if this is a linear motion control or a non linear motion control).

[HuubBuis]

I have checked the available pins on my ESP32 carrier board. I think I can add the level shifter module and do a real test on the lathe. I hope to get this done within 24 hours.
As soon as I get (delivered or find) a CD40106 I will test this using the same setup.

[staskaaa-netizen]

I think I can add the level shifter module and do a real test on the lathe.

I just used 10k resitors as level shifter. internal diodes will do the rest of capping voltage. Will push my current version of pcnt esp32 encoder. Semms like ok version on to run on table at lest. with overkill 1000ppr encoder. i do not have smaller with z.

[staskaaa-netizen]

Did : https://github.com/staskaaa-netizen/uCNC-modules/tree/pre-alpha/esp32_pcnt_encoder It is way more stable than isr + its got internal fitlering of pcnt. Minus - two channels of pcnt per encoder with index.

[staskaaa-netizen]

It was a good day : https://github.com/staskaaa-netizen/uCNC-modules/tree/pre-alpha/g33_ELS it does sort of work on table (led blinks, position does follow encoder rotation), spindle encoder is being followed by z axis. I made this one after seeing current g33 is sort of match3 one tooth spindle sync. This one uses proper electronic gearing between spindle and z.

[HuubBuis]

current g33 is sort of match3 one tooth spindle sync

No, it uses an index pulse to synchronize the start position and synchronization pulses to keep the z-axis position in sync with the spindle position.
Mach3, EdingCNC and probably others have proven to work when the spindle speed is stable and that is on heavy geared lathes.
On my variable speed hobby lathes, 4 to 8 synchronization pulses have proven to work reliable for 10+ years.
A g33 bases on a "high" resolution should/could work even better if the CPU can handle the load needed to process the synchronization.

[HuubBuis]

I think I can add the level shifter module and do a real test on the lathe.

I have added the level shifter to the ESP32 carrier board and now the RPM reading is stable and accurate. So a small step further on the way to go.

[staskaaa-netizen]

Mach3, EdingCNC and probably others have proven to work when the spindle speed is stable and that is on heavy geared lathes. On my variable speed hobby lathes, 4 to 8 synchronization pulses have proven to work reliable for 10+ years. A g33 bases on a "high" resolution should/could work even better if the CPU can handle the load needed to process the synchronization.

It is until it is not. On Mach3 it is random as per my friend experience, on linux cnc it is way better, I was able to run it even on par-port. and it sounds like this pcnt thing does really unload cpu. We are unly comparing pcnt counter to our necessary ratio and emtiting pulses then it should be emitted. On table its really just following encoder.

[HuubBuis]

sounds like this pcnt thing does really unload cpu

Ofcourse if you reduce the ISR calls and count in hardware. Nothing wrong with that.

On table its really just following encoder.

I haven't looked at your code yet but my worries are that the stepper has to speed up/down beyond it's capabilities. On a heavy geared lathe or a servo driven spindle you probably don't have to worry about that once synchronization is establised.

If the spindle speed of my lathe was stable during threading, I would prefer doing it this way.

There is also nothing wrong having different g33 modules depending on the situation.

Once you have your module up and running, I will test it on my lathe. I am curious about the results and maybe I am way to pessimistic about my lathe stepper capabilities.

[staskaaa-netizen]

I haven't looked at your code yet but my worries are that the stepper has to speed up/down beyond it's capabilities. On a heavy geared lathe or a servo driven spindle you probably don't have to worry about that once synchronization is establised.

It is in between. I am fully on servos - and yes, we can start it gentle and ramp it till needed speed - you do not start without z reserve of course. Second - China 100 euro servos are not as dumb as they look, and have pid inside them. So in stepper mode - you just give some steps and it will follow it ecentually. Even my big vmc have special lag viewing ability, and you can always see how much servos do lag from programmed distance. But - i think i will make second of two turns index search for servo up to speed and position.

[staskaaa-netizen]

Ofcourse if you reduce the ISR calls and count in hardware.

Other aspect - i was not able to get reliable isr firing with my resistor level adapter. Same as in example video.

[HuubBuis]

Other aspect - i was not able to get reliable isr firing with my resistor level adapter. Same as in example video.

We have spent a lot of time on this issue and the schmitt-trigger of level converter is the first option that worked on my lathe.

[staskaaa-netizen]

Other aspect - i was not able to get reliable isr firing with my resistor level adapter. Same as in example video.

We have spent a lot of time on this issue and the schmitt-trigger of level converter is the first option that worked on my lathe.

Yeah, and it is dark side / unknow of esp32. i do not have a clue of being so picky to signal level. But hey - pcnt here is silent king imho. i realy enjoyed how its performs.

[HuubBuis]

and it is dark side / unknow of esp32.

ESP is one of my favorite processors and until now I did not have this issue. It is solvable so now fixing the next issue.

[HuubBuis]

It is in between. I am fully on servos

Actually, I can switch between my low on torque at low RPM brushed DC motor (original) or a servo so I can test both situations.
Not every body is able, capable or wants to change his spindle motor.

I target the starting hobby user who wants to spend as less as possible on his first CNC conversion and doesn't have the means to change a lot on his lathe.
So if we have an option for both type of users, I am happy.

[staskaaa-netizen]

On translators - i think one can also use this shmidt trigger and translator ic SN74LV6T14.
And - if one goes wild with custom board, how many encoders inputs do we need, and is it worth / do other tried lserial output encoders live ?

[HuubBuis]

Solutions sounds usable and a real test on the lathe is the way to prove it. I think it is time for me to see how I can fit an encoder to the spindle. Not so easy because there is not a lot of space behind the gear cover.
To connect the encoder I need to make a new carrier board. It will probably based on an RP2040 or STM32 blackpill. Also a new board to connect the encoder with level converters is needed.
So it will take some time before I can do a first test.

[HuubBuis]

To connect the encoder I need to make a new carrier board. Also a new board to connect the encoder with level converters is needed.

If I use only one phase and index pulse, I can test using the same IO (pulse,Index) as current G33. That saves a lot of hardware to make. No direction information is no problem, threading is only in 1 direction and index pulse ensures thread is always started at the same position.

[staskaaa-netizen]

Last version should work. You will need to tune pcnt setup section and use correct ppr per you setup, but i see no reason why it should not work.

[staskaaa-netizen]

added 1x 2x mode for encoder: staskaaa-netizen@571820e2 both should be used as correct encoder ppr in grbl setting too.

[staskaaa-netizen]

and fixed some bug with signed output of 4x. now it does not need to have proper direction : staskaaa-netizen@541a9c0f

[staskaaa-netizen]

Added spindle tester / emulator. G33 with els part will need more work. now it is definitely pushing non uniform impulses : https://www.youtube.com/watch?v=Ytp9_oxqTzM

While current realization of g33 seems to work nice with pcnt encoder implementation : https://www.youtube.com/watch?v=kYqTKlAt59Y

Still - will try to find a way how to get this more dynamic response to current pcnt counter.

[staskaaa-netizen]

I may find a solution. i will reuse current g33 approach, but will feed it with virtual indexes generated same way as i do it now. 10 or 20 per single rpm. So it will be able to update feed more often. Trap - will need to make g33 start still wait for one or two physical ones. For correct phase.

[HuubBuis]

10 or 20 per single rpm.

Than I could make a new sync pulse disk and change the pulses from 4 to 20 and have the same results. That disk could than also be used for the current G33 module. Could also add some code to emulate the original 4 pulse disk just by skipping every xx pulse.
Than I wonder would a low (16..32) PPR encoder not be more convenient?

In the past I used an 8 pulse disk on my mini lathe. On my bigger lathe I changed to 4 because 8 didn't perform better.

[staskaaa-netizen]

Just pushed : staskaaa-netizen@b5c730fc Ended with even different version. Now our pcnt is final correct watcher, no conversion from pcnt to rpm now and back. Pure steps per pcnt logic. Enjoy :) And sim now jumps +- 5% of rpm in half revolution - this things hold position in 0.05mm range.

On single smaller disc - no if in short. Same as in my old heidenhain with old type of control logic. We have 500ppr encoder on servos with sine output, it is being interpolated 20x inside machine for position loop and up to 10x more on top of it for speed correction loop. And first one is slower and see final directions, second one is pure analogous one and watch DI things mostly. As far as i undrestand it.

In long this one explanation : We moved G33 synchronization from sparse physical index pulses to continuous PCNT encoder position tracking, using the encoder count as the main real-time spindle reference. Physical index pulses are now used only to establish absolute phase origin, while virtual indexes are generated mathematically between them for stable correction updates. This greatly improves threading smoothness because correction bandwidth is no longer limited by a low pulse count per revolution. A high-resolution encoder such as 1000 PPR provides precise instantaneous spindle position and RPM estimation, while a simple 10–20 slot disc only provides coarse timing snapshots and produces large correction jumps. The final system combines the stability of continuous PCNT tracking with the deterministic phase lock of a real physical index pulse.

[staskaaa-netizen]

And more comment - this one is different topic than conversational mode which is this topic main thing. As now - i have putted it to current g33 module. It is heavily named as pcnt counter / pcnt delta etc. So as is it is asking to go to separate G33_pcnt module. But - it seems like mostly of current 32 bits cpu do have in build quadrature decoding hardware counters. Atmega could realize only 1/2x and at 8 bits resolution. but still. I would propose the module name as G33_hw_cnt, or just leave it into current g33 one, and rename functions / variables on higher abstraction level.

`// enable this to use the encoder pulse as the feedback loop marker/trigger
// #define G33_FEEDBACK_LOOP_USE_ENC_PULSE

// third mode: keep index/virtual-index hook only as update trigger,
// but calculate phase error from raw PCNT encoder counts using a fixed
// steps-per-PCNT-count slope calculated once before G33 motion starts.
// #define G33_FEEDBACK_LOOP_USE_PCNT_COUNTER`

G33_FEEDBACK_LOOP_USE_PCNT_COUNTER - becomes G33_FEEDBACK_LOOP_USE_HW_COUNTER

[HuubBuis]

Correct me if I am wrong, but if I remember right, at the start you wanted to generate a step pulse every xx encoder pulses. Now you generate an synchronization pulse every xx encoder pulses and trigger the (modified) g33 module to do the synchronization.

I think I found a solution to temporarily mount an encoder to my lathe spindle. I attach an extension at the threaded end of my spindle so that it sticks out the gearbox. On that extension I can mount a timing belt connected to an encoder. The encode can be mounted to the gearbox cover using magnets.

[Paciente8159]

Agree on module things. question - should both need to be putted into one single module or keep to separated ones ? ie - standard approach for things specific to certain architecture.

You can keep each architecture implementation on it's own module. Users can mix and match according to their specific needs.

One more question on g71/ g72 - i think i will try to add them as separated modules too. How now µCNC handles linuxcnc canned cycles do work ? Do they generate underlying primitives or parser do parse them directly ?

The rule I mostly followed with µCNC is to implement all GCodes/MCodes that are in the RS274NGC standard (and can be implemented on µCNC) are integrated in the core code (following the rules as the standard specifies them). All other GCodes/MCodes (you can call it a superset) are to be implemented and added via modules.

Apart from the RS274NGC µCNC tries to follow along the lines of LinuxCNC mainly (or if not existent on LinuxCNC, some custom MCodes are implemented like Marlin or other firmware from were they were derived).

Canned cycles are broken into primitives and the code can be found here

[staskaaa-netizen]

the rule I mostly followed with µCNC is to implement all GCodes/MCodes that are in the RS274NGC standard (and can be implemented on µCNC) are integrated in the core code (following the rules as the standard specifies them). All other GCodes/MCodes (you can call it a superset) are to be implemented and added via modules.

Problem is - G70-G73 are different per controller and not in RS274NGC standard. And with my all love to Heideinhain - mostly have copied Fanuc with some extra flavour. Now it is this simplified one (buttons are presets for most common operations) with some some solution for monotonic curves. And later preview and running them. No link to named unit, just g80 to mark end of current one path. Heidenhain do allow all variants - inline with g80 to mark end of contour, or fanuc like two number - start and and end and labeled one.
For now i think i will leave it as is + add button to create labeled region from current/ select block of countour + add link to current g7x block .

[Paciente8159]

uCNC modules serve those purposes. Both generic (architecture broad) purposes as well as very application specific implementations. Modules have access to almost everything in the core, so there are many possibilities.

[Paciente8159]

By the way..thanks for the submits. I'm having a very busy work related period so it might take me some time to fully review the submitted code.

[staskaaa-netizen]

By the way..thanks for the submits. I'm having a very busy work related period so it might take me some time to fully review the submitted code.

It is totally hobby side for me too. rp2350 was tested before commiting, esp32 - may have some errors. But was totally ok before i started this lvds on rp2350 journey. Still have more than one option to thing of this g7x things. Re-read my manuals for eltropilot, heidenhains and fanuc examples. Hh put their own codes, each for each special case, where all others (haas / siemens) do fanuc like things. And of course mazatrol is different from others at all.

Technical lvds on µCNC question - i have non blocking memcpy of psram buffer to ram. Duration is ~ 7ms. It is stable as is, i do not have any troubles of it, i have only from sd card reading on soft spi. Which is obvious. Now spi sd card read gots its own busy flag. MAy move this to dma. Should i take care of splitting it some chunks ?

It is the last not very elegant solution which does work.

Btw - on lvds stuff is someone want - i have some spare Wincor Nixdorf BA72A-2 monitors with lcd panel (lq121s1lg44) which i am using. got 5 for 92 euros. You can't get wrong with this price. May need led conversion for backlight or reverse engineering of its own backlight driver.

[staskaaa-netizen]

Busy times. But still some time was found to play around. lvds is very nice too, it needed some more rework of code but now giving sort of 50 fps easily. And encoder stuff with multiple virtual hooks is migrated too. And it is rock solid.

The most important thing - i was able to make lvds renderer static machine - it sits on its own core1 in while (1), and doing scan line things from screen buffer without any interrupts at all.

https://github.com/staskaaa-netizen/uCNC/pull/new/rp2350_lvds