Advanced Search

Hi,

Yes, the internal homing routine needs to be triggered one more time; after that, the axes will remain permanently referenced.
I am using internal homing method 4.
Once that is complete, you can comment out or delete everything related to homing.
My home and limit switches run via EtherCAT. This allows me to save a significant amount of cabling.
My XML file is nothing special.

It seems LinuxCNC runs great on the majority of PCs. I've had a lot of network and USB problems with several min-pc's I bought new, cheap, for around $100 USD. With desktop, gaming, or workstation type PCs you will find occasional models that refuse to cooperate but most work.

I've test run LinuxCNC on my GMKTek mini-pc with a Ryzen 7 5825U cpu, with good results, but I recall someone recently complaining about a similar model.

If you use 1-10 year old hardware I'd expect a good chance of success. But that number range is no strict rule in any way. I'm typing this on a ~11 year old pc that tested fine on LinuxCNC, currently running straight Debian 13. With a ~9 year old graphics card and 16GB RAM it is still very usable.

Even brand new less than 1 year old often works great, you just run a greater chance of not-yet-fully supported hardware.

A couple days ago I installed LinuxCNC on A Dell Precision T5820 for a customer, an 8 year old server grade workstation with massive overkill computing power. Everything works so far except the new 8-port non-branded network card bought separate from Amazon was junk.

forum.linuxcnc.org/18-computer/39371-res...or-use-with-linuxcnc

forum.linuxcnc.org/18-computer/54979-new-pc-build-asrock-n100dc

forum.linuxcnc.org/18-computer/57073-hp-...or-use-with-linuxcnc

forum.linuxcnc.org/18-computer/38838-har...ency-tests-used-pc-s

forum.linuxcnc.org/18-computer/54369-use...mesa-ethernet-boards
The thing with laptops is, despite getting the same exact model, still might not work. Happened to me only once, so it can happen.

Hey everyone! 

I'm pretty new to LinuxCNC and I'm trying to figure out what kind of computer or hardware setup works best for running it smoothly.

I've been reading some posts about latency issues and it got me kinda confused lol. Like, does it matter a lot what CPU or motherboard you use? And is a regular desktop PC always better than something like a mini PC or a single board computer (like Raspberry Pi)?

Here's kind of my situation:
- I don't have a huge budget, so I want something reliable but not super expensive
- I'll mostly be using a parallel port or maybe Ethernet-based motion controller
- Low latency is really important I think, but I don't fully understand how to test for it yet

I've been browsing some options online, maybe these can help others too:

www.amazon.com/s?k=mini+pc+intel+n100

www.ebay.com/sch/i.html?_nkw=dell+optiplex+linuxcnc

etechdevices.com/collections/pc-servers-software

If anyone can share what PC or hardware setup they're using and whether it runs well, that would be super awesome! Even just a quick "this works great" or "avoid this" would help a lot. 

Thanks so much in advance, you guys seem really helpful here!

It sounds like you either need to (1) make your stock a little bigger and *mill* it true after mounting, or (2) probe the part and update your origin in CAM. It would be cool if there were a kinematics layer that could do the G52 equivalent in a rotating frame.
If you're doing a production run, could you put in the equivalent of a vice stop on your chuck, so that every part is at least in the *same* place?

Thanks for the quick replyfind attached my ini file and the Gcode, you will see in the Gcode in the first few lines that I have added G07, with this in the Gcode everything works as expected (and how it worked in linuxcnc 2.8.4)
revoce the G07 from the Gcode and the 'bug' will be self evident when saving the modified Gcode file

I program (F360) using the center of rotation as Y0Z0.

Your example shows a self-centering vise, and I assume it'll be connected to the axis with a zero-point system.  If your adapter plate is adjustable you can indicate the adapter & zero-point chuck in very close.  From that point on the vise should self-center close enough.

For round parts (3-jaw chuck) treat it like a 'set-true' lathe chuck.  Chuck up the part and indicate it concentric with the axis of rotation (dial test indicator). Loosen the chuck on the backplate and tap it around.

Once it's turning concentric the Probe Basic 'Ridge & Valley' probing routine (in Y) will find Y-axis center.  Once you have Y-center, probe in Z and then adjust Z-offset based on stock diameter.

As far as probing the center of rotation for a prismatic part - assuming you've adjusted your vise & zero-point to be on center...

• Z-axis
  • clamp a piece of stock in the self-centering vise
  • Skim cut one side using Y-axis to establish a flat plane - doesn't need to be a huge area
  • Rotate 180
  • Skim cut opposite side at the same Z-position - preferably without changing Z-position between cuts
  • Measure part thickness (and checking for taper to ensure 180 degrees is actually 180!)
  • Probe part in Z, setting Z0 to top of part (probably automatic in probing routine)
  • Adjust Z-offset by half the measured thickness.  Z0 should now be center of rotation
• Y-axis
  • Probe your vise on one side (jaws horizontal)
  • Rotate vise 180
  • Probe same vise surface again, approach from the opposite Y-direction
  • Difference between these two is the Y-axis center.
  • From that point use a scale, calipers or a jig to center the stock in the vise along the jaws.
• Bonus
  • Write down the machine coordinates once you've found center of rotation in Y and Z
  • Next time you home the machine, repeat the above indicating and compare the numbers.  Any difference is the error window for your machine's homing position.
• Double-bonus
  • Avoid removing your 4th axis at all costs so you don't have to re-indicate
    

For repeat prismatic parts, you can machine or 3D print a fixture/jig to help center the part in the vise jaws.  This will get things close, and from there just program a little extra material in your stock.  You will air-cut a bit, but this will avoid taking a heavier cut than desired.

The above headache of indicating is why I switched to encoder index homing on my A-axis, and am in the process of doing the same thing on my XYZ axes.

Most important: You have to modify the postprocessor to enable tcp.
With 5 Axis you really want to use tcp.

Looking for some community advice:
I’m planning to add a 4th axis (rotary A-axis) to my milling machine. In principle, that’s not a problem. What I’m wondering is how to best handle situations where the stock isn’t clamped perfectly centered in the chuck/vise.I think it’s unrealistic to expect the workpiece to be mounted absolutely concentric every single time.I’m using the Probe Basic interface. I checked the probing functions to see if I could probe and compensate with G52, but that doesn’t seem to be possible.
How would you approach this? Would you probe the offset somehow, use a different work coordinate system, or handle it another way?I’d appreciate any tips or suggestions!

I have a rack-based toolchanger/toolsetter at the back of my CNC router.  My custom M6 gcode saves the X,Y location at the start, and moves back there at the end (at max Z, of course).  Often the next thing that happens is a rapid to a different X,Y.  I'm wondering if there's a safe way to not restore the position after the M6, or if there's some magic to restore it only if the next move is anything other than a G0XnYn move (i.e. G1 or G0Zn)?

Not sure, works for me:

mesaflash --device 7i96s --addr 10.10.10.10 --write 7i96s2p_7i74d.bin --reload

md5sum 7i96s2p_7i74d.bin
b77b9faf82730e3acf82c2cdcba6e022  7i96s2p_7i74d.bin

mesaflash --device 7i96s --addr 10.10.10.10 --readhmid > 7i96s2p_7i74d.txt

gives me:


 

Thanks for reporting.
Given that you could actually run the gcode after getting the 'Radius to end of arc differs from radius to start' message on load would point to a bug in the arc checking done on load which might be connected to a bug fix:

There was a bug that had made the preview use the RS274NGC_STARTUP_CODE in the ini file whenever a new gcode was loaded. This could lead to the preview not matching the currently set machine state. Eg if the gcode did not contain the WCS system (eg G54 or G55) and the controller was currently in, say, G56 but the ini startup_code contained G54 the preview would show the tool path with reference to G54 when the machine would actually run the program with reference to G56 (ie possibly somewhere entirely different).

Could you post your gcode file ?

Hello again,Somehow I'm struggling to flash the configuration:returns a success message, but runningafterwards shows absolutely no change.I've tried it with my newly generated bin file (), but also with various other configurations. I made sure to executeand also did several hard power cycles (power resets). I checked the board status using, and it looks like fallback is not active.Does anyone have an idea what could be blocking the update, or what I might be missing?

I attached my terminal outputs.Thanks in advance!

I have recently upgraded both my lathes from 2.8.4 and parallel ports to 2.9.8 and MESA cards
All is running well over the last 6 to 8 weeks and is all stable
However I loaded up a Gcode that I wrote some years ago today and linuxcnc was throwing an error related to the G02 / G03 lines stating that the arc would not meet up or words to that effect

Checking the G03 line all seemed correct, I work in Diameter mode G07 and metric units, the previous X and Z position where correct and a radius of 0.6mm was called for, the finished X was start X + Rx2 and the finished Z was start Z - R
As stated already this Gcode had been written some years ago and used many times without issue

I have amongst others G07 set in the INI files, and as such I do not normall include G07 in my Gcode files (I had always assumed that the INI files would set the machine to G07 and therefore setting G07 in every Gcode was not necessary, I do the same with metric units and never set G21 in my Gcode files as it is set in the INI file)

Running the Gcode all went well appart from the nag message about the ARC but other than that the Gcode ran and produced the correct component, Howerver the graphic on screen display was NOT correct, the white lines (tool path) where drawn at twice the distance from the centre line. When the Gcode was executed the red lines where drawn in the correct place which was NOT over the top of the white lines)
The digital readout on screen was all displayed in Dia mode having the black background and Radius mode the green background
When the Gcode was started the on screen display was moved to show the origin position, this could be moved to show the component being machined.

I found that adding G07 to the start of the Gcode fixed the display problem and the nag message about the ARC
My assumption is that the on screen display is generated from the Gcode file but is NOT utilising the G07 from the INI file
The machine interpeter is using the G07 from the INI files and set the machine to Dia mode and correctly machines the component.

As stated previous versions, at least 2.8.4, did not work like this, and if I'm honest this feels like a bug in 2.9.8
There is a work around to add the G07 to each and every Gcode file but in my eyes this should not be required as it is already set to G07 in the INI file

lower left hand bottom corner of Gmoccapy screen shows active G code and G7 is there even without the G07 in the Gcode
its very repeatable, remove the G07 from the Gcode and save the Gcode and the ARC error message is displayed, add the G07 to the Gcode and save the file and no ARC message
MY lathe is a slant bed, tooling on the back of the machines just in case that could be relavent

Whats your thoughts 

 

Nice!

I did get PIO working and made a pull request . I hadn't announced it yet because I want to stress the heck out of it, and I just ordered a PCB that will form a hardware test harness for it. It seems like it will work well, but I want to make sure that when six axes are chugging along full speed, the scheduling doesn't slip or lock up.

It theoretically should be capable of 200KHz stepping, but again, I haven't stressed it yet.

I bought the WIZNet RP2350 board as well. One of my pull requests should in fact work on it, but I haven't tried it.   I'll check out this code soon!

Hey @scotta , any chance we can get some of the other PRs merged?  They are starting to stack.  #12, #14, #15, and #17 should all be good to merge, and #11 could be closed if #15 is merged.  (The forum won't let me link the PRs.)