Thoughts on designing a new controller

I was under the distinct impression that the DRV8873 was going to give us an measurement of the motor current over SPI, but after reading the datasheet it seems like that is not the case. I think SPI is used only for reporting error conditions and setting the voltage thresholds. The IPROPI pin outputs a current which can be measured across a resistor to create a voltage proportional to the motor current.

Here is the relevant section of the datasheet:

That means that if we want SPI and current measurement from each motor we will need two GPIO per motor (chip select, and current measurement). We could also go without the SPI input entirely if we want, and use only one pin per motor.

In either case, I think your idea of using the LED driver to generate the PWM will help a lot by freeing up enough pins to make either one possible.

So the entire UI (html, js, css) is wrapped into a single compressed html file that is uploaded to the esp32’s flash memory from the IDE and that is what’s served when a connection is made. Only took me two days to figure that out… a bit different than what I’m used to. Templating is not an option at that point.

1 Like

On my todo list is to figure out some sort of templating solution using .h files, because one big file is not going to be maintainable

Is there any real limit to program space in the esp32? once you start including icons and such, things can get big. If you put everything into .h files, that becomes part of the program, correct?

There is a serious limit. We have about one megabyte to work with once the wifi stack is in there. All of the icons are going to need to be drawn with JavaScript instead of pictures to keep the size down

1 Like

I think this illustrates a basic problem common to some modern machine development. Too much dependency on complex software for simple functionality. The whole point of manual jog controls is to maintain basic functions and BYPASS anything complex that may have failed, is not yet set up, or has been misplaced. You don’t even need to supply the buttons. Just provide solder pads, holes, or headers where a user can connect his own.
4 gpio pins for
Lmot_Step, Lmot_Direction, Rmot_Step, Rmot_Direction INPUT
or
Lmot_In, Lmot_Out, Rmot_In, Rmot_Out INPUT
or
MoveLeft, MoveRight, MoveUp, MoveDown INPUT
or
Lmot_In_LED, Lmot_Out_LED, Rmot_In_LED, Rmot_Out_LED OUTPUT
2 more jumpers provide 4 bits to select between the above functions reusing the same pins.
2 gpio to read an encoder to select the number of encoder pulses per step.
E_Stop
HomeX, HomeY, HomeZ
BusyFlag to indicate that the last commanded move is still in process.
Serial, SPI, or I2C to read registers containing important variables and setup constants. This communications channel can duplicate all the above GPIO functions over 2 just wires.

Thats 13 GPIO and a communications channel. It provides everything for an operator to stand in front of the machine and operate it manually without any computer.
Edit: oops, forgot Z.
Zmot_Step, Zmot_Direction INPUT
Zmot_In, Zmot_Out INPUT
MoveIn, MoveOut INPUT
Zmot_In_LED, Zmot_Out_LED OUTPUT
Maybe reserve SledGPIO as well for vacuum on/off, pen up/down etc. So 16 GPIO total.

The exact same connection points also provide a basic interface that R Pi, ESP32, a network router, or really any computer can use to interface with the Maslow hardware with or without any version of ground control.
Another advantage of having duplicate control interfaces is that you can rapidly switch between them to compare the function of one against the other. This allows for rapid validation of code changes and ease of pinpointing differences between implementations.

Thats a lot more than just buttons, but I was on a roll and wanted to get it down before I forgot. Its been a while since I looked at existing Maslow firmware code or GRBL code, so lots of this might already be in there.

1 Like

I addressed some of this back in Firmware wishlist

1 Like

After I wrote what I did, I did some googling and it looks like you might be able to ā€œrepartitionā€ the flash memory… but regardless, probably should strive for efficiency.

1 Like

Re: limit switches. Or home contacts might be a better term are doable, even if we don’t exactly know how yet. At least we should reserve 3 gpio for the contacts and work it into the code eventually.
One handy fact about Maslow geometry, when the chains are equal length, paying out equal speeds on left and right motors produces downward vertical motion Edit: removed my incorrect generalization of this property at other places on the board.
Therefore a metal bottom edge contact is a safe starting limit.

I saw this today and thought it would be good to work into new firmware. http://www.themakersguide.com/home/products/triple-edge-finder-2

I’ve done this with my ESP32CAM ESP32-CAM Video Streaming and Face Recognition with Arduino IDE | Random Nerd Tutorials

I think it gives either 3 or 4 megabytes of program space at the cost of losing OTA programing ability. That would be a serious sacrifice of functionality.

Incidentally, ESP32CAM could work good for your photographic calibration grid routine. My experience working with these devices is here https://www.amazon.com/gp/product/B07Q56LGG6/ref=ppx_yo_dt_b_asin_title_o09_s02?ie=UTF8&psc=1#customerReviews Unstable, but it works and will probably work better by adding capacitance and simplifying the server code.

2 Likes

Actually adding a 2nd ESP32 solves another problem.
Repartitioning to gain codespace loses OTA function, but it can still be reprogrammed via its serial port. If the 2nd chip is not repartitioned, it can be OTA programmed, and the program we put on it can download the code for the main chip and update it via serial.

Its pretty easy to expand gpio for slow signals like chip select, just chain as many shift registers as you like. Offloading PWM is a great resource saver and I am all for it, but just like shift registers, it does increase our response time. Likely not enough to matter, but do we have any idea of the physical responsiveness of the system? Like how long from G code command issued to start of movement. How long from last PWM high to low transition until sled stops moving?
With a camera mounted on the sled and a grid behind as someone has done, these can be measured and used to benchmark iterations of controller.

1 Like

After some more thought and writing elsewhere, I fully support this approach. Make the Arduino GRBL processor be an ESP32 and take on the role of G code interpreter. I would like to cram a whole bunch more functionality in there too, but that might need to wait. I would like to start some work on this. Is there a specific version of ESP32 anyone would like to use so we can be using identical hardware for development?

egad… just compiled and uploaded it and it uses 1.7mb of program space. You have to partition it using ā€œMinimal SPIFFS (Large APPS and OTA)ā€ setting to get it to install. Is a esp32 with large flash an option?

except that when you want to move left, there is a complex set of calculations
that have to take place before you can do so. So you have a computer, even if
you don’t realize it.

13 GPIOs is also a very significant portion of the available GPIOs

David Lang

no, if you are on a far left top corner and let out the same amount from both
chains, you will run off the left edge and run the right chain off the sprocket
leaving the sled swinging before you hit the bottom edge.

you do not automatically move towards the center as you feed equal amounts in or
out.

David Lang

the real-time requirements are the big question. Right now, the cpu real-time
requirements center around not missing encoder pulse transitions. This is one
reason why it’s so interesting to consider encoders that track their own
position and can be queried.

the machine moves slowly, we already have cases where it misses an entire update
cycle (because the calculations for the prior cycle didn’t finish, and nobody
realized until we started measuring the time spent on one cycle.

when starting and stopping, the electronics react much faster than the physical
world can (this is why the ā€˜can’t keep up’ error has been useless in practice so
far, however good it was in theory)

David Lang

I don’t think there’s enough variation for us to need to standardize, espeically
this early.

Also https://github.com/bdring/Grbl_Esp32 already has a exp32 version of grbl,
with a webserver on board to control it.

David Lang

1 Like
    • Embedded flash:

Flash connected internally via IO16, IO17, SD_CMD, SD_CLK, SD_DATA_0 and SD_DATA_1 on ESP32-D2WD and ESP32-PICO-D4.

* 0 MiB (ESP32-D0WDQ6, ESP32-D0WD, and ESP32-S0WD chips)
* 2 MiB (ESP32-D2WD chip)
* 4 MiB (ESP32-PICO-D4 SiP module)
  • External flash & SRAM: ESP32 supports up to four 16 MiB external QSPI flashes and SRAMs with hardware encryption based on AES to protect developers’ programs and data. ESP32 can access the external QSPI flash and SRAM through high-speed caches.
    • Up to 16 MiB of external flash are memory-mapped onto the CPU code space, supporting 8-bit, 16-bit and 32-bit access. Code execution is supported.
    • Up to 8 MiB of external flash/SRAM memory are mapped onto the CPU data space, supporting 8-bit, 16-bit and 32-bit access. Data-read is supported on the flash and SRAM. Data-write is supported on the SRAM.

ESP32 chips with embedded flash do not support the address mapping between external flash and peripherals.

https://www.analoglamb.com/product/alb32-wrover-esp32-module-with-64mb-flash-and-32mb-psram/

https://www.analoglamb.com/product/esp-32s-alb/

1 Like

I’m finding there are lots of weird quirks from module to module, even in identically named modules from different sources. Many variations, revisions and Arduino IDE does not work with all of them. I’d like us to be able to help each other without ā€œmy module doesn’t have thatā€¦ā€ or ā€œit works on my X, I don’t know whats wrong with your Yā€. There is no point in people spending effort and money in different directions when it is so easy to get alligned early. So lets nail down some desirable features.
I think we want an S, Dual core version so we can run realtime on one core and network on the other.
We want the largest possible amount of internal flash and RAM. We want a large amount of external flash and pSRAM, but not so much that it is nonstandard and incompatible with Arduino tools.
We want a large number of gpio pins, but they should all be available. Some modules use GPIO pins to attach external flash, but still break out the unusable pins and include them in the count for marketing, which would cause us confusion. What module strikes the right balance between memory and gpio pins?
We want a board that already has an accurate boards.txt file for Arduino so we can use example code right out of the box.
We want something with worldwide, instock availability and fast shipping. An amazon product most likely.
And it should also be available at the cheap Chinese mass marketers like Banggood or AliExpress for those willing to wait for the boat to same a few bucks. Anyone care to select that module and provide a link?

@WarHawk8080 I would like to get started with that platform you posted. bdring/Grbl_Esp32 Can you provide more details about how to order it, BOM, schematic, ESP32 board known to work with it, motor controllers known to work, and where to buy them.

1 Like