Advanced Search

I was thinking to my self much the same as I wrote, but I'd reached the point of losing the plot and grateful for the reassurance.
Thanks

Spindle-at-speed only pauses motion for the first feed move after a spindle command (as far as I recall) It definitely doesn;t interfere with rigid taping, for that would be a silly thing.

There are two packages not being found or downloaded. (qttools5-dev,
libpython3-dev)

We (well, mainly you need to work out why that is.

You could try updating the apt archive

sudo apt-get update

And then see if you can find them, for example:
sudo apt-cache search qttools

For too many months I tried in vain to fix the venerable vfd that was the original fitment in the machine and have at last inserted a Yaskawa unit . Tiny thing compared to the old one! But does actually run the motor at the speed commanded without drama and also reverses without needing to stop the spindle. Have also got the Linuxcnc spindle at speed bit to work from the encoder signal.
I think I've been round in circles on the synchronised motion implementation say for tapping.
I believe now that when pncconf writes the hal for a spindle with an encoder, then no additional entries are required to enable synchronised motion. The configuration output has spindle position, speed as well as index enabled pins, and I think that is all that is needed.
The wiki help, to me, implies some specific pin names are required, but after trying to get the suggested ones to work I find that in fact the default ones provided by pncconf work, or at least seem to.. At least I can get a sample G-code file with G33.1 to complete a cycle. Yet to cut metal with it, but nearly there.
I am also confused by the Spindle at speed notion. I can understand that it would be better if the spindle was running before the tool hits the workpiece, and notionally a good idea, but when the spindle reverses in the middle of a tapping cycle, I am guessing that the motion will continue to move as the tool delcels and accels, rather than wait to get up to speed? Must do, but was curious as to what happens under the hood so to speak.
Thanks

unknown wrote:

Issues: asks for root passwd, my fault will fix on another build, ISO still identifies as 2.9.4, need to update the config file.

That should be fixed by this:
github.com/LinuxCNC/linuxcnc-live-build/...aller/preseed.cfg#L1

The last row still creates an error -> custom_postgui.hal:6: Pin 'halui.machine.is-on' was already linked to signal 'machine-is-on'

A bit of HAL backgroumd. A HAL "net" command is the word "net" followed by a "signal name" and one or more HAL pins.
The signal name can be chosen fairly freely, and serves as the reference for interconneting HAL pins. There can be may HAL pins in the same net, but only one of them can be a "writer" (This might typically be called an "output" but that gets a but confusing as physical inputs are "output" HAL pins (they output a value) and physical outputs are "inputs" as they accept a value from output HAL pin)

Back to your error. It means that the HAL pin "halui.machine.is-on" is already connected to a HAL "net" somewhere else in the HAL files, and that it is connected to the net "machine-is-on". 
The fix for this is to just use "machine-is-on" as the net name for anything that you want to connect to "halui.machine.is-on"
I can't see your problem HAL line from inside this editor, but if, for example, the line causing the problem was:Then you would need to change it to:
(Note that the => <= and <=> don't mean anything to the computer and can be left out, but can help readabilty for humans)

It looks like you have most of it sorted out, but feel free to ask any questions if you get stuck.

Depending on what the mystery control board is, it might be compatible with Remora firmware.