Advanced Search

I'm sure you've got a reason for constantly swapping around your tools in a few holders, but my experience is that the less I move tools around in holders, the happier I am. It's a huge quality of life improvement IMO- reduced tedium, reduced chance of human error, reduced mental load of trying to fit all the operations into a couple tools (and/or making compromised toolpaths because you really don't want to have to change to that n'th tool)

My procedure for setting up tools uses the spindle nose as a reference and a 1-2-3 block:

1. With no tool offset applied (G49), jog spindle down to close to some reference- mill table, vise, whatever works.

2. Slowly jog spindle up until 1-2-3 block barely fits under it. Zero the work coordinate system

3. Insert a tool into the spindle, but do NOT run M6Tn- just physically insert the tool. Jog the spindle up until the 1-2-3 block (in the same orientation) just slides under the tool. Enter the Z value shown in LinuxCNC into the tool table.

4. Repeat #3 for any other tools

5. To use tools, call a toolchange with M6 Tn, for tool n. Then call G43. You can then use any tool (once you've loaded the offset) to set up the WCS for the current job and the others will follow.

The nice thing about this is you don't need a fixed reference point- probably most repeatable if you always use exactly the same place every time, but so long as you can reference the fixed spindle nose and the tool without shifting other stuff in between, nominally it all comes out correct.

The above also applies to touch probes- they get set up like any other tool (also a huge QoL improvement- even the cheap one I have has been great)

I'm afraid of Google Translate. The translation doesn't seem legible; it looks distorted.

This function comes in my PC's BIOS, "S3 video repost," and it was also part of a latency problem that I disabled.

Thanks Nick. I might start with a similar 4th Axis. I'm also looking for a used microarc.

andypugh wrote:

cnbbom wrote:

And can you please confirm that the machine actually crashes with a PWM in the base thread? 




 

As I explained here, I'm doing things manually and trying to learn, I don't know how to verify this, but remember that I did this test with preempt RT. That is, a clean installation of the linuxcnc CD with the modifications suggested by rodw. I tested with isolcpus 1, 2, 3 cores, then reduced it to 2.3 and even then the latency improved.

With the CD installation, PWM works, and the problem with trying to install the RTAI kernel was due to the high latency, which reached 120000.

cnbbom wrote:

andypugh wrote:

So, are you saying that
"addf pwmgen.make-pulses base-thread"
Causes the PC to shut down and need a reset?

Is it possible that your base-thread period is shorter than the base-thread latency?
Yes, disabling that line makes everything work except for the PWM spindle.

Is anything else running in the base thread? 
What is your base thread period. 

And can you please confirm that the machine actually crashes with a PWM in the base thread? 
 

File -> Edit Tool Table
You can manually enter the offsets of any tool.
(don't forget to reload it after editing)

The part that confused me is that the tool offset is not the offset of the *tool*, but how much you have to move the *spindle* to make the tool tip be in the right place.

That's why when you measure a longer tool, you get a bigger number, so people think it's "tool length" but internally it's not. My laser has X and Y offsets too, so when I switch to the laser the whole machine moves to put the laser in the right spot.

Yes, very familiar withTool length setting and setters, including those with RFID chips in a production facility, but my machine for sure has no way to straight forwardly attach a gauge to a non moveable part,
In fact that's an interesting question, if say I had an iso30 tool length setter, that measured the tool tip to taper gauge point, where exactly would you store that number in Linuxcnc?

Anyway, All the bits I'll ever make are more or less one offs, and every tool set will be unique, so for now I'll use the method I have worked out until it bites back.

did you turn on power to the Mesa card before starting linuxcnc?

1. Suggested pullup is 2.2K 1/2w for 24V. The only disadvantage of the pullup is the wiring nuisance.
10K will not work.

2. Enable on simple step/dir drives is not of much value safety wise as it's very unlikely to have a runaways
without the control generating step/dir pulses (and step generation will stop on a LinuxCNC or communication fault)

3. Its important that the default state of 7I76EU outputs be the safe state as all outputs will return to the power up state on
communication loss. This initial state is all outputs open circuited (this is true even if the outputs were set to push-pull mode)

Well, I can't recommend the servo reference run!
The problem is that it is not monitored. If an axis does not move, Linuxcnc does not notice. It happened to me again today. During homing, a Y-axis does not start moving, even though I waited until all axes were OP.
I will switch back to Linuxcnc homing.
It's a pity that the servos do not output the Z signal. 

Hi Chris,

I am working on document gladevcp-panels.html .
github.com/zz912/linuxcnc/commit/82dffc8...3c20d188c83819948735


How to avoid duplication information?
What information should be in Readme.md?
What information should be in gladevcp-panels.html?

Is it possible to link from one document to another?

I would prefer to leave Readme.md as is and add only the usage instructions to gladevcp-panels.html. But it has to be linked to each other.

I don't know how to link them.

Added1:
I tested your new "Available built-in VCP Panels" list and it return [CRITICAL] . Is it OK?

 

For a knee mill, right, you'd need a reference measurement each time you move the non-cnc-controlled part. If both the quill and knee are controlled by linuxcnc, you should be able to combine their locations into a single "virtual" fixed table measurement.

Or, don't put your toolsetter on the moving part of the mill

The important thing to remember is that tool lengths are relative to *each other* so as long as your technique knows that, it should work. You can't just measure a tool against something random and expect it to work.

In big shops, tools are measured outside the machine, relative to the seating plane of the tool holder - which means every tool is measured relative to (essentially) a fixed point on the spindle itself. Win! You could do this too, if you have a way to accurately measure the stick-out of the bit relative to a fixed point on the quill.

rodw wrote:

Life has got more complicated. With proper kernel tuning, latency can be better with Debian 13. I am in the process of publishing a second video about this on YouTube. Please refer to my channel. www.youtube.com/@MrRodW
The yet to be published video should be watched before the current one.

My apologies and thanks. A beginner in these things missed something; I thought it was just copy and paste, but it's all different. My processor only has 4 cores, how could a number 7 be working? But now I think I understand, and I did some tests changing the isolcpus values. I stress-tested two YouTube videos and one video on the PC plus 8 glxgears and got this result.

I am really glad, you most certainly deserved it.
Congratulations.