Took a while to track this down… Occasionally the machine (Ruida RDC6442G) would move to the start position then hang. To cut a long story short, it turned out to be the case where there was a Z Offset value other than zero in any output layer.
My machine doesn’t have a (software) controllable Z Axis - but apparently LB needs to interrogate this value before it sets off.
The only rescue is to hit the machine’s reset button and run the job again (with the offending Z axis value set to zero). There seems to be no other way to flush the job from the machine’s queue.
I seem to remember a message from LB some time in the past saying it can’t get that value and should it continue or not. Now it doesn’t say that. Has this been inadvertently removed?
Any thoughts?
Cheers
Tony
as a subscript…
Various other settings in my library also had non-zero values. It kept tripping me up so (don’t try this at home!) I wound up editing the library XML to change them all back to zero’s. (after creating a backup copy of course)
It’s off by default. If you don’t have a controllable Z axis, you should turn it off and the system shouldn’t try to do anything with the Z.
For the next release, I’ve actually found commands that do true relative Z moves for the Ruida, so it won’t be necessary to query the machine for these anymore, but having that switch enabled would still mean the system would emit Z moves if you had Z offsets in the job.
Thanks Oz, yes, indeed that switch was on. I probably enabled it in the early days trying to figure out whether my machine actually had a controllable Z axis.
I just tried it, with that switch on it hangs with a non-zero Z axis value, when the switch is off it behaves itself perfectly.
Thanks
