Good input, thank you. The original JL1 power supply is only 12V 2.5A so this will probably be OK for now.
I saw that the Jackpot MOSFETs are low side switched, and guessed that the original FluidNC config used that very same GPIO in a similar config as an enable (in this case powering the laser).
I’ll consider modifying the config and moving the leads to a tee off of the board power.
Thanks again for all the help today to get this working.
Is a USB connection enough to avoid the issues when running FluidNC even if the Wifi is in STA mode? I wouldn’t think that it would be different from running the job off of the SD card?
If it is in STA mode:
Will a job started from the SD card keep running if the wifi connection is dropped?
Will the memory issues go away if the wifi connection is dropped?
I did the test with LightBun on the big ASUS Windows ROG laptop over USB.
Thinking about that, I still had the mid sized Acer Ubuntu machine connected to the GUI in AP mode.
LightBurn still ran the test fine. I haven’t tried connecting and doing anything in STA mode since my early tests. I might come back to that.
Come to think of it, I’m not sure the SD card I installed is working. I formatted a 16Gb with FAT32 and installed it. The errors on boot up of the Jackpot went away, but I didn’t see any indication an SD filesystem in the GUI just now as I went to upload the Gcode file to try and run it.
I’ll troubleshoot that tomorrow.
I’ll test running a job from the SD card and dropping the AP connection tomorrow (assumes I get the SD card issue fixed)
I haven’t seen a memory issue today after I quit using fluidterm while also uploading configs and restarting FluidNC from the web GUI. I’ll report if I run into any memory issues in my testing tomorrow.
We should only ever been using one connection at a time for a real job. Using the fluidterm and wifi is a debugging option but should absolutely not be used for actual work.
The issues in this thread I believe to be unique because it is all experimental. Pushing lots of buttons and testing things.
The next firmware revision looks to be coming soon and it has even more Wi-Fi fixes, and the patch for the GUI built in.
I think it speaks well of the Jackpot and FluidNC.
In the span of two days, I swapped a Jackpot in to replace the JL1 GRBL controller.
That’s with no previous knowledge of FluidNC, and working with a brand new, just-released board.
Absolutely, I do not mean in any a negative way. Just that I am not super concerned about the issues popping up here because a lot of learning is happening here for both of us.
I’ve been revisiting this after thinking about it for the past day.
In the short term, I’m going to make a pigtail that connects incoming 12V power and return to the laser module, and for now will get rid of using the enable in the FluidNC config.yaml.
That said, I don’t believe that hard wiring power and return to the incoming power supply is the best practice. The return on the laser module should always be tied to a return that is common with all the power returns on the board. The power supply to the laser module should not.
Using an enable to switch the high side power then provides a 2nd way to turn off the laser under program control even if the PWM line is blown. Without this, a PWM line or embedded software failure can result in the laser stuck on at full power. That’s not a good thing. With an enable, when the controller is executing gcode that doesn’t need to lase, it can inhibit the laser using the enable pin, which shuts off the laser even with a stuck/broken PWM input.
Related:
Using a low side switch as on the jackpot for the laser power is bad practice in another way, in my opinion.
When the low side switch FET is off, return is no longer connected to a downstream module, and that’s never a good practice when other IO on a module can be supplied voltage which is now unreferenced.
After thinking about that, and that the high side isn’t suitable for over 2.5A to the downstream load… It was dumb of me to hook it up that way even though it works on this machine.
Eventually what I’ll do is wire up a high side switched circuit and bring one of the standard IO pins out as an enable, which I will then map as the laser enable pin in the FluidNC config.
In another config change note, I realized this morning that the old controller (and matching LightBurn config) had the scale set to 1000, which is why the laser seemed yesterday to have so much more output power. In the config I used, the scale was 255=100%, so I was essentially running everything with 4x the intended power. With that changed, I’m now seeing results that are similar to what I saw before. I’ll update the post up above again to reflect this change.
This morning when I first powered up the JL1 after being off all night, the AP mode wasn’t working correctly and it was asking for a password other than the default. Nothing else was connected. I shut the JL1 back off and waited a minute, then powered back up. After that, it came up fine.
That feels to me like there’s still some kind of race condition going on where rarely the board will come up in a funky state.
All things considered, I’m really happy with this board. I’m liking FluidNC more and more as I learn about it, and the Jackpot board is a spectacular value for a control board with 5 populated TMC2209s and a ton of available IO.
I’ll be working on my enclosure some more today and building the modified harness to change the laser power supply around. I’ll start looking for an enable module that meets my needs. Maybe one of Bart’s existing modules would work for me…
Thank you, Ryan for the continued great support even as you’re making your way through a big product launch.
One last question- are there SVGs of the jackpot and/or v1e logos? I selfishly want to make a logo for the outside of the enclosure celebrating the setup…
I don’t think it is the jackpot, but there seems to be something funky still with fluidnc. I do see issues like this on my end. If I try to log in too soon after booting the jackpot, my laptop will need to have the browser window refreshed. Call phone works every time…my fire tablet almost never works (I am testing that more today).
I am holding off for the next fluidnc update as I know things have been adjusted.
Yes at the bottom of the home page you will see a like to the logo files.
The SD card I had installed had something not right, so I stuck it in the Ubuntu machine and used Gparted to completely wipe and then create a Fat32 partition. Now is working great in the Jackpot board. 16Gb SD card, for whatever that is worth.
Gcode file upload to the SD card is a dream over WiFi in AP mode, very fast.
Similarly, running the gcode file works great from the UI.
I tested multiple times disconnecting while a job was running, no issues at all with stuttering or corruption of the job.
I did many runs replacing my material test gcode as well as a couple of attempts at engraving a V1 logo. In one of those, as soon as I started the upload I got the dreaded memory errors and lost connection. I had to power cycle, then power cycle again after that because the first time up it did the thing where it won’t accept the WiFi password.
I did replace the harness pigtail for the laser module as I discussed up thread. This one pulls 12V power and return from the power inlet (put both cables into the crimp ferrules). It’s working fine and I’ll leave it until I find a suitable SSR or P channel MOSFET to use for switching the laser with the enable GPIO.
I just realized I didn’t install the heat sinks on the TMC2209s, so I’ll do that now.
Of the many times I connected and disconnected WiFI over the course of the day, there were three or maybe four times when I had to power cycle as I occasionally get that situation where the ESP32 won’t accept the WiFi password. Power cycles resolve that.
I’m going to start looking into adding buttons to the UI and also am very interested in the capability to run gcode in response to an input pin. Lots of really cool features in FluidNC that I’m starting to discover.
What I do notice is that when a connection is made, if there’s no disconnection then the system is very stable and the only hiccup I saw when staying connected was the time when a file upload caused the out of memory error. After that, when the system was back up I uploaded the same file 10 times without issue, so I’m not sure what that is.
All of my connections today were in AP mode, and I only connected with one of my laptops.
I haven’t yet tried connecting with a phone but will do that in the coming week.
After a good day driving the JL1, I brought the big ASUS ROG windows laptop to the garage to use LightBurn to turn on the laser at low power and do some focusing.
As it turns out, any time tonight I connect the USB to this machine with LIghtBurn running, LightBurn thinks it is connected and then nothing works. Further, FluidNC’s AP stops running. Really odd.
I disconnected LightBurn and connected Fluidterm and see this:
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
Somehow the ESP32 has rebooted and is in boot loader waiting for a download.
If I unplug the laptop and power cycle the Jackpot, then FluidNC comes back and is fine.
It’s 100% repeatable this evening- I’ve tried 5 times.
LightBurn worked great yesterday so I’m not sure what I might have messed up.
The FluidNC GUI is still working fine after rebooting and connecting over WiFi in AP mode.
I guess it’s time to go study up on how to add buttons or commands to be able to do laser focusing without needing LightBurn- and to think about how it is that LightBurn is kicking the ESP32 into a reset to the bootloader.
I did most of my initial testing with light burn I actually found it to be the most stable. It always connected…but I did crash my laptop several times. Wonder if the two are related?
I’m still not sure, but in looking at old posts on LightBurn forums, I may need to toggle the DTR option. I set this just now on the laptop, but won’t try this out on the Jackpot until tomorrow sometime.
Had a chance to test LightBurn with the DTR signal enabled.
It is now working fine with the Jackpot/FluidNC.
It is completely repeatable that with this setting off, FluidNC gets kicked over to bootloader when I connect up.
I have no idea what changed or how between Saturday and Sunday- but if anyone else sees this behavior with LightBurn this is the reason why. I suppose I could have hit that setting by accident as I did go into the device settings and slightly adjust width/height.
I created a pull request to add my config.yaml to the V1e github.
Edit: Maybe that should be rejected, and instead create a user_contributed directory or somesuch.
That’s probably where non-v1 machines should live, if anywhere on the v1e github.
I thought about that as well. For me, it would make sense to just configure FluidNC to use the correctly named file. For an average user, though, does it make more sense to just upload a config.yaml appropriate for the machine they are building? Not sure honestly…
Yeah I think that makes sense to add to the docs.
Also some notes about the enable pin, the MOSFET low side switches, and why any of that matters.
Further, notes about needing to be sure that the IO pins are all deconflicted- FluidNC will panic if you re-use an IO pin in 2 places.
Maybe also commenting out sections for many things like coolant by default and notes that users should only uncomment them if they are using those features and know why they need them.
My hope for all of this is to make it really easy for someone who buys a Jackpot to slap it on their machine, take a few really simple steps, and hook up per some kind of documentation. I’m willing to help edit docs too, just not sure what would help the most.
@MakerJim@vicious1 Thank you both for this work. I also have the JL1 Laser (sadly still in the box - I got it right before we moved and is in my office in the pile of “stuff still needing to sort through”). I have always wanted to support Ryan, and I think I will be looking into getting the new board and following your progress here to slap it in. I have been a little hesitant in setting up the JL1 as I would still need to do the GRBL changeover. I had all the links to follow that procedure, but that was months ago and not sure where I have them saved. This would be a lot simpler, and I get to support V1 as well.