Well, that looks exactly like it’s supposed to. I guess at this point, leave FluidTerm running and try to reproduce any issues you are having. It will continue to output information.
1 Like
Have you erased the Jackpot and reinstalled Fluidnc? I had some wifi troubles a while ago and after erasing my Jackpot and reinstalling Fluidnc I haven’t had anymore trouble.
Do you suppose there’s some conflict with my computer or FluidNC settings that’s an issue with connecting?
If I’m initializing the machine after it has set for a while, it feels consistent that it takes three times to stay connected in the AP mode, and then it’s fine in AP mode for that session and only if I don’t shut off the machine via e-stop killswitch.
If I e-stop, it will not reconnect in AP mode unless I shut it down and walk away for some unspecified amount of time.
During none of that process am I trying or seeking to connect via my WiFi, as it has been made clear that those connections are ill-advised.
I do have the WiFi option and password entered into the settings and the ‘STA>AP’ option is selected.
Could that be causing a problem? Is there some flip-flopping going on in the background that is causing the issue?
The results of the .bat log were of a WiFi connection, not an AP connection. Would it help to see it run for an AP connection? Should I run it again after an e-stop?
Thoughts?
I did wipe it and re-flash and re-load, thank you for that suggestion.
1 Like
I don’t understand. How are you performing an e-stop? Technically, that means killing power but that term gets used for other ways of stopping a job.
Ultimately, I need to see the output of FluidTerm to have any idea.
If you have it set in STA>AP mode, it should connect in STA mode every time as long as your STA settings are configured correctly and it has a strong enough connection to your wifi.
When I say e-stop, I mean that I’m killing the power to the machine.
Am I correct in assuming that in STA>AP mode, the controller prioritizes making a STA connection over an AP one? If so, how often does it attempt to make the STA connection before settling on an AP one?
Regardless of what type of connection is being made, should I always see full bars on the FluidNC network signal? If the answer is ‘yes’, then what would cause there to be zero signal being transmitted from the board?
Thoughts?
The FluidNC network is only started in AP mode. If the AP network starts in STA>AP mode, that means it was not able to connect to your wifi.
It tries to connect in STA mode, if that fails it then goes on to AP mode. As far as I know, on power up it tries once, if it fails it then goes on to AP mode.
You’d need fluidterm or the output of $SS after boot to tell you what happened.
Yes, exactly.
It would be helpful to see what your AP reports for signal strength with the FluidNC connection. It may be a low signal strength that is part of the problem.
How far away from your AP is the Jackpot?
To reiterate this - the fluid term output you posted showed you had 3.9.4 installed.
Did you do a full erase, reinstall FluidNC 3.9.1 and copy the files Ryan linked so it’s using tested firmware and config files?
I missed that, previously.
I’ll go back and flash and upload accordingly and see what happens.
If the prevailing wisdom is to use the boards only in AP mode, is it correct to assume if I don’t ever point it to my router after I flash it that it will only connect in AP mode? And, then, if that’s the case, should I just switch the default connection type from STA>AP to AP?
My laptop has been between 5 and 8 feet from the machine, and the router is less than 25’ away, albeit on a floor above.
The FluidNC signal has either been none or full. From what I’m understanding, it sounds like all the time the FluidNC signal has been zero, it would have most likely been because it was connected or trying to connect via STA mode.
The WiFi chip and antenna on esp32 boards isn’t great (there are boards with external antennas which are better) so if the connection from the jackpot to your WiFi is marginal then yes you can absolutely change it to AP mode only and use it like that direct from your laptop.
1 Like
Bit of an update here:
I have been operating exclusively in AP mode since I re-flashed the board, and things feel much more predictable. Thank you to everyone for the help.
The connection still drops out regularly when I first get started, as in I connect, hit the ‘home’ button and before the machine finishes that operation, the board has disconnected and I have to re-connect in order to do anything. I’m guessing I should be running a FluidTerm session each time I want to start the machine if I want to try and get help, yes?
Also, the machine seems to have some sort of a gremlin in it that causes the machine to stop in the middle of running a program at a random point (nearly) every time I’ve been cutting something. It causes the machine to just pause for 5-7 seconds and then resume. It’s odd, and it doesn’t really bother me, except when the bit is engaged with the project and it’s just sitting there, heating up and burnishing itself against the material.
Anyone experienced this behavior, too? Is it something that would show up in the g-code and could be edited out, or is it in the processing of the code while running?
Thoughts?
Yes, that’s the best option.
This isn’t normal. Some folks have mentioned something like this- but it’s never been fully troubleshot as far as I know. FluidTerm logs from the time it hiccups would help.
Be sure you don’t have multiple browsers connected to the WebUI (e.g. if you had a “hotspot” window and also a separate browser window opened to http://fluidterm.local/ )
Beyond that, get us logs from the error when it happens and we can try to narrow down what is happening to you.
1 Like
Yeah that seems really odd and should not happen in 3.9.1. If you can catch it in a log that would be awesome.
I’ll make a point to start FluidTerm up front the next time I power it up.
Thank you!