Advanced Search

If using a THCAD for ohmic sensing has issues with water. the most likely issue
is that the sense  resistor is too high a value.

DerKlotz wrote:

Today i did a Sudo ... update and upgrade. During the upgrade i got these errors. Somewhere there the problem?
 

Try repeating after typing
    sudo apt purge raspi-firmware
If you still gets errors, share the output of uname -r as it appears it is trying to install an incorrect kernel version.

Hey Chris,
thanks for the report on github! It seems like it got some attention and the problem with the xhc-whb04b pendant is already figured out. Can you tell me what the supposed fix is to get the pendant working again? Or I just have to wait for a future LinuxCNC version?

I was able to block the installation on the ISO (which was done on our installer) but as soon as you do a sudo apt upgrade, the issue comes back. 
Ref: github.com/LinuxCNC/linuxcnc-live-build/...sts/desktop.list#L23
 

Looks great. I will be interested in how you go with the My Ohmic Pro. I was sent an evaluation one and its beautifully engineered. I just had nothing to try it out on. The THCAD for Ohmic struggles on Water tables so hopefully it proves a more robust solution. Lukaz at Proma said he was very proud of the water handling of the  My Ohmic Pro

Be sure to add an EMI filter on your mains input to avoid electrical noise. You can get them built into an IEC connector. even with a power switch and fuse built in.

I thought the THCAD can do the job of the Promo Ohmic sensing system?
Or perhaps one need an additional THCAD arc-voltage reader.
Plasma-guys, you know this.

Thank you so far. I continue tomorrow

Now I'm starting to wonder if I should run the the buffered encoder outs (that the Ultra3000 provides) into LinuxCNC via the extra Mesa cards I got and use BLDC to generate commutation pulses, send them out to the drives. The only issue is the startup sensing: how would BLDC command the Step/Dir drives to move in order to find the index pulse if the step/dir drives need the commutation signals to run in the first place?

 You are right, the bldc comp can only help where the commutation is under linuxcnc software control.
(It might have helped with the original encoders, as it can convert Fanuc 4-wire into simulate Hall sensor outputs. But you didn't want to hear that)

Yes, all those things will need manual HAL edits.
You don;'t have to put everything in the same file, the [HAL] section of the INI can pull in as many .hal files as you need. It may make sense to have the toolchanger in a separate file, for example.

You can also have several INI files in the same config folder, sharing HAL files, tool table, etc. This can be handy if, for example, you have a part-time rotary axis, or an alternative geaometry. (for example my mill has a horizontal spindle that I sometimes use, and that means swapping the Z and Y axes.)

I might be worth skim-reading the list of available HAL components to get a feel for what is available. You are likely to need the "carousel" component, for example.
linuxcnc.org/docs/stable/html/
Scroll down to (and expand if necessary):
Commands and userspace components
Realtime components and kernel modules

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)