No freaking way!
You know, I don’t actually understand any of this, so random things I would check…does the current set differently for each A B stepper? That is on the same command line as steps? It is always double, or is it just not being set and defaulting to something?
Oh, I spoke too soon. Even though the currents are showing what I expected, the UARTs are not working properly. Still a ways to go. It occurred to me that the multiplexing signals might be late due to the I2S DMA buffering, or it’s something else entirely (even X1 and Y1 don’t look right). And a brief dive into the I2S, everything looks about like I would expect I guess.
I’m not stuck yet.
I feel like you might have just turned your hat around and are about to get serious.
So this doesn’t help? The tinybee marlin config mentions tmc in it.
I have a tinybee that i am running Fluidnc on. It has esp32 so the fact that they already have marlin figured out, I thought it would help. (But I did move my 8825’s to it, I did not run the tmc’s.)
TL;DR: A bunch of technical details, blah blah boring stuff.
–
Ok.
The stepping is working. The UART scheme is where the Jackpot is different from the Tinybee and also from the FYSETC E4.
For completeness, UART is how it sets the microstepping and the current (and stealthChop and other junk but primarily microstepping and current) in contrast to the jumpers/potentiometer on the older stepper drivers.
The Tinybee doesn’t support the UART on the 2209. There is no connection so it won’t ever work unless you do some serious soldering.
The FYSETC E4 does have UART connection and assigns each stepper driver a different address 0 through 3 so they can all connect to the same wires. When the controller makes a request, it includes an address so only one of the controllers pays attention and responds. If two controllers had the same address and shared the wires then they would both take action (setting microsteps for example) and they would try to talk over each other in their responses.
There are only four possible addresses (limited by TMC2209) so it is ok for FYSETC E4 with four drivers, but to get five or more drivers you need another strategy. This is mentioned here. The solution wasn’t explained in detail (or my forum search couldn’t find it), but the idea is to have an analog switch to temporarily connect/disconnect multiple drivers that have the same address.
In the Jackpot implementation, the X driver has address 0, the Y driver has address 1, the Z driver has address 2, and A, B, and C all have address 3 but they essentially go through a 1-to-3 multiplexer that connects only one at a time of A, B, or C. (X, Y, and Z are always connected.) This is unique to the Jackpot board; no other board supported by Marlin has this.
My off-by-two error above I am pretty sure was just bad microstepping values as as a consequence of messed up UART communication (and my bug also made it incorrectly report OK when in fact it wasn’t). I think I have the I2S step generation solved, and I have X, Y, and Z UART solved, both of which are simply using the existing features that the FYSETC E4 and a couple other boards use.
The 1-to-3 multiplexer is (still) the difficulty.
The TMCStepper library is used by Marlin, and the TMCStepper library has a little bit of a UART multiplexing feature, but it doesn’t cover our use. One of the bigger problems is that it can only use “real” GPIOs, and it has no concept of the virtual pins that are the I2S outputs that Marlin defines.
Yet the TMCStepper code feels like the “right” place to add the multiplexing because it has a setup phase before it starts talking, perfect for configuring the multiplexer when it’s talking to the A, B, or C drivers. But it can’t use the I2S outputs. Adding the mux control at the point-of-use in Marlin would mean a much more complex modification spanning a ton of files, which is theoretically possible but extremely nasty.
My current thought is to add an optional callback function into the TMCSteppers so they can invoke a function during the setup phase before talking. Then the function is defined at the Marlin level and does the mux control and is able to use the virtual GPIOs.
That’s my next plan. Maybe it sounds complicated but it shouldn’t be that bad.
Jamie how did you get the M122 marlin style output in fluidterm for the jackpot?
Well, duh… X2 is twice as large as X1 
HTH
Same way some of my classmates did it in their CS labs: hardcoded the output…
Fluidterm is mostly just like a COM port interface like putty or teraterm, and it talks to Marlin just fine. The one advantage over say putty is I can use CTRL-R to toggle the DTR/CTS or whatever to hard reset the controller.
I haven’t given up on the serial mux, I’ve just gotten a bit distracted. I still think it’s possible without a huge effort.
Oh, so that was just Marlin…dang.
Okay, so I think I’ve got it working this time.
I set X2 to a low current and it had the expected effect: the X2 motor moves more easily by hand while all of the rest of the motors are normal. Then I set it back to normal and set Y2 to be low current, and Y2 became easier to turn by hand. I also configured (in configuration_adv.h) the “A” axis (6th stepper driver) to be 32-step microstepping and in the M122 report it shows 32 while all the others show 16. So the commands are being routed to the appropriate stepper drivers.
The basic idea of the update is what I outlined before. The TMCStepper library already has a “pre-read” and “pre-write” routine that is the perfect spot to insert switching of the serial MUX to route the serial signal to the proper stepper driver. But within the TMCStepper library it only knows about native Arduino pins and it has no concept of the I2S streaming through the HCT595 shift registers.
So I added a callback function, and the pre-read and pre-write functions invoke the callback function (if any). Then on the Marlin side I have a function that writes the pins (which map to the I2S streamed pins) to set up the mux.
The only bad part is that setting the I2S pins doesn’t take effect immediately. There is a queue for the DMA and it takes a moment for the pin values to propagate through the queue and appear on the output. By my calculations it’s 32 milliseconds to flush the FIFO so I have a delay of 40. A delay of 5ms was not enough and wires were getting crossed, setting values on the wrong stepper drivers.
I need to start a conversation with the maintainers of the TMCStepper library to see if they are amenable to adding the callback functionality, and then, perhaps in parallel see if the Marlin folks have any input/objections to adding a new board and the tweaks it requires.
But I think I can have an unofficial release put together before then and people can try it out.
Dude, that is nuts. You are trying to make it sound Easy…but I know it wasn’t because I barely understand any of that.
Holy crap, this is awesome!
I wonder… if we made an add-on for the expansion port that added thermistor and a couple of MOSFET IO, could we make the jackpot into a controller for the Repeat printer… ??? !!!
That is crazy. I love it.
It looks like the pins on the expansion header (GPIO12, GPIO13, GPIO14, and GPIO15) are analog capable, but only when wifi is not started. It would probably be straightforward to add an expansion board with ADCs where you would fetch the values over i2c, but I’m not sure what that would entail on the firmware side. I’m not seeing any obvious feature where someone has implemented i2c temperature readings.
But it’s just software.
That would be nuts honestly. I still can’t believe you are this close to getting marlin working on it at all. I never even considered it for even a second.
You know. I never know what to expect in here. This place is so unique!!! Congrats Jamie!
Ok, for anyone brave, I think this will work:
Download this:
https://github.com/vector76/Marlin/archive/refs/heads/jackpot_updates.zip
Build with VSCode and you should get a binary firmware.bin within the folder .pio\build\esp32\
I use a modified version of the FluidNC upload batch file to upload the firmware using esptool.exe that came with FluidNC:
@echo off
set EsptoolPath=esptool.exe
set BaseArgs=--chip esp32 --baud 921600
set SetupArgs=--before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect
set Firmware=0x10000 firmware.bin
echo %EsptoolPath% %BaseArgs% %SetupArgs% %Firmware%
%EsptoolPath% %BaseArgs% %SetupArgs% %Firmware%
Also you can use fluidterm to connect to the controller and the nice thing about that is you can use CTRL-R to reset the controller and view the startup messages.
And then you will need version 2.1 (not 2.1.1) of the ESP3D-WEBUI:
https://github.com/luc-github/ESP3D-WEBUI/releases/tag/v2.1
Unpack that and get index.html.gz and upload that to the controller.
Somehow the system remembers my SSID and password even though I triple-checked that it’s not defined in Marlin anywhere. I am confused how it got there, but it is evidently in flash somewhere not in the filesystem (index.html.gz) and not in the firmware (firmware.bin) and not on the SD card. There is a tab on the web UI to set the SSID and password or configure AP mode, but I wouldn’t know how to set that up if it weren’t already working.
I think I might try a few things to see if I can get a completely fresh start and see if I can figure out how to set the SSID and password from there.
Ok, if you have a totally blank system, the upload script (batch file) I gave above is not enough because it doesn’t set up a file system or (I think) boot loader. Maybe other things too, I’m not sure.
Install FluidNC. Then install Marlin over top of it. It’s a workaround for the parts that I don’t understand, but for now it’s good enough to get started.
After you’ve installed Marlin over top of FluidNC, you will find it starts in AP mode with SSID=“MARLIN_ESP” and default password is “12345678”.
From there you can upload index.html.gz, and after that you can configure your own station mode or AP mode with your own SSID and password.
That is different. So marlin still treats this as two systems? The firmware, and the wifi firmware. Sort of like the skr with an esp01. I actually like the sound of that better. I guess that makes sense marlin doesn’t have an interface really and this doesn’t have an LCD, so it has to get controlled somehow.
I need to poke around, I feel like this can open up the door to a few odd mods.