search

t-oster / VisiCut

A userfriendly tool to prepare, save and send Jobs to Lasercutters
https://visicut.org
Other
233 stars 114 forks source link

Provide additional user interface elements for Ruida controlled devices (and possibly others) #706

Open TheAssassin opened 8 months ago

TheAssassin commented 8 months ago

This is related to LibLaserCut (for the actual implementation), but since this is a general issue about additional buttons, I thought I'd open the issue here.

The OMTech Polar is a capable device, but its user interface is very limited: it basically just provides a big white play/pause button. Advanced features, like setting a (relative) origin, moving the focus axis etc., cannot be done without hooking up additional hardware (e.g., an (expensive) control panel that is used in many bigger Ruida devices, which doesn't really fit anywhere and requires cutting a cable path...).

In my opinion, VisiCut as the go-to laser "control" software could and should expose some software control elements. These devices must support those commands, obviously, as other software can perform those actions, too.

What do you think? Is this worth investing time and effort into? Of course, one could build a standalone tool, but it'd make more sense to integrate such functionality into VisiCut.

mgmax commented 8 months ago

See https://github.com/t-oster/LibLaserCut/issues/158 for some background discussion of how it could be done.

tatarize commented 7 months ago

Ruida unlike some others also has a set origin though it can't be done as a software command except through the 40207 port protocol (maybe). But, given the issues were raised circa 2020 I don't really have that high of hopes. In meerk40t, I've managed to get to the point of Ruida devices and can send most of the out-of-band commands. Though there's a lot of stuff in Ruida like updating a bunch of the saved settings etc, that also need more raw gui support. I think I have that for GRBL but that's much more mature and supported in the project.

TheAssassin commented 7 months ago

I don't think that setting a relative origin on the controller from the software is the only solution. One can, e.g., fetch the current position (Lightburn supports that), so relative coordinates could be calculated within the software.

Anyway. Given the device I'm trying to make VisiCut work with at the moment, there is an absolute necessity for the UI to send commands ad hoc rather than just send jobs when the user presses a button. For instance, if you do not have a control panel at all, there is no way to actually stop a job if one of the interlock switches triggers. All you can do is hit "reset" to reset the interlock system and continue the job or just reboot the machine...

I'm still working on roughly understanding the Ruida protocol and the features of the specific controller I have. Simple tasks as "move Z axis to specific coordinate" are quite tough, especially if you have no panel connected to the controller for error read-out... It's a bit of a shame that hacking on those controllers is rather hard due to stuff like that dreaded scrambling, the lack of proper protocol documentation and the fact that all the software that works with Ruida controllers is basically based entirely on reverse engineering. Lightburn, the only software that seems relatively feature complete on those controllers, is not interested in revealing their progress on this task, apparently.

Generally, VisiCut's user interface needs a bit of a revamp anyway in my opinion. I'm still brainstorming on that, I will probably open some issues on UI changes in the future. At any rate, features like editing, e.g., the controller's variables (something Ruida specific, as far as I can see) could always be added in separate dialogs.

TheAssassin commented 7 months ago

P.S.: Sending commands ad hoc would be great not only for stuff like moving the tool head from the software but also for debugging weird protocols such as Ruida's. One could just send commands and actually check what they'll do.

tatarize commented 7 months ago

I've mapped out everything the device does. Check the main file for it as well as the wiki that's set for it. https://github.com/meerk40t/meerk40t/blob/main/meerk40t/ruida/emulator.py https://github.com/meerk40t/meerk40t/blob/main/meerk40t/ruida/rdjob.py

See Wiki: https://edutechwiki.unige.ch/en/Ruida

I did a lot of reverse engineering for the protocol a while back. Move Z axis to specific coord is D902xxxxx units are absolute position given in μm.

TheAssassin commented 7 months ago

Thank you for your work. I was not aware of the emulator code. It really helps understand the protocol.

I don't seem to be able to use any of these D9* move commands. Maybe we can continue that discussion in https://github.com/t-oster/LibLaserCut/issues/214. I'd appreciate your help.