Advanced Search

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.

Now that I've got the user tabs, ATB buttons, and user DRO showing up, the next snag is creating hal pins.

I added some hal LED indicators to my custom DRO panel, but they aren't being created when LCNC/PB is started.  At least they don't appear in halshow.

Dragged & dropped a HalLedIndicator in the panel
edited the object name
edited the pinBaseName

Just trying to get an on-screen indicator of an "is-homed" status.

I remember running in to this issue a few years ago - that time I was missing the lines in custom_config.yml:

I added the above under data_plugins: but still no joy.

Do I need to add this:
To the dros_user.py file somewhere?
 

That is a nice idea, till physics stick their nose into it and ruin everything!
The saw will spin at probably 1500-2500RPM (based on size maybe slower), and that is way to low for any end mill for hard stones, usually diamond coated.
Having said that, it will work, but it will be very, very slow.
Also, another advice that comes to mind, everything should be cut from the back side as the saw will eat into the part to make the cuts, so they remain on the back and not visible.
This will greatly depend on the material thickness, though, so that should be also taken into account.

Thank you for the response. I have an idea, but it is difficult for me to make it a reality.I thought that if the A-axis rotates very slowly, we could use it to cut the outside corners of almost any shape. My main problem, however, was cutting inside corners, for example, on an L-shaped countertop. For that reason, I wanted to use a bit to cut the inside corners and rounded parts.Let me try to explain my idea.The blade will be in the same plane as the Z-axis. The assembly will also have a bit mounted near the tip of the motor or spindle. The entire assembly will rotate so that the bit can become perpendicular to the slab, while the diamond disk becomes parallel to the slab.Both tools will be mounted on the same motor or spindle. The rotating assembly will not be considered another machining axis. Instead, I would treat it as a tool-changing mechanism:

• Tool 1: Diamond disk for straight cuts
• Tool 2: 45-degree diamond disk for bevels and angled cuts
• Tool 3: Milling bit for inside corners and rounded parts

Once I solve all of these mechanical and machining problems, my next goal is to make the machine very user-friendly.I will not be the person operating the machine every day. Workshop workers will use it, so the control system must be simple and intuitive. Ideally, the operator should be able to load a countertop design, select the material and tools, and start the job without needing advanced CAD/CAM knowledge.Thank you in advance for your help.

1 No.
2 No. but...
If i understand correctly, it is a bridge type CNC that turns the head where the circular saw is mounted, so that strictly implies no A axis moves while the head is down into material.
Basically, it can not cut curves or rounded corners.
It should be easier to just use a text editor and do gcode manually, or if you have repeatable dimensions, do a VCP panel with a choice of cuts preprogrammed.
Also strictly requires interlocks to prevent anything (auto, manual, MDI) to turn the head if the head is under a certain value where the material can be, those saws cost a lot, and forcibly stopping such big motors is never healthy as you have about 2-15 seconds before it permanently retires. With smoke.

I will try to be there, but no promises.

Fast = find an old PC with parallel port, a cable for it, download LinuxCNC ISO, burn, install, wire drives directly to that cable for parallel port = make chips
Cheap = see above
Easy = get a Mesa 7i96S and see above, minus the parallel port stuff
Good = se above this
Very good = see above this
Extremely good = get a Mesa 7i95T as you can later add encoder or glass scales to anything.
-
For now, download the ISO on the downloads page and use it to boot any PC or laptop in Live mode, test the included sim configurations and the included GUI's as much as you like, it will not delete anything on the hard drive ... unless you explicitly ask it to.

You should be able to debug the encoder issue by monitoring these pins::

hm2_7i97.0.encoder.0N.input-a
hm2_7i97.0.encoder.0N.input-b

in halshows 'Watch' tab

Where N is the number of the encoder you want to monitor (0..5)

These pins should toggle as you rotate the encoder

If the a or b hal pins do not change, you can trace back to the hardware
by measuring the voltage at the 7I97 encoder input pins, these should
toggle between near 0V and say +3V to +5V

So not i get no motion and an immediate following error. Before i would get a small amount of rotation but no counts in both configurations. Keep in mind this is a cheap amazon encoder that might just be a piece of junk. When I swapped this 4th from a resolver to an encoder i was able to see like 1440 0r so counts per encoder revolution but for some reason linux just doesnt like this guy. Not a problem, i can get one that y,all recommend.. i just dont know which one to get. It would be nice if I could get this one to work because I had to design/print a new riser/mount to fit the analigm dc servo... I can send you a link to the encoder that i bought if that might help....