I’m not 100% sure if it will kick you off, but it definitely is not intended to be used that way.
The second port was opened under the understanding that those two would not be used simultaneously.
In the future, that 2nd port is going away.
I don’t know what the impact of 2 separate connections would have, but 2 separate WebUI connections has been known to cause problems in memory consumption and processing if it’s happening while a job is running
Which one is intended to go away?
From the FluidNC wiki:
FluidNC can accept commands over multiple interfaces simultaneously. For TCP/Telnet, it can also accept multiple simultaneous TCP connections from different clients.
It does sound like there shouldn’t be multiple websocket connections. If websockets become an issue, I’d probably try the Telnet route.
Port 82 was added because the WebUI developer didn’t intend them to work simultaneously. So commands were conflicting and when Mitch tried to get him to change the numbers, or add something to better separate the 2, it was denied.
So the 2nd port was the easiest way to support both at the moment, given the command incompatibilities, and the change in Websocket subprotocol…
At some point, that will likely go back to all being on port 81. I need to discuss it with Mitch again, but I expect if he’s agreeable it will happen over the next couple months
What I’m saying is a 2nd ESP-32 could serve as this proxy, probably then running WLEDs, Pendants, ,DROs, etc etc etc. So it may be more work that you want to do (it’s more than I want to do as well 
) but, this would be the way to cleanly get IO expansion out of the FluidNC/Jackpot without going to far nuts.
I guess I don’t care which port it is. The part I do care about is whether it handles that auto-disconnect. I think that part is a good feature, especially if we only want to allow for a single websocket connection.
Specifically, this handler code only exists for connections to the v3 websocket:
for (uint8_t i = 0; i < WEBSOCKETS_SERVER_CLIENT_MAX; i++)
if (i != num && server->clientIsConnected(i)) {
server->disconnect(i);
}
Correct. Because the V3 webUI can handle it correctly.
I’m not sure what the WebUI2 does, but it likely either will constantly try to reconnect, or just never reconnect without a full refresh
So I didn’t introduce it for WebUI2 connections.
As long as the WebUI-v3 subprotocol was in use, I expect it to remain. Whether or not it gets pushed into the arduino subprotocol is something that Mitch would have to decide. That would require WebUI-v2 changes
I have also done this. To replicate a telnet port specifically. We needed to log and connect at the same time. So our (much faster) logger connected as a man-in-the-middle and as a bonus the engineers could all connect at the same time. We ignored any weird conflicts because it was unlikely two people were actively working in the same few seconds.
I mean an esp32-c3 is comically small and cheap. If it could be programmed as a ‘accessories bridge’ that would be neat.
I ordered a cheap 1 meter strip with 60 LEDs to experiment. Based off discussions here, my current plan is to try doing this with an
ESP32 wirelessly via telnet. That hopefully allows for still having a pendant and using the WebUI.
https://www.amazon.com/dp/B088BRY2SH
I know I can cut them but this is the perfect length for my beam. It seems like all these individually addressable WS2812B strips are 5v. I can get the same length strip with up to 144 LEDs but that’s unnecessary and I don’t like the amp requirement. Then WS2811 are 12v but addressable in groups of 3. It would be nice to have 24v ones so it could use the power supply already in the beam. I’m not sure if voltage drop is an issue. Although, if I add a 5v supply to my beam maybe that can power both the ESP32 and the LEDs. Or I can just put a small power strip with USB inside the beam. I currently have a splitter in the beam so I can connect the Jackpot and router.
Nah, voltage drop is an issue for people doing the eaves of their house with these things, 1m will be fine.
Its sounds like you’re running the same lights I have on my LR3. For LR4, I built a new controller incorporating a fuse and a TI SN74AHCT125N. I had ordered a couple of extra M5 Stamps just in case I needed to replace the one in my Dial, and for other projects - they looked fun. Runs the S3 variant. (The red/green wires are because I was also building a Christmas light setup 
)
I built this to run off a small buck convertor that I’m currently using in the beam on my direct-wired ESP32 DevkitC Amazon special. I built the controller for the LR4 mainly as a learning exercise. I know most of it is overkill. (I’m also trying to improve my solder skills just in principle.)
But I can confirm that there isn’t enough voltage drop to affect the color of the LEDs (I haven’t measure it though.)
I just need a way for this thing to talk to the Jackpot ESP32 and FluidNC. Trying to avoid wires in my case because I want to add a spindle. (I might drop the pendant in lieu of a button that would simply resume from a hold (it’s mainly what I use the pendant for anyway.))
I have no clue what that is even doing. I can generally figure out software but electronics is where I know just enough to be dangerous.
They look fun. Right now I’m just going to use a regular devkit but that might be nice for a final product. I don’t need many pins at all.
This is where it’s either a websocket or TCP/telnet.
Yea, I can’t get used to the FluidDial. I can figure it out but it’s not intuitive. Hence why I’m creating my own thing, mainly for jogging with a joystick and resuming from holds (while seeing the last message for context). Although, even that’s mostly just for fun/learning.
Connecting to the Jackpot via Telnet is fun. I just did it on my computer with PuTTy (or there’s a Windows telnet not installed by default).
I’m happy to see you can do auto-reporting this way.
I think this will work just fine for my purposes.
Shouldn’t that read “telnet is bad… telnet is bad… telnet is bad”.
Yes, I think a socket management and/or UART mux is just what a Jackpot needs to be a fully expandable, fully customizable controller.
Well - I don’t really understand it well either. Frankly in my circuit, it may not do anything useful. But my understanding is that it creates a more consistent data signal. I wired it so it could also be used by a second data signal to run two strings (I was thinking it might be useful as a status indicator on the front of the strut, or a progress bar, or potentially both. But at this point I don’t have any of the coding skills to implement it, so I just ran with one string under the beam.
I turned off the garage lights to give you and idea of how much light that string produces. (Not sure why I’d ever use the machine in the dark. 
)
Ha, maybe. I have little experience with it at this point so I haven’t formed much of an opinion yet. I know that it’s old and basic and not something to use if you want a secure connection. It’s not something I would use in an enterprise environment. There is nothing secure in FluidNC whether that’s telnet, websocket, or HTTP, but that’s also not a concern for me. If one of my neighbors figured out how to “hack” my Lowrider, I think we would become friends. 
Well, I’ll certainly share anything I figure out and perhaps that can be translated to your setup.
I mean @Tokoloshe has a glow in the dark LR4 so I think you’re in good company. 
That looks like more than enough light. I’m likely to prevent it from running at full brightness but we’ll see what looks right.
So here’s the physics problem (bending light) I haven’t yet solved. The light produced under the beam is “behind” the bit so shadows are cast toward Y min (where I stand.) I’ve been toying with some ideas to get light out in front of the bit to try and knock out those shadows.
I’ll share anything I come up with.
Maybe something like this on the dust shoe? Amazon.com
Anytime I put effort into that I realize once I put on the dust skirt I can’t see it anyway.
