Yeah, I did see something about some fixes
Anyone know why it says tft for sd?
I have not seen anywhere where they have developed a tft screen, have they?
1 Like
You know, it is sad that they did not ask you version info on discord!
Well Shoot, now i want it to do something, Anyone know if I can connect it to a4988’s direct?
Or maybe take the drv8825’s out of my ramps and connect them, think i need to do some research. (Although the research is hard for fluidnc if it is not a board!)
1 Like
this is a modified version of the regular esp3d esp3dui, they did not remove everything.
1 Like
I had been using 3.7.5 but when I went to tweak the code to add instrumentation, I used a stale version.
Now with 3.7.5 it is crashing right away with low memory errors and going unresponsive. Typing on fluidterm does nothing except for CTRL-R to reset. 
2 Likes
do you need to keep anything from your esp? if not use the erase batch file, then upload the new.
I already used the erase, I did not realize you had to configure station mode from Ap mode.
I used erase.bat then the installwifi.bat
2 Likes
A complete reflash would be erase, install wifi, install fs, in that terminal CTRL+U upload the config.yaml, then CTRL+R. Boot the system and log in.
2 Likes
What does Fs do?
I didn’t think they were being copied. The genuine ones are so cheap.
Ok based on how inconsistent it is and the symptoms, I am guessing it is maybe a dropped packet causing a logjam in the TCP stack that then sometimes blows the system.
Here is one instance: I’m running in station mode on an isolated wifi router (no internet) with only two members on the wifi: the ESP32 and my PC with wifi dongle.
I have fluidterm open and I also have a second serial port.
I run one job to completion, no issues.
I run the same job a second time, and part way through the motion “freezes” and I see this on the console (I don’t know which happened first):
[MSG:WARN: Low memory: 14868 bytes]
[MSG:WARN: Low memory: 13864 bytes]
[MSG:WARN: Low memory: 13744 bytes]
[MSG:WARN: Low memory: 13616 bytes]
[MSG:WARN: Low memory: 11164 bytes]
[MSG:WARN: Low memory: 11036 bytes]
[MSG:WARN: Low memory: 10908 bytes]
[MSG:WARN: Low memory: 4180 bytes]
[MSG:WARN: Low memory: 4060 bytes]
[MSG:WARN: Low memory: 3940 bytes]
Refresh of the web UI is unsuccessful and the ESP32 appears to be off the network because ping doesn’t return any responses.
Ctrl-R on fluidterm does reset the ESP32.
On some other occasions it was less catastrophic, where the motion would pause briefly and I would get some low memory errors, but it would recover.
CNCjs and no-radio FluidNC should be robust against extremely bad wifi, losing the UI in the worst case but never interfering with execution of a job. In the ideal case it wouldn’t be necessary because in theory the ESP32 can do it. It has an RTOS and it has two cores, so in principle it should be possible to isolate the web interface from the SD reader and motor control but of course this is easier said than done. They have one core dedicated to I2S output and the other core does everything else, so hiccups in wifi cause delays reading from SD, even apart from any low memory issue.
Does anyone know how to drop packets on purpose? I’d like to see if I can produce the behavior on command.
1 Like
Which FluidNC and ESP3D-WebUI repository branches are you guys experimenting with?
GitHub - bdring/FluidNC: The next generation of motion control firmware (main)
GitHub - MitchBradley/ESP3D-WEBUI at 3.0 (note the 3.0 branch)
Or something else?
Curious how reports are implemented. Whether code uses hanging GETs or websockets (rather than dumb polling) with server able to throttle report interval in streamed response bytes based on load (request queue length, high cpu, low mem, crap network, etc…).
1 Like
Wifi packet errors should get resent in the wifi layer of the protocol.
TCP is a stream and it won’t send a packet until the previous ones have been acked. IIRC, it only tries 3x before it fails and disconnects.
In either case. I don’t think the “user” has any idea that is happening. Or any control over it. But the esp ip stack is embedded and may be a bit unstandard.
At the user level, when the tcp stream is log jammed, any bytes added to the stream by the user need to go into a buffer. That buffer may be growing and causing the low memory.
3 Likes
I don’t know about wifi, but ethernet frames do not retry, so I was expecting the same. UDP datagrams can get lost and the TCP layer (not ethernet) has to keep track of acks and resend, in the case of lost ethernet frames. There is a certain time lag before it even knows that it has been lost, and during that time any sends need to be buffered, like you said (or I guess at some point they would block).
Also I would note that a high data rate (e.g. auto report 50 ms) will buffer and deplete memory quickly, whereas a lower data rate might recover without blowing up the system. Still just a guess but it’s consistent with the behavior.
2 Likes
That makes sense.
I have heard before that Ethernet uses “collision avoidance” and wifi uses “collision detection” when de-conflicting the wire (or RF channel). I don’t know if that really corresponds to a “dropped packet”, but my point was just that if the RF channel is busy, wifi has some mechanism built in to resend the info. I have no idea what the technical details are. I’ve never looked it up.
1 Like
Stick someone with a pacemaker in front of it, and startle them?
3 Likes
I have been able to crash FluidNC v3.7.5 several times by printing the test crown with the reporting interval set to 50ms. Then I modified the expressif sdk CONFIG_ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM setting from 32 to 8 buffers in sdksettings.h. With dynamic buffers set to 8 I haven’t been able to crash FluidNC after printing the test crown numerous times. What happens instead is that reporting will temporarily pause when all axis are in motion, then reporting resumes. The same low memory warnings appear regardless of the wifi buffer settings.
Here’s my configuration:
platformio.ini
[env]
platform = https://github.com/tasmota/platform-espressif32/releases/download/2023.07.00/platform-espressif32.zip
framework = arduino
dio_qspi/sdkconfig.h
#define CONFIG_ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM 8
#define CONFIG_ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM 8
3 Likes
I will try that!
Just a heads up: the docs page says the Jackpot comes with six (6) 2209’s, while the store listing says it comes with five (5) 2209’s. This could lead to confusion and frustration.
This whole thread has left me completely confused!! 
7 Likes
I saw that as the board can have 6 (as per pictures) and when bought from the store, it will come with 5, leaving the 6th socket unused. This is the same as the SKR Pro 1.2 board which has 6 sockets, but comes with 5 drivers now.
I suppose a clarifying sentence could help, but that will probably lead to more ordering confusion than sime selling the board with an adequate number of polulo drivers.
1 Like