step pulse gap, rough stepper motor movements

[jimfong1]

I've been noticing some rough stepper movements when doing grayscale raster scanning. It is more noticeable at higher motor rpm speeds, 300mm/sec or more on my k40 laser. I got out the logic analyzer and Rigol scope to capture the stepper pulse train going to the driver. About every 15ms, I see a 0.3ms pulse gap. This repeats throughout the raster run. This short pulse gap makes the motor jitter and vibrate ever so slightly.

Standard straight moves such as G1X200F30000 are fine.

https://imgur.com/a/y7gI4Fo https://imgur.com/a/5Fsxd55 https://imgur.com/a/4asVEh1

https://filebin.net/92esd6nq74p2qsch Saleae Logic capture data. You can download the Saleae logic program free and open up the file to view.

Same grayscale raster image runs fine under grbl-lpc and stm32/grbl ports, smooth stepper motion.

I looked at the captured logic analyzer data and at every pulse gap, there are two very close step pulses next to each other as seen here https://imgur.com/a/Abi8AdP

[terjeio]

This could be due to the system architecture - program code is stored in external SPI flash and is read into internal RAM for execution when a page fault is generated. IIRC I calculated the time needed to load a page to around 300uS, and normal processing is suspended when this takes place as I understand it. Perhaps you could check activity on the CS and/or data lines of the flash chip during the gap to verify if this is so?

[bdring]

Thanks @jimfong1

I have seen some jitter in the past, but not like that. It was on a much smaller scale. I have not looked at it since I was comparing RMT vs. bit banging step generation, but I will give it another look.

Typically the IRAM_ATTR statement is used with interrupts, to preload the instructions.

I think the problem might be due to the RTOS and the way some of the API is written. Accessing some of the peripherals like the PWM via the API could be part of the problem. If you look at the API there are often a lot of RTOS related code. The RMT feature would be ideal for generating steps, but I have never been able to get it to work right within interrupts.

Perhaps it is time to look at directly accessing the peripherals.

[jimfong1]

I received a NodeMCU board yesterday, ESP-32S which has a CP2102 serial chip on board. This serial chip seems to be really slow for bulk USB transfers. My standard grayscale test takes over 120 seconds to complete. Compared to my ESPduino-32 with a CH340 serial chip which takes 38 seconds to complete.

This slower NodeMCU/CP2102 board sees very little pulse gap since it runs the raster really slowly. The gap is still there but it is about 0.1ms so it doesn't effect the jitter (relative to the next step pulse) all that much and the motor runs smoothly. So if you have a NodeMCU/CP2102 board, you may not even notice the problem at all.

I ordered a another different ESP32 board and will update this when I get it in to test.

[TwatBurglar]

@jimfong1 @bdring

Perhaps i2s is another option, instead of RMT?

i2s is done in hardware, so i2s data from the DMA buffer is shifted out with neither code nor interrupts - ie. it should always have absolutely perfect timing.

The only code required is to leisurely refill the unused half of the buffer before the used half starves. And an i2s buffer can be large, giving longer time before starvation (long enough to withstand @terjeio 's 300usec instruction fetch execution freeze, for example, or a wifi interrupt, or anything else a bigfatOS decides to scamper off to attend to).

So, I was all ready to try i2s with the 74HC595 serial-in-parallel-out trick.... but then found out esp32 already has this: an i2s parallel mode:
https://github.com/simon-jouet/ESP32Controller/issues/4

I can't see why @bdring 's board couldn't do parallel i2s as-is. Something to think about...