Thunderlaser: speed and power from LaserScript not used in output .rd file

[alastair-dm]

I'm using the Thunderlaser driver with output to file with visicut_1.8-24.1.20180519jw-beta-1_all.deb on Ubuntu 16.04. The LaserScript:-Test-pattern produces a file that cuts at the default power and speed, not the power and speed defined in the lasercript. I've decoded the output file with the tool from kkaempf/ruida and it shows the speed and the min and max power set only once at the start instead of being set differently for every square.

Blow_on ca 01 13
Speed_C9 100.0mm/s c9 02 00 00 06 0d 20
Laser_1_Min_Pow_C6_01 10% c6 01 0c 66
Laser_1_Max_Pow_C6_02 20% c6 02 19 4c
CA_03 0f ca 03 0f
CA 10 00 ca 10 00
Cut_Horiz 2.997mm aa 17 35
Cut_Vert 2.997mm ab 17 35

Repeating with the Generic GCode Driver I can see the power and speed changes for each square in the g-code.

Thanks for the work so far. It's looking much more usable than RDworks.

[alastair-dm]

I think there are two bugs happening here:

1. ThunderLaserProperty getProperty() and setProperty() don't handle the "speed" and "power" properties in the example script.
2. The LaserScript produces a single VectorPart with changes of speed and power settings, but ruida.startPart() treats a part as a layer with a single speed and power.

The first is an easy fix I think - explicitly handle propertyNames[1] and [3] then use superPropertyNames[i] in the subsequent iteration. Doing this results in the output file using the last speed and power from the laserscript instead of the default values.

For the second I think adding ruida.startPart(minX, minY, maxX, maxY); at the start of the SETPROPERTY case will do the job by creating a new layer for each property change. It appears to work for this case as I'm seeing the changes in speed and power in the output file. I may be able to test it on the cutter later today. There may be unintended consequences I've not considered for other sorts of job though.

[alastair-dm]

Unintended consequence - the Ruida controller really doesn't like the output file with the multiple layers. The interface doesn't respond normally while the file is selected (processing problems generating preview image?) and we resorted to uploading a known-good file to regain control then using 'delete all' to get rid of the offending file entirely.

[kkaempf]

Thanks for the report ! And sorry for a late reply, it's vacation season 😉

[kkaempf]

ThunderLaserProperty is subclassed from FloatPowerSpeedFocusProperty and its set/getProperty functions only handle the extra propertyNames, leaving the normal "speed" and "power" to its parent class. This should work fine.

[kkaempf]

Adding debug statements reveals that (at least) the speed property doesn't vary but is repeatedly set to 100.0. So this doesn't look like a driver bug on first sight.

[alastair-dm]

No worries, same season here. Thanks for looking at it. I'm having separate issues with netbeans that I'll have to fix before I can test further. In the meantime I'll try to explain better...

For ThunderLaserProperty I understood the subclassing, but I don't think the implementation of set / getProperty is handling the parent propertyNames correctly. After handlin a subset of the extra propertyNames it sets up to iterate over superPropertyNames but instead checks propertyNames in line 121 so the superPropertyNames are never actually handled. This diff should help explain: ThunderLaserProperty_20180823.txt

For the VectorPart handling I think it may be hard to deal with. I don't know enough about the ruida protocol to know if it's something it can't actually handle, or if it's just the way it's implemented here. I've just looked at the difference between how speed and power changes are handled in ThunderLaser and in GenericGcodeDriver as I understand gcode.

LaserScript produces a single VectorPart which can have multiple SETPROPERTY type commands in its CommandList. This works in GenericGcodeDriver because commands are just handled sequentially, and a changed speed or power will be applied in the next cut operation. See GenericGcodeDriver.writeVectorGCode and the following setSpeed, setPower and line functions.

It doesn't work in ThunderLaser.sendJob because each VectorPart is mapped to a Layer, which is defined as being all at the same speed and power. In ThunderLaser.sendJob the instance of a VectorPart starts being handled at line 439. This has a ruida.startPart call which creates a new Layer, then iterates through the VectorPart's CommandList, handling each command in turn. The SETPROPERTY type commands end up calling things like ruida.setSpeed depending on property, which are passed through to layer.setSpeed etc. which just write to the matching layer property, overwriting the previous value which is now lost. This is different to the LINETO and MOVETO type commands which go through ruida.lineTo and ruida.moveTo to layer.vectorTo, ending up in the layers array of vectors. The final output in ruida.write outputs each layer's properties, then each layer's vectors.

From what I've seen, the ruida protocol has separate commands to set speed and layer speed, but I don't know the rules on their use. Can a speed change be applied between the various line/move commands within a layer? Similarly I don't know if there's a limit on the number of layers - the Layer class doesn't seem to enforce one.