Advanced Search

Not easy, but, GRBL and FluidNC are pretty much hobby only due to USB or WiFi comms mostly and the inherent latency and lack of "horse power" and lack of memory for complicated stuff, but they are pretty damn good for what they are and the fact they run even on a 8 bit micro controller.
LinuxCNC is a different beast altogether, the shear expandability and flexibility is definitely in the " life-changing epiphanies" level, and reliability combined with Mesa boards is way above most new industrial controls.
As a fresh example, today i went to visit a client of mine with 2 retrofitted industrial plasma cutters, he was just finishing the drawings and started the machine, literally as he pressed Run he turned and walked away from the machine and we went out for lunch. That is how comfortable he is with reliability of it all. He has over 10 years of experience with LinuxCNC machines, had one, now has two others, even his dad at over 70 years old uses those machines daily.

FWIW my work on the adaptive toolpaths got merged in FreeCAD- it's in the weekly builds. See: forum.freecad.org/viewtopic.php?t=96548

tl;dr is it adds a more-or-less one-click "rough the entire model" mode and- perhaps more relevantly- properly evaluates the stock and model instead of blindly projecting the contour you specify. Put differently, it's far smarter about not machining into the model, including avoiding areas it can't reach in 2.5D due to overhanging geometry. The attached image shows that on a demo model I threw together.

Not world-changing, but still a really nice QoL upgrade if you like adaptive toolpaths. Plenty of other... quirks... in FreeCAD remain, of course, but it's getting better all the time if you're not afraid of the weekly builds.

Is there a write-up in addition to the ngc files?

I have a shuttle pro by Contour that I have used with linuxcnc for years under version 2.7 using the old HIDCOMP component which is now outdated and not included in the new distro.    The shuttle always worked perfectly.

Now, I have upgraded to 2.9.4 using the iso installer.     WIth only the single line "loadusr shuttle" it throws a error as "dev/hidraw0 is not a known device."          Looking at the docs it does not recognize a valid usb ID for my contour shuttlepro.     LSUSB lists the ID as "011" and that is not provided for in the shuttle component but is indeed valid for a shuttlepro.   The component only covers ID's of 0020, 0240 and 0030.    

LSUSB displays Device 003   0b33 and ID 011 Contour shuttlepro

I did make the appropriate rule using the 011 ID but apparently the failure to recognize the id is withing the component coding.

Edit: I found the attached document that confrims that 011 is a valid usb id   (chart on pg2)

Hopefully someone will correct this in the shuttle.1 component.      

Thanks,
George
 

I'm interested in hearing opinions/thoughts from folks that have use both LinuxCNC, and one of the microcontroller firmware based systems, like Grbl, or FluidNC.  I have long (though perhaps not "deep") experience with LinuxCNC, and I've done some reading a couple of times about the "newcomer" systems, but I've never used one.

I assume that, given a g-code file, any of them will (basically) get the job done.   What I'm interested in hearing about is the things that surprised you, in switching from one to the other.  What was better?  harder?  easier?  worse?  What did you miss?  What made your milling life better?  I know, I know -- changing mill s/w probably doesn't involve life-changing epiphanies.  But I think you understand what I'm wondering about.

This question is triggered mostly by curiosity, and also because I've been window shopping for a new mill lately, and I'm wondering how much I should care about the controller and software that come with it.  It's likely that I'll replace whatever they provide, with my RPi and Mesa card,  but...  maybe not, or, maybe not right away.  I guess I'm wondering what the "dark side" is like.

paul

I can not test that as it requires EtherCat hardware.

Yes, I have a Voron v0.1 for small parts (120x120x120) and a Hevort for big parts (450x450x600 volume). Pretty sweet for sensor brackets and that kind of stuff.

I did a M6 remap that does that.  I originally did it as a .NGC remap but then did the remap in Python.  Either way the idea is the same.  See the attached document for my write-up and support files.  If you want the Python files that I modified, I can post them.



 

Is there a write-up anywhere on how to configure LinuxCNC to do a tool length probe when doing a manual tool change?  Having to split my g-code into two parts, for the sake of different tools, is (at least sometimes) a nuisance.

I confess I've been mill-shopping, and although I'm not looking at the shapeoko products, I did end up on a video demonstrating their "BitSetter" accessory, which seems very nice.  I'd love to have something like this.  

Hi Chris,

I am trying to add a grid to the 3d graphics before i start with adding a 3d model of the machine, same grid with the qtplasmac, i checked its code and added the lines(i think that its related with drawing a grid in the viewport) to the qtdragon_hd_handler.py(lines with the + signs next to line numbers in the attached screenshots) but i can not see a grid in the viewport. as u know i dont know the programming language i am just copying and pasting, i also added a doublescale box in qt designer, i can see the grid size as 50 in startup as i entered in the code but there is no grid still in 3d graphics.

have u tried adding a grid to 3d graphics before or do u know how to do it? Thanks in advance.

Hakan

 

IB_CnC wrote:

Printer is churning them out at the moment, should be able to test if it works over the weekend.

Printer? As in 3D printer?

Current status.
 

Going to try to get it going with some Optical sensors.
One of the pockets has a double flag to include the homing, all other pockets only 1 flag to detect the index position.

Printer is churning them out at the moment, should be able to test if it works over the weekend.

 

Just wait a second after the motor starts before reading RPM from encoder.

This would not work with rigid tapping (the OP's question)

Edited original post
But it happens in any subroutine, in simple nor complex.
It can be like this -

G91                                ; relative
G38.2 Z-164 F1000                ; quick find

---

HERE IT STOP

---

G1 Z3.0 F10000                    ; retreat by 3mm
G1 Z-2.0 F10000                    ; move toward 2mm
G38.2 Z-1 F5                    ; slow find
G1 Z1 F10000          

If I change G1 to G0, it never stops. But that not possible everywhere.