Advanced Search

After a bit more digging, I'm guessing the "# create a new component..." stuff is for creating a new component and not for just linking qtpyvcp hal widgets to hal.

Reviewing the terminal output during PB startup, it looks like 'exported hal' is working, or at least not throwing a warning:

 

Not sure what this warning is:

 

Attached the full terminal output during startup, halshow showing no pin being created, as well as a screenshot of the hal led indicator I'm trying to connect.

 

First of all, some users do not need LinuxCNC at all because they perform simple tasks for which GRBL/FluidNC is enough. LinuxCNC is just an unnecessary complication and additional cost for them. Secondly, the conversation about LinuxCNC should start with github.com/jzolee/HAL2UDP - the cheapest solution worth recommending (ESP32 + W5500 +OptoBOB or CNCshield), unfortunately with limited possibilities. Then there is riocore (recently active topic on the Forum). Later, Chinese cards compatible with 7i92 available on Aliexpress. And finally, the original MESA cards, unfortunately expensive and difficult to obtain in some countries, but widely praised. The most expensive and so far quite difficult to configure is Ethercat (I use it and I like it, but I don't recommend it to beginners).

Different GUIs are created to meet the specific needs of some users. There are no overall better or worse ones, they are better or worse for a given operator or a given machine. For example, I have vision problems, so Axis has too small a font, and QtDragon turns me off just by looking at it. But other people use it and praise it, but they don't even want to hear about Gmoccapy, which is a great choice for me...

Now that I've solved the issues with getting EtherCAT drives to work, I'm looking at GUI options, however I'm wondering if there's any kind of guide as to pros/cons of each GUI option?

First machine I'd like to try this on is a plasma table, but potentially also re-retrofitting a mill, and I'd like some kind of commonality between them, but I'm kind of stuck in not knowing what to go for.
I know there's QtPlasmaC and QtDragon, but also the MonoKrom option.

ok, i think i see the problem but have to check how i fix it, i never used function code 3 for bit's

Unless there is something fundamental that i am missing, you can not turn the saw while cutting, never ever, so "motion.interp.heading" can not be used, so why Rod?

That is up to the users to find a use for it. The motion.interp.heading will be the exact direction of your saw blade is pointing as commanded by the gcode interpreter updated in real time. It may not be useful with a saw. But in the case of a tangential knife, it could be coupled to the A axis rotary angle so the knife always remained tangential to the direction of travel on G1, G2,G3 moves. I thought the machine would use a component to monitor the heading and do things like stop to lift and reposition the knife when transitioning from G1 to G2/G3 if the change in direction exceeded a safe limit. In your case that would be 0 degrees.

Hi,I am currently configuring a Modbus RTU I/O expansion board with RioCore / RioFlow, and I ran into two issues:1. Unable to read digital inputs (N4D3E16 board)

• Board model: N4D3E16 (16 Digital Inputs / 16 Digital Outputs over RS485 Modbus RTU).
• Current status: Controlling all 16 digital outputs works without any issues. However, I am unable to read the status of the 16 digital inputs.
• I am following the register addressing and function codes described in the board's documentation (which I have attached). Could you check if there is an issue with how RioCore handles the Modbus function code (e.g., FC02 vs FC03 / register offset) for this mapping?
  
  2. RioFlow device renaming bug in LinuxCNC
  • When I assign a custom name to the devices in the RioFlow interface, LinuxCNC throws an error on startup and fails to load.
  • If I leave the device names blank (default), LinuxCNC starts and runs properly.

I have attached the JSON configuration file and the board's documentation for reference.Thanks in advance for looking into this!

Thank you Tommylight, Timo and Rodw for the replies and ideas.I live in Algeria, so buying a commercial stone CNC is very expensive for me. That's why I'm trying to build one myself.I've built several plasma CNCs before, but I always used PNCconf. I don't really know HAL/INI manually, so I'm starting with the 4-axis configuration generated by PNCconf.For now, my goal is actually simple: cut slabs accurately. For an inside corner, such as an L-shaped countertop, I'm happy for the saw to stop before it overcuts the corner. I can finish that part with another tool later.The machine will cut from the top/front side of the slab.For the A-axis, my idea is simply:raise Z → rotate A to the next cut direction → lower Z → cut → raise Z → repeat.I understand that A should not rotate while the blade is in the material, and I will use an interlock for that.Rodw, your mention of . Could you explain how I could implement it starting from a normal PNCconf-generated 4-axis HAL/INI configuration? 

For now, I want to make the machine as simple as possible and just get it operational. Once I have it working and cutting slabs reliably, I can improve it and make it more efficient step by step.Thanks again everyone. I'm trying to keep the first version simple and build from there.

I went back to this recently and looked into an alternative approach.  I simply don't have the knowledge (or courage!) to directly poke about with LinuxCNC, potentially breaking things as I go...  Anyway, this approach is browser based and uses a small Python bridging app, which (of course) ChatGPT wrote.  I'll attach the relevant files below.  To use them:

With LinuxCNC running, open a terminal in the directory containing the files and run python centre-finder.py, then open http://127.0.0.1:8080/centre-finder.html in Firefox.

The UI is pretty chonky, but I'll see about thinning it down in time.

Manually jog the tool to three points on the bore/cylinder, hit CAPTURE at each one, and it calculates the circle centre and sets the active WCS XY zero to that point. It doesn't move the machine — it's essentially a convenient operator interface sitting on top of LinuxCNC's Python interface. Currently working on 2.8.x/Python 2.7, with an eventual possibility of adding a horizontal electrical probe.

Once done and Firefox is closed, the Python server simply remains idle in the background waiting for another HTTP request; it does not generate motion or continuously interact with the LinuxCNC motion system, so it should have no meaningful effect on machine motion or step generation.

HOW IT WORKS:

The command the Python bridge sends to LinuxCNC is:

G10 L2 P0 X... Y...

Specifically, it constructs it as:

COMMAND.mdi("G10 L2 P0 X%.12f Y%.12f" % (new_wcs_x, new_wcs_y))

The important bit is P0:  P0 means the currently active coordinate system.  So if you're in G54, it writes G54. If you're in G55, it writes G55, etc.

COMPATIBILITY:

Developed and tested on LinuxCNC 2.8.x / Python 2.7. The browser interface is deliberately lightweight and the WCS write uses the standard LinuxCNC G10 L2 P0 command, so the underlying approach should be familiar across LinuxCNC versions. However, the Python bridge uses the LinuxCNC Python API and may need minor changes on significantly older/newer installations. Test in a SIM configuration before using it on a machine.

It is intended to set the active WCS XY offset; it does not move the machine.

Disclaimer: I've developed and tested this on a LinuxCNC 2.8.4 HAL SIM configuration and satisfied myself that the three-point calculation, active-WCS update and general workflow behave as intended. That said, this is very much a "use at your own risk" utility — please test it on your own configuration/SIM and verify the resulting coordinates before trusting it on a real machine. I accept no responsibility for damage to the machine, tooling or workpiece.

Would it be better to remove the copper hoses and replace them with clear polyurethane hoses (PA11)?Our main reason for considering this change is to have better visual control of the lubrication flow. With transparent hoses, we would be able to visually check whether the lubricant is flowing properly.Additionally, do you have any recommendations regarding the proper lubrication setup? How should the lubrication system be designed or configured to ensure that it is working correctly and reliably? Any recommendations regarding the type of hoses, routing, connections, or other components would also be appreciated.

I decided to replace the guides with new ones and everything had to be disassembled again.

 

Follow-up on a second box, same method as the first post.

Not another N100. This one is:

• CPU: Intel Celeron J6413 (4 cores)
• Distro: Debian 13 (Trixie)
• Kernel: 6.12.101+deb13-rt-amd64, PREEMPT_RT
• IgH: 1.6.9, native driver ec_igc
• NIC: Intel I226-V (8086:125c), dedicated EtherCAT port
• Slave idle in PREOP (application stopped)
• cmdline: isolcpus=managed_irq,domain,3 nohz_full=3 rcu_nocbs=3 irqaffinity=0-2 intel_idle.max_cstate=0 processor.max_cstate=0 idle=poll iommu=pt
• Governor: performance. RT thread pinned to isolated CPU3 with SCHED_FIFO 90.

Same MEASURE_TIMING path as before: clock_nanosleep(CLOCK_MONOTONIC, 1 kHz), then only receive / process / queue / send. No PDO mapping, no CiA402. 60 s / 60000 cycles.

Wakeup latency (µs)

min / p50 / p90 / p95 / p99 / p999 / max / avg

= 2.096 / 2.240 / 2.798 / 2.845 / 2.923 / 3.360 / 7.387 / 2.360

After the test the application was started again. The same I226-V port runs the servo at 1 kHz in OP with 0 lost frames.

This still does not compare I226/ec_igc with I210/igb — both boxes are I226-V. It only shows a second x86_64 + ec_igc sample on 6.12-rt. 60 s idle PREOP is not a production worst-case.

Master branch solves the A Axis alignment because I added some new motion.interp.* pins to it. One of them is motion.interp.heading which is the tangential heading or direction in real time. Look for motion interpreter Metadata Pins in this documentation link
linuxcnc.org/docs/devel/html/en/man/man9/motion.9.html 

I had envisaged there would be a companion component that dealt with knife alignment probably with external offsets with a setting that paused motion and lifted the knife if the next segment changed more than a certain angle (0 degrees in the case of the saw)

But I would look closely at FreeCAD CAM because one of their CAM developers Brad Collette (aka Siptronic) has done a bit of work with CAM for tangential cutters.There might be a ready made CAM solution.

It seems a bit odd. I am reasonably sure that you cannot tilt the blade during the cut.
How much do those blades wander when you engage asymmetrical?
I have no idea, but I would be skeptical if outside contours are doable.
I saw that one in the Interweb.stylecnc.com/stone-carving-machine/4+1-automatic-stone-cnc-bridge-saw.html
For the price I would probably just buy it if not a hobby project.
The rpm problematic on said machine is obviously solved by using two separate spindles. (one vertical) one 90° tilted that can rotate around a pivot.
For square cutouts it cannot be all to complicated to figure out how to manually program the thing.
.... I think I need a wood panel saw with router.....
How capable is a water jet machine? 
How about a diamond coated steel rope? Seems there are options for that as well. The plate is vertical and the machines run around like one of those hot wire foam cutters. 
 

This video of mine talks about 3 paths with Linuxcnc from simple/cheap through to more complex solutions.


Subsequent videos walk through a basic controller config for parallel port and spindle which is more or less exactly what you have, Next video will be using mb2hal for spindle control with RS485 Modbus which will free up 2 more pins to  let me add mist coolant.