Advanced Search

This is for discussion about a potential feature which would automatically name/identify signals in HAL. Right now, a signal name always have to be given with the net command. But I see no technical reason why that is the case. New signal names could be generated automatically if none is given. And if trying to connect to a pin which already have a signal connected, that could simply be detected and linked to the already existing signal.

Right now I am using some code like:
I see very little additional value in the signal names geartrain_reverse_OR_stage1-3. It only clutters the "logic". And this clutter gets only worse the more complicated the logic is. Even the gearbox_search_slow provides little value. Instead, it could be like this:At least to my brain, the logic function is in this case easier to read. The net command could the automatically generate signal names where they are not provieded. For instance net_0001, net_0002, net_0003, net_0004 or similar. And if I want to use for instance geartrain.stage2.search_reverse for something else, the "net geartrain.stage2.search_reverse => hm2_7i95.0.7i84.0.0.output-03" command could automatically identify that the signal connected to the pin is named "net_0002" and just add to that same signal.

Similarly, if I want to for instance turn on a light when the spindle should be running, I could simply do "net spindle.0.on => hm2_7i95.0.7i84.0.0.output-01" instead of having to figure out where a signal was first connected to "spindle.0.on" and then use that signal name.

What are other peoples thoughts on this? I do think that giving meaningful names to signals is general good practice. But why force it in cases where "anonymous" signals would make more sense?

Hi,

I have spent a last few days to read a lot of forum posts related to this subject as well as general information on proximity switches. I still have my own questions, since this is completely new to me.

Please help me first with the following question. Page 14 of the Mesa 7I96S manual states:

[
For PNP type sensors or switches with a common positive, the input common pin is grounded and the sensor or switch applies a positive voltage to the input pin to activate the input.

For NPN type sensors or switches with a common ground, the input common is connected to +5 to +36V and the input pins are grounded to activate an input.
]



1. Is **the input common pin** in the two paragraphs above the pin marked in the diagram below?

2. And this pin can take 24V input?

I plan to use 24V NPN NO proximity switch. And I think I understand how to do the wiring.

I will have to seek further helps to check my wiring, too.

Thank you and best regards,

...behai.

John hi! After I transferred everything to *.qss. Everything worked! The only inconvenience is that the styles are not visible in QT Designer. Until you launch .ui via LCNC

Hello!
I'm new here and registered here because of this topic. Is it possible to get the firmware for an ESP32-S3? Or do I have to change something so that I can flash the ESP32-S3? I still have two of the S3 here and would like to test them as CNC controllers.

Thank you very much

Kai

Yes, and after some testing on yesterday it seems to work.
I just need to solve a noise problems that exist only when the spindle is running. The VFD is plugged to a different plug in a other room, which is not the same "line" if i can say so, as the CNC router is connected to. If its connected to the same line as the cnc router, then as soon as the spindle starts the axis moves like crazy.
Currently it seems that the axis are getting some noise when other things like vacuum cleaner is running or when turning off, and then the axis moves slightly.

I am not sure if grounding the machine with a ground rod would help, but this is not a linux/linuxcnc related problem.

So, thanks for help guys. The Latency problem is solved and anyone who has similar problems should consider to use a pc with integrated Graphics card.

Thank you. working

Thanks John! I'll try!

Hello,

I have made progress in defining the relative path.

For a RIP installation, the definition is as follows:
However, I don't know if I can use this absolute path for package installation:

Thanks Tommy, Don't actually know the technology, but all the limit switches on the machine are the same, and magnetic.

Signal goes to an optical isolator and the output from that to the 7i77.

Have only just now noticed that the Upper switch is labelled +OT.. A likely start of my confusion.!

Now that I've actually managed to run the machine and draw that famous Linuxcnc outline with it on a piece of paper, I fear it less and know better what the configurator questions are really aimed at, I'm going to create a new build from scratch and check this out all over.

Fabulous!

Yeah, I think if your 6.3 is working, I'll just wait and see.

Cheers!

Great!
Debian 13 (Trixie) is only a few months away from release (its in alpha release now) and it uses the 6.12 kernel
I did save my 6.3 build steps here.
docs.google.com/document/d/1-vj8OuACyzkk...aWE/edit?usp=sharing
You can modify them to do another kernel

Just keep the kernel version the same as the RT patch which is why we do a git clone.

tommylight wrote:

rodw wrote:

You should use estop-latch

Why?
-
Yes, there are instances when it is very useful, but not on simple/hobby/small machines, and especially not for beginners.

The video (not mine) explains why. My last couple of machines I used a safety relay so estop is external and I utilised an external reset button but I did test and consider using user_request_enable. You should not depend on a software estop if you have ired one in anyway.

QT dragon works well with my setup (as does Axis) I don't use estop_latch with it.

Yeah, well, I'm considering putting in the effort to compile that 6.6-rt that's over at kernel.org... but then... this might be working, and since pretty soon they'll be out with Debian 13 and then what is it, 6.12? So I dunno.

You were and are a hero to post that super-easy 6.3 install. Thanks again!

Aaaand!

You guys are totally awesome!

Installing the 6.3 rt kernel first fixed the network not working after updating to the R8168 driver.

And that driver changed my ping rtt stats obtained from:

from max > 3.0ms to max < 0.2 ms.

Wow.

Hopefully this will improve my error finishing read issues!

Thank you, thank you again!

My 6.3 kernel is quite old now but still ahead of Bookworm's 6.1 kernel
Sometimes I have lost my network with the R8168 and have been able to boot into a different kernel on the system to resolve it. Except I can't remember what I resolved! I think I needed to download something from the internet or run apt

I updated the typo