Whoops, sorry.
4 Likes
Well, since weāre busy letting kittens out of the bagā¦ 
I built Jamieās example code and have it running on one of my ESP32s on a Jackpot.
I did a little research on what parts are available to make an add-on module that adds support for a few things that would be needed to turn Jackpot into a proper 3D printer controller under Marlin:
- A GPIO expander to run at least 6 more FETs (Bed heatrer, Extruder 0, Extruder 1, and at least 3 fans)
- A multi-channel A2D that would allow connecting at least 3 thermistors (Headed Bed, Extruder 0, Extruder 1).
For both of the above, preferably an IC that already has support within Marlin, making the āJackpot 3D printer add-onā more an exercise in laying out a module, testing, and adding Marlin firmware support.
This stalled first because Iām really busy at work right now, and also because interest on Marlin support didnāt seem super high.
I didnāt think about the thermistors. Shoot. We canāt just use the inputs for that, we would need them broken outā¦or use the expansion header. Either seems fine, broken out is less expensive.
Otherwise we have 4 outputs, SSR for heaters, direct for two fans (print and extruder). We just need thermistor inputs and probe input for a single headed printer. No need to set it up for 2 heads?
Itās not that simple. On ESP32, there are a bunch of analog inputs that canāt be used when WiFi is in use.
So, to do this correctly you have to use a multi-port analog (ADC) chip.
This isnāt that bad, we can just look at what other Marlin-supported boards use (E.g. MKS TinyBee)
Edit to add- since weāre expanding GPIO anyway, this also means there could be a header set that supports āMarlin Modeā or maybe even full support for the BTT TFTs that you already sell.
Again, MKS TinyBee is the example.
We really only need two. I would have to look at our 7 inputs and see if any are free on wifi and analog. Would that work if there were two open pins?
Interesting in the world of Marlin. (keeping Klipper in the back of my mind just in case that gets started)
It might work in a minimal use case (one heated bed, one extruder.). But I remember looking, and I think those GPIOs were already in use in a way that is a bummer for us (major change to jackpot).
But we shouldnāt shoot for the minimum. In a built-it-to-scratch-your-itch world, it is perfectly reasonable to want a 2nd extruder, or a chamber temp sensor, or maybe even backup thermistors (AC mains heated beds scare me from a thermal runaway perspective)
Itās also worth noting that the parts we are talking about arenāt that expensive. Note the retail price of TinyBee.
Yes. Klipper on ESP32 would be seriously awesome. But to get ESP32 as a supported Klipper target is a big step. Weād need to find someone with the skills and coding style to get an ESP32 support added to Klipper as a ready-to-go example pull request (Might be me being nuts, but reading the tea leaves).
Marlin is looking increasingly doable to me short-term because MKS TinyBee exists.
1 Like
I can pretty easily add headers before the diodes on the next batch.
It is more of a what the perfect CNC board is capable of without adding anything in terms of being a 3D printer board. It does not need to be an octopus, but in adding 3 header pins makes it a single extruder Printer board as well that seems ideal. Or more ideal than designing another board to add to this board. the combined price would be near or more than an octopus.
but I am not an EE so I could not design that myself.
1 Like
That right there is the beauty of open source. MKS publishes their schematics, and their Marlin modifications. We just need to go study them, learn, and apply that to your designs.
Then when those get published, others can do the same. (Most) everybody wins.
1 Like
I am not against it at all. I also think I should break out those pins since that is free on upcoming boards.
Hi Jamie,
Wile waiting for my Jackpot, I hit this post from you and find it very interesting. I downloaded your file and was able to compile the firmware. Thanks for sharing your learning and out of the box thinking.
Now with hindsight (an my bias) I think āthe marketā has not given traction to this idea and I guess the preferences have favored FluidNC. I found one related query (jackpot-support-for-dual-endstops-and-octoprint) but it seems that Jackpot can handle dual endstops so the conversation didnāt advance.
So I wondering if today you see some benefits of having Jackpot with Marlin instead of FluidNC?
Thanks in advance.
1 Like
Iām not Jamie, but Iāll throw some comments in response anyway.
Marlin on Jackpot would open up some interesting options, as would say Klipper on Jackpot.
There are practical limitations, however, that at the present time make this unworkable.
It would be a big step backwards at the present time to put Marlin on Jackpot.
One of the big obstacles is implementing the unique hardware-accelerated shift register based IO that FluidNC does on the Jackpot or Bart Dringās 6-pack boards. This implementation uses special capabilities of the ESP-32, and those are not presently supported in the other firmware.
If someone were really motivated, they could try and port that implementation to the other firmware.
Absent that, weāre in a place where if you want to run Marlin or Klipper on a board that the V1 community uses, pick an SKR Pro 1.2, which Ryan sells in the shop. Fully supported for 3D printer or CNC, and plenty of community knowledge on how to use it. People wanting to run Klipper for the CNC machines would choose this approach, for example.
If you want to run FluidNC, which is targeted at CNC and not a printer, then choose the Jackpot. The big benefits in favor of FluidNC in my opinion are the Web UI, the pendant support, spindle capabilities, and the active development of the FluidNC ecosystem.
3 Likes
Marlin on Jackpot does use the high speed I2S output similar to FluidNC. This screams bits out at an extremely high speed from an internal buffer, which gets translated from serial to parallel by the shift registers.
In Marlin itās here.
I didnāt implement this. It was implemented by whoever got the MKS TinyBee working, or someone previous to that. The MKS TinyBee is based on the ESP32, so porting to the Jackpot is basically just a matter of remapping pins.
The only hiccup in remapping the TinyBee pins to Jackpot is the way the Jackpot multiplexes the UARTs for the TMC2209. The TinyBee does not implement UARTs and uses ādumbā drivers like A4988, with jumpers to set the microsteps. The Jackpot does not support the āoldā style of stepper drivers and is specialized for TMC2209. If not for that difference, it would be just pins and nothing else would be necessary.
All the adjustments that I made were to implement the UART muxing, which is mandatory for the Jackpot.
I donāt know of any disadvantages to using Marlin on the Jackpot. There are additional features that Marlin offers that FluidNC aggressively rejects, and the dialect of gcode is a little different. If you are used to the Marlin flavor, then this could be an advantage. But overall itās whether the feature set of Marlin vs. FluidNC is better suited to what you want.
3 Likes
Fair enough MakerJim.
I bought the Jackpot and the printed parts for building a LR4 but it will take sometime before they arrive.
Meanwhile Iām trying to learn as much as I can so to get familiar with FluidNC ecosystem. To do that I ordered some ESP32 from AliExpress which arrive very fast and doing all kind of things like compiling FluidNC in different flavors and also some Marlin versions for Jackpot and other boards, like MKS TinyBee and Fysetc_E4 and I can say that Iām more or less comfortable with the process of running the SW part.
Your grounded assessments on the advantages of FluidNC are very compelling and make me think about retrofitting another equipment with FluidNC and an appropriate board capable of driving Nema23 stepping motors.
Thanks a lot for your feedback.
Thanks Jamie,
I did compile the Marlin FW for Jackpot with the Package you posted on November 2023. All I can say is that I got the firmware.bin and partitions.bin and also build a file system. But not having a Jackpot I have not been able to test it.
Iām not getting complains from the compilers so I guess everything should work as per your modifications.
I will take this opportunity to ask you if you have any idea how can I get a littlefs instead of the spiffs.bin file system Im getting by default. Can I use a littlefs generated by FluidNC, - with the appropriate files in the data folder - and default_8MB.csv file for the Marlin FW?
I donāt really understand how the filesystems work.
I know the SD card has a filesystem, and on the flash of the ESP32 there is also a filesystem (where index.html.gz and yaml files reside). Also there is a configuration area that is not part of either filesystem which contains e.g. ssid and password and which yaml file to load. Then there is a fourth area that contains the executable, which I assume is like boot ROM at a fixed address where the CPU knows to jump to it when it first wakes up.
I donāt know how to set up these areas. Iāve been using the FluidNC workflows to set it up and then overwriting it with Marlin and it has worked without me actually knowing how.
So thatās a long way of saying I donāt know.
Iāll take another look. Last time I looked I thought there was something still very different between the too implementations.
Agreed. There are three direct access and three muxed driver UARTs on Jackpot.
Itās an additional difference, but I donāt recall that being the only issue (as hinted at above).
For CNC, none really. Jackpot doesnāt support thermistors and doesnāt have adequate support for hot ends or heated beds without additional FETs and expansion connectors. Not an issue for CNC, but a big issue for the printer use case as mentioned above.
Thanks Jamie! Until I got my Jackpot last saturday I was like you about de file systems, but I did learn something I want to share.
When I started Jackpot for the first time, I noticed that I had the default FluidNC firmware and the file system had only about 200 K. When loaded all the V1E configuration files, they occupied most of that space.
Realizing that V1E ESP32 has 8 MB flash size, I decided to learn how to compile a FW adequate for double the size of the default flash. In the process I got a compilation for the 8 MB and also a FS with 10x the size of the default littlefs.bin. Although with the use of SD you will probably donāt need to use all that space, may be that the system will have better performance.
Any ideas?
I didnāt notice any performance increase when building for the full storage size, just that all of the space was then available.
This isnāt anything to do with Marlin- the topic of this forum thread, though.
There are some forum threads here about that, for example a bit about how to do it is here:
It would be good if you can add your notes and experiences about your compiling to those other treads.
1 Like
Thanks for redirecting the conversation MakeJim. You are right
Now regarding Marlin in Jackpot, I wonder if Marlin function like āauto trammingā is doable in FluidNC? Has someone done it?
I donāt know if Makers really use this function in the field or not. Is there I any need to have that capability for Jackpot driven MPCNC or Low Rider?
We can auto square X and Y and Level Z, yes.
Maybe we are not talking about the same thing?
1 Like