Using a USB cabel provides you with different options compared to using the snapmaker with Wi-Fi connection…
-You can set a material thickness in Wi-Fi mode
-Using Wi-Fi provides you lasers with camera capture and USB don’t.
-You can use the touchscreen if you use USB and you can only disconnect if you are using Wi-Fi.
-The bedlevling would be nice to have in mill and laser module.
-You can’t controll the Enclosure if you are using USB.
This is a terrible answer and I’m not blaming you at all as you aren’t the one who made these decisions, just figuratively speaking the ‘messenger’ - but the statement of “this works as intended” and the ‘between the lines’ recommendation to just accept this and adjust oneself to it is not really helpful.
I lately noticed what the op is talking about myself and I don’t agree with what you are saying: “it is not possible for them to work the same” - of course it is possible but someone needs to implement it properly.
What is bugging me the most is the camera capture - this is a really essential part of doing any laser work. Where I put my machine, I have a really bad wifi connection and even in good wifi conditions (I tested this in my old apartment) the machine constantly disconnects. So now I prepared my setup so that I put a dedicated computer next to the machine(connected by LAN) and connected the snapmaker via serial connection using the usb cable - finally a stable connection and no more disconnects
but suddenly half my features are just gone - this is nuts.
If the serial connection connects right into the machines controller, wifi connects directly to the android device (touchscreen) and the android device is connected internally via serial to the machines controller, then the machines controller should evenly be capable of interacting with the android device, same as the android device is able to interact with the machines controller.
Because the USB connection bypasses the hardware that’s used to control some auxiliary functions. The only way they could get both setups to work the same way would be to strip the additional functions from the wifi-connected version of the software—they cannot add those functions to the USB-connected version, because the hardware setup won’t allow it. And people want the functions.
The hardware design decisions made suggest that Snapmaker wasn’t expecting most people to use the USB connection at all, and any functionality provided there is more of an afterthought/debugging aid.
Software is not magic. It’s limited by what the hardware it’s running on allows.
I agree that how Luban handles the difference is confusing. I completely understand the reasons why: Wifi communicates with the touchscreen, USB communicates with the controller. But how Luban presents the capabilities of each connection is confusing.
The USB connection should basically be a glorified console, and probably off in a dedicated tab or widget. It should be possible to connect via both Wifi and USB simultaneously (the argument that this might cause command confluicts is mooted by the CAN bus, as any use of the USB console will quickly demonstrate).
The addition of control options to the USB connection looks and feels like a hack: there wasn’t support for this functionality in the touchscreen, or there wasn’t enough memory to add that support, and so therefore let’ s add it to Luban USB mode!
I’m not sure there’s a good fix here, though. Aside from the different UI implementations of some operations depending on whether the connection is USB or Wifi (and that IS a bug, no doubt), the choice is basically “have the hack that exists currently in Luban” or “don’t have the functionality at all”. Now, I haven’t looked at the code, and I may falsely attributing motives to the developers, but it smacks of desperation. Luban has a lot of problems though, so what’s a few more eh?
The developers of luban don’t really watch this forum, If there’s changes you’d like to see perhaps consider creating an issue on their GitHub: Issues · Snapmaker/Luban · GitHub
Some or all of those features listed above are technically possible to implement, but require coordinated changes to the firmware and luban; which we’ve been complaining about since day one and I’m not even sure the developers have even acknowledged those requests.
If there’s enough people mentioning it maybe they will get around to it.
For example, the simple fact that issuing g-code commands over Wi-Fi does not give a response other than ‘ok’. That was an arbitrary decision made by some developer and there’s no reason for that to be the case.
Most software goes through a design stage, and the code is written to implement a (usually) coherent design.
Quite often, features are suggested after the design phase, and they either conflict with the original design, or are deemed sufficiently critical that no attempt is made to reconcile them with the original design. These are hacks, in the sense of “a hack job to make things work”.
The code extensions are not a hack, but Luban certainly feels hacked together. As if nobody thought it through all the way, or like it is being pressed into service for uses beyond its original intended purpose.
This sort of thing is common with decade-old software maintained by a skeleton crew, but Luban isn’t that old. Though it is an Electron app (anybody else notice the " sysctl kernel.unprivileged_userns_clone=1" requirement to get it to run?), and that does argue for the theory that it was never designed at all