t-oster / LibLaserCut

a platform independant library to control Lasercutters. This is the base library for VisiCut
http://visicut.org
Other
60 stars 55 forks source link

Add support for software focus for Ruida driver #214

Open TheAssassin opened 7 months ago

TheAssassin commented 7 months ago

Some Ruida devices such as the OMTech Polar provide software-configurable autofocus (in case of this specific device, there is a Z axis that moves the lens up and down above a static bed). In order to be able to actually use the device with VisiCut, we need to add support for this Z axis to the driver.

(Context: the device itself does not have a control panel so that the focus cannot be configured on the device itself. Lightburn provides a special "OMTech Polar mode" in which one can configure the material thickness so that the Z axis can be moved to the correct position (which is basically -17 + thickness, as -17 would set the focus on the honeycomb bed itself; this is a known value not subject to changes and the Z axis homes itself on every startup of the device.)

Edit: as far as I can see, the Ruida protocol supports four axes including Z. I therefore hope it's somewhat straightforward to add this feature.

TheAssassin commented 7 months ago

@tatarize thank you for your comments in https://github.com/t-oster/VisiCut/issues/706#issuecomment-1990930175 which helped me understand the protocol better. Unfortunately, I cannot move the Z axis (or, rather, any axis) with the suggested D9 commands.

I'm trying to send these from https://github.com/t-oster/LibLaserCut/blob/master/src/main/java/de/thomas_oster/liblasercut/drivers/Ruida.java#L659 (I refactored the code to use a type of property that provides a focus setting). I'm trying to send values ranging from -5 to +5. Do I have to enable some special mode beforehand (like it is done in the MOVETO branch)?

I'll continue to experiment tonight. As said, this is entirely trial-and-error based since I do not receive any feedback from the device. I need to run every job and observe the device's behavior.

Edit: I also tried 8008XX with no success. I'm not sure what the difference is to D902. Also, I tried all available "options" for D902, none of them made any difference.

TheAssassin commented 7 months ago

I found some working commands to drive the Z axis (at least I think so) and will continue to experiment with these. I can not yet configure the velocity which means that the Z axis moves with less than 10 rpm, making the process extraordinarily slow, but I'm confident I can speed this up.

TheAssassin commented 7 months ago

The command to move the Z axis to an absolute value on the OMTech Polar (6442s controller) is 800B, followed by the desired absolute Z position as an encoded float. Moving the axis seems to work reliably now. We should however make sure that the Z axis is moved to its 0 position (i.e., up to its home position to be out of the way for movements) wherever appropriate (it's probably sufficient to do this just at the job begin and end). When setting the velocity correctly beforehand, it moves fast enough so that it won't really waste any time.

To support software focus, we need to extend the FloatMinMaxPowerSpeedFrequencyProperty class used by the driver with a focus value. As a workaround for development, I just use the existing PowerSpeedFocusFrequencyProperty and use the configured power both for min/max (as most people seem to do anyway even if both values can be configured separately).

tatarize commented 7 months ago

Good to hear you got it working. There should be both a relative command and an absolute command, there usually are for ruida controllers. The problem is there's not really any realtime control stuff in the main program and even fewer hooks into the drivers. Even for things like GRBL which has a lot of potential useful commands like soft reset that could be essential in using the board well.