Advanced Search

I made a new PWM board to +/-10V.
Now with isolated power supply and the possibility of differential analog output. Now the groundings don't mix
 





ps:I saw one mistake, I forgot to bring out the ground for +-10v
ps: 

Yes. that's correct but looking at the parport driver,
you may be able to do this by inverting the desired
output pin by using the out-invert parameter.

linuxcnc.org/docs/html/hal/parallel-port.html

[This would have the advantage that it would likely  work in reset mode
(which doubles the possible step rate at a given base thread rate)

Would this change in the hal for parallel port pin 2/3 be correct?

loadrt not count=1
addf not.0 base-thread

net xstep stepgen.0.step => parport.0.pin-02-out
net xstep => not.0.in
net xstep-neg not.0.out => parport.0.pin-03-out

I am currently seeing a very serious problem with keyboard jogging on a fresh install of the current version of Linuxcnc 2.9, installed using the current ISO.  Occasionally when jogging using the keyboard it appears as if the jog key you press sticks and the machine will continue to jog long after you release the key.  Sometimes it won't stop jogging until you press a different keyboard key (what key doesn't matter.)  I have only observed this behavior when using keyboard jogging.  Jogging using the mouse to click on screen jog buttons behaves normally.  This is a very serious and unsafe problem.  I just updated the control on this machine from Linuxcnc 2.7 to the current version, and I had never observed this kind of behavior before.  I've already totally smashed one limit switch jogging before homed, so no soft limits.)

The machine is using the Axis UI, running on an industrial (fanless) i5 mini computer.  Latency seems OK and the UI is very responsive not laggy at all.  

Is this some kind of bug?  Could it be a Debian setting? 

If you feel like testing there is an alternative:

Keep line 330 (ie initcode = "") and add these lines after it:



This should initialize the interpreter with the currently active modal gcodes.

Will_cnc wrote:

Please let me know if you make any progress , I am planning on using two cia 402 motors for the tool changer but don't know where to begin.

I threw the problem at ChatGPT and got a promising response.  I've not had time to really work on it and test, but the AI Overlord suggests that carousel should be in counts mode, and connecting carousel.N.counts-target to the lcec.N.something-something-position-command is the basic connection.

I don't know about homing yet, but I don't think it's possible to get around the requirement to rotate the carousel until the index pin is triggered.

I've attached an A-axis probing routine - it's from PathPilot.  I think it's suitable for cylindrical stock along A, not really for prismatic stock.

I've not tested it, but it'd probably be a good starting point for someone to test/tweak and then submit to the ProbeBasic devs for inclusion in PB mainline.

2. Run the macro — it probes at A=0° and A=180° in Y, calculates the midpoint, and sets G52 Y to the center of rotation

For this to work the following must be true:

• You have some sort of TCP enabled, or
• You adjust rotational point to stock offset in CAM after probing, or
• You have very simple parts, with very simple programs, and
  • an internal macro/subroutine 'adjusts' the Z/Y positions for every single point in the program based on the probed offset.

I think the easiest way to explain why (I think) your proposal won't work is to make a diagram.
 


If you have TCP that takes care of everything.
If you adjust CAM after probing, that also takes care of everything.
But just probing and shifting Y will result in bad parts unless you're only machining at one A-position.

I didn't draw the other problem... but not only will features not line up, the part will orbit the actual CoR, which means at A90/A-90 the Z-position will be higher/lower than CAM expects it to be.  Maybe crashy-crashy.

The only reason to probe is if you're doing 2nd op parts and have to line up features with existing surfaces.  Even then you'll probe, adjust CAM (or TCP), and pray.

No skim cuts, no calipers, no manual offset math — roughly 30 seconds per part.

Or use a work stop that gets the stock centered enough to take care of a little excess material - roughly 1 second per part.

The cause has been identified to be a side effect of the bug fix mentioned above. You can revert this by finding 'gremlin.py' on your system (I sorry but I do not know where that is on a package installation) and change this
 

to this:

 

This will revert the bug fix.

I'll have a look at getting this fixed without regression.

 

Thanks for the detailed writeup — very helpful, especially the encoder index homing tip (I use A6 Servos with absolute encoders myself)!

For the daily workflow with changing stock I would like to find an easier way to avoid the manual indicating and skim cuts: a small probing macro that finds the rotary center automatically and sets G52.

The idea:
1. Clamp the stock (no need to center it carefully)
2. Run the macro — it probes at A=0° and A=180° in Y, calculates the midpoint, and sets G52 Y to the center of rotation
3. Swap to the cutting tool and run the program

With the WCS origin set to the rotary axis in CAM (Y0 = center of rotation), one single setup covers all rotation angles. No skim cuts, no calipers, no manual offset math — roughly 30 seconds per part.

G52 persists across resets in LinuxCNC by default, so the machine-level calibration (the fixed offset between G54 and the rotary axis) only needs to be done once after homing. The macro then corrects only for the actual clamping offset of each individual part.

What do you think?

Might be worth adding something like this to the ProbeBasic probing tab — the Rotary Axis tab seems like the natural home for it.

Please let me know if you make any progress , I am planning on using two cia 402 motors for the tool changer but don't know where to begin.

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?