Advanced Search

Is the estop input debounced? (software or hardware)

A bare parallel port input will react to 20 or so ns noise spikes
These will occur only occasionally because the likelyhood
of the servo thread reading the input just an the moment of the
noise spike is unlikely. Motor drives make just these sorts of spikes.

Note that while an open switch wire with as resistive pullup will be susceptible
to capacitively coupled noise, a shorted switch wire will be susceptible
to inductively coupled noise.

I would check the routing of the estop wiring to make sure is is not anywhere
near the motor wiring.

If all else fails I would try a RC filter on the parallel port input pin (say 330 ohm and .1 uF at the parallel port itself)
or adding a hal debounce component to the ESTOP signal

Well, yes and no, not the same thing.
If the arrow on the X axis shows towards positive values, it is wrong, but if it shows towards negative then all is good.
From your ini file:Setting all those to 0 should work, but i never tried it without also removing limit switch inputs.
-
Some more info:
-you can have Y axis with limits as you have it now
-you can make a new config that has no limit switch on Y for use with rotary
-you need to move just the motor wires over to rotary.

That is interference, no matter how you put it, caused by:
- bad wiring,
- cross wiring,
- no ground,
- bad grounding,
- ground loops,
- bad power supply/s,
- dirty power supply (not physically)
-
A quick way to narrow down things is to use the halscope and watch the input parallel port pins, 4 at a time, for each port.

Ok here are the 2 files you requested,  I could not find the line you said to delete (Home_'''_ velocity).With the choice of the Axis configuration, has not caused any problem with any of the CAD software I use.(SheetCam, Estlcam, and Lightburn)  this sort of shows how it is 

 
 
 
 

@cmorley

I’m attaching a video showing the Z-axis height measurement in the QtDragon GUI using the Basic Probe.
Note: For debugging and troubleshooting purposes, I made two modifications in my case:

• The probe_down function (in probe_routines.py) was adjusted to perform a single-touch measurement because of time.
• In the parse_input function (in basic_probe.py), a message was added in the "COMPLETE" section, which appears in the top right corner of the window. This message should appear after a successful measurement.

In the video, three consecutive measurements were performed:

• In the first measurement, a debug message popped up immediately after starting the probing, caused by a change in the feedrate value via the potentiometer — I consider this behavior undesirable. At that moment, the Z-axis measurement value was immediately updated to 0, and nothing else happened afterward.
• In the second measurement, the feedrate value changed again during the measurement, and right after this change, the Z-axis value from the first measurement was updated.
• In the third measurement, I set the potentiometer so that its value would not change spontaneously during the measurement. The measurement went smoothly, and the Z-axis value was updated only after the Z-axis returned to its start position. However, this value was already delayed since the first measurement.

Additional note: If the feedrate value does not change during the first measurement, it doesn’t affect the measurement itself. Even in that case, the first displayed Z-axis measurement value will be 0.

I hope I explained everything clearly



EDIT: added config files:
 
 

Yes, but that was probably with a different signal line. Also, I killed all the halscope and started over. I think Todd's got the explanation.

Sorry for not responding to these earlier, I thought I had subscribed, but I wasn't getting notifications of your replies.

That makes sense Todd. I was thinking of it as an analog scope.

My machine is self designed/built, 3 axis wood router. 2.2kW spindle, conventional steppers, LinuxCNC 2.9something, LMDE6.
G540 motor driver at 48V, software stepping with parallel port(s).

My estop circuit is really simple, there is a NC emergency stop switch with a 5k pullup. For the past couple of months, estop has been randomly triggered with no cause I've been able to find. It could happen in 10 seconds after motion enable, it could run for an hour before being triggered. I can enable LinuxCNC and watch it, 10 seconds to 10 minutes (i.e. random) and it will go into estop, with the motors powered (locked) but not moving.

Estop randomly triggering will only happen when either at least one motor is connected to the g540, or a heavy resistive load (15 Ohms, 2x across where the stepper coils would be). With no load on the g540 estop will stay off. I have looked at the power supply voltages, they are fine during an estop event (using a DVM, not looking for a transient with a scope).

The machine has been working fine before this. The only things I can think of that I've done to the setup:
1. Fried one of the outputs on the motherboard parallel port. Now I have 3 parallel ports, two PCI cards and the motherboard. I'm only using the two PCI cards, but the motherboard parallel is still visible to the system.
2. Replaced the estop cable (!) with nicer wire.

What I've tried:
1. Replaced the estop cable again. I realized that the first replacement was no longer twisted pair. I replaced it again with shielded cable, shield connected at the box containing the g540 and power supplies. Interference seems unlikely since the switch is a short.
2. Cleaned the switch contacts, which didn't help. Jumpered the switch, which didn't help.
3. Removed the C10 breakout board. One parallel port goes directly to the g540, the other went to the C10. There were only two switches connected to the C10, the estop (!) and the electrical touch probe, I just hardwired them to the parallel port. Appeared to greatly improve the problem (a lot longer between estops), but now it's back to 10 sec - 10 min.
4. Greatly improved cooling on the g540.

I don't really see how the g540 can be causing this estop problem. The only estop connection to the g540 is estop OUT from the computer. Symptoms, however, seem like the g540 has something to do with it. I did check the 48V is rock steady through an estop. Note that the g540 stays powered up (motors still powered) when an estop happens. I can reset the estop and it will be fine again for 10 sec 10 min. This doesn't sound like a thermal problem.

Any advice?
Thanks, Steve

 

Looking at a mazak integrex 200y:
 
I just realized that your machine is actually more setup as a lathe so the above will not be much help.
The best way forward would likely be to build a new custom kinematic for your type of machine. I have a series of documentations (including the jupyter notebooks for sagemath) if you want to have a go at it:
github.com/Sigma1912/LinuxCNC_Demo_Confi...tating/Documentation

[edit]
If you attach your vismach model I'll see if I can find some time to help you.

I have a sim config for a b-axis head / c axis table in my suite of twp-configs on my github site:
github.com/Sigma1912/LinuxCNC_Demo_Configs/tree/main

 

to test this you need to:

1. download and unpack the folder 'LinuxCNC_Demo_Configs-main'
2. from the unpacked folder copy the folder '5axis-twp' and paste it into your 'configs/sim' folder
3. right click->Properties->mark as executable the following files (otherwise you get the permission error you got):
- '5axis-twp/twp-helper-comp.py'
- '5axis-twp/vismach/xyzbc-trsr-gui.py'
 

 
 
 
 

I tried to figure out if I see something with pyOCD but I don't understand if I'm using jlink/stlink or links wrong....

Dear Community,

I’m excited to share io-samurai, an open-source, budget-friendly interface for LinuxCNC and remote I/O projects, built from the ground up for makers like you! I’ve been working hard on this project, and I’m thrilled to announce that once the first batch of final PCBs arrives and I’ve thoroughly tested them, I’ll be releasing the full project on GitHub under the MIT License. Here’s a sneak peek at what’s coming:
What is io-samurai?
io-samurai is a versatile platform for CNC control and remote I/O, powered by Raspberry Pi Pico/Pico 2 and W5100S/W5500-Lite Ethernet modules. Key features:

    16 inputs (20–50 V, MCP23017, I2C) with Zener protection.
    8 high-current outputs (50 V, 500 mA, TD62783-driven, MCP23008-controlled).
    Single analog inputs (10 kΩ potentiometer, 0–3.3 V, GP26).
    40 MHz SPI (~6000 Hz burst) for fast Ethernet communication.
    Optional SH1106 OLED for I/O status and IP display.
    LinuxCNC uspace HAL driver (compiled with halcompile, .so), with safety features like timeout and data checks.
    Python library for automation and remote I/O.

It’s perfect for LinuxCNC users, but also great for IoT, home automation, or any project where you want to experiment with hardware and software.
Current Status
I’ve invested $268 into prototyping, and the first five final PCBs are on their way (~$40–50 each). Once the PCBs arrive and pass testing, I’ll publish the project on GitHub, including:

    Firmware: Pico/Pico 2 code with Wiznet’s ioLibrary_Driver (MIT licensed).
    HAL Driver: Uspace .so for LinuxCNC, with full setup guide.
    Hardware: Gerber files for PCB manufacturing (e.g., JLCPCB, PCBWay).
    Documentation: Detailed pinout.md, setup-guide.md, and io-samurai-manual.pdf.
    Python Library: For remote I/O and automation.

The GitHub repo (github.com/atrex66/io-samurai) is ready to go live under the MIT License, ensuring everyone can use, modify, and contribute to the project.
Get Involved!
I’m passionate about making io-samurai accessible to the LinuxCNC and maker communities. Here’s how you can join the journey:

    GitHub: Follow the repo for the upcoming release (github.com/atrex66/io-samurai).
    X: Follow updates and share your thoughts: @aTrEx77.

What’s Next?

    PCB Testing: Validate the final boards with W5500-Lite, MCP23017, MCP23008, and 10 kΩ potentiometer.
    GitHub Release: Share all code, docs, and Gerber files under MIT License.
    Roadmap: Mach3 driver, FPGA-based step generator, (~$150 full CNC or HMI control with display and pi Zero 2W).

I’d love to hear your feedback or ideas for io-samurai in LinuxCNC setups! What features would you like to see? Let’s build something awesome together. Built with ❤️ in Hungary.

Cheers,
Zsolt Viola

Patreon: Support development for early firmware access, technical posts, or consultations ($5–$30/month)
Patreon link ( #)
 

Thanks for taking the interest.

Just realized that T1 at 0.000 is sensible.
It is the datum point against which the other tool offset heights are measured.
My previous post used the wrong terminology, not 'cutting length' but 'tip offset'.

I have an edge finder permanently mounted in a NT30 chuck.
I could set all my tool height offsets reference that.
Could be an ideal time to start using my table mounted tool height setter.

I never tripped over this in years of Axis use.
Always just touched-off the actual tool when it was mounted, never used the tool table.
When the mill is next in use, I will check how Axis handles this.

Hi Aciera,

thank for the input. Today I started to configure vismach, when i realized that my TCP moves seem off by quite a bit. Which leads me to the following questions:

With the Mazak Z axis is lying horizontal and X standing vertically. -> So i switched X and Z in my vismach model and everything's fine. But in TCP i realized that if i switch between normal and TCP my Z axis was moving left and right. Which had to do with the X/Y offsets for TCP. Witch made me lead to the conclusion, that in the TCP calculation the tool-offset need to be applied to X and not Z. Which than begs the question if the formulas for X and Z need to be switched completely.

So i started doubting everything and searched the forum. I found your XYZBC-TNR example which sadly i can't run right now because of some permission problems:

But I'm still not quite sold if i can copy the the TCP math from this example. With the Mazak the head is swiveling around Y (B-axis) in your example it's a dual table config.

I would be real glad if you could give me some input on:

- 5 - axis Kinematic with swiveling B axis head
- The X and Z axis switch debacle
 

Hi,

Using the linuxcnc iso & ethercat my jog speed is max 5000 mm/min. and apptime 50000.
This is tested on a laptop. Very bad performance.

I used to have apptime 15000 and jog speed around 19000 mm/min using a desktop pc.