Advanced Search

What is the bianari file for the normal RP pico?

stepper-ninja-W5500 or stepper-ninja-W5500S

The longs motor DM542A is better than you think and is my choice of drives for NEMA23 motors if price is important.
With 25x microstepping and 48v power supply, I used the following setttings

Never mind, stupid question. All attempts result in massive errors or a segfault crash of LinuxCNC.

Thanks for looking.

Yes that is what i thought. I find it so strange that i can have ludicrous speeds in the wizard. Not sure what kind of magic is happening there

I have stepgen's maxaccel and maxvel 25% bigger than the linuxcnc maxaccel
and maxvel settings. Also i have to figure out what i can set of DIRSETUP, DIRHOLD, STEPLEN, STEPSPACE realistically for my stepper-driver. A Longs DM542A driver is probably not the best driver in the world. 

This is the max i can do without getting errors:

#******************************************
[AXIS_X]
MAX_VELOCITY = 200.0
MAX_ACCELERATION = 200.0
MIN_LIMIT = -0.01
MAX_LIMIT = 750.0

[JOINT_0]
TYPE = LINEAR
HOME = 0.0
FERROR = 10.0
MIN_FERROR = 1.0
MAX_VELOCITY = 200.0
MAX_ACCELERATION = 200.0
# The values below should be 25% larger than MAX_VELOCITY and MAX_ACCELERATION
# If using BACKLASH compensation STEPGEN_MAXACCEL should be 100% larger.
STEPGEN_MAXVEL = 250.00
STEPGEN_MAXACCEL = 250.00
P = 1000.0
I = 0.0
D = 0.0
FF0 = 0.0
FF1 = 1.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
MAX_OUTPUT = 0.0
# these are in nanoseconds
DIRSETUP   = 10000
DIRHOLD    = 10000
STEPLEN    = 5000
STEPSPACE  = 5000
STEP_SCALE = -400.0
MIN_LIMIT = -0.01
MAX_LIMIT = 750.0
HOME_OFFSET = 0.000000
HOME_SEARCH_VEL = -30.000000
HOME_LATCH_VEL = -2.500000
HOME_FINAL_VEL = 0.000000
HOME_USE_INDEX = NO
HOME_SEQUENCE = 2

hm2_7i76e: 0.stepgen.00.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.01.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.02.maxvel is too big for current step timings & position-scale, clipping max possible.

These warnings are because its not physically  possible to generate the required step rate because
the rate cannot be faster than 1/(steplength+stepspace). You can increase the maximum step rate
by reducing steplength and stepspace or using a lower micro-step ratio in the drives.

Following errors during installlation/setup are often because the stepgen maxaccel and maxvel
values do not leave enough headroom from LinuxCNCs joint/axis maxvel and maxaccel values, so check
that the stepgen maxaccel and maxvel values are at least 25% greater than LinuxCNCs joint/axis values

Hi,
I ran into this exact issue today as well while porting my routines to a new Mesa card setup. My typical workflow is:

• Move down quickly until probe touch
• Move up a bit
• Move down slowly for precise touch

There seem to be two common causes for the "probe triggered during non-probe move" error:

1. Speed-related signal bounce:
   Moving too fast (or sometimes too slow) can cause vibrations, which may result in the probe signal bouncing. This bounce can trigger the probe input at unexpected times.
2. Not moving up far enough after the first probe:
   If you only move up 1mm after the first touch, the tool might not fully clear the touch plate, especially if there is any residual flex, springiness, or electrical noise. In my case, increasing the retraction distance to 3mm after the first touch, and making sure the upward move was at a reasonable speed, completely solved the problem.

Summary of what helped in my setup:

• After the first probe touch, retract upwards by at least 3mm (instead of just 1mm)
• Ensure the retract move is at a moderate speed (not too slow, not too fast)
• Double-check wiring and mechanical play to minimize vibration

Hope this helps someone else with a similar setup! My routine before i do a touch-off:

O <touchplate_delicate> sub

#1 = 20        (touch plate dikte in mm)
#2 = -110      (Z-min limiet, uit .ini file)
#3 = [abs[#2] - #1]  (max travel distance)

G91            (relatieve coördinaten)
G21            (millimeters)

G38.2 Z-#3 F250   (probe snel naar beneden, tot plaat geraakt wordt)
G1 Z2 F250        (2 mm omhoog na contact, los van de plaat)
G38.2 Z-3 F50     (langzaam naar beneden, precieze touch)
G1 Z3 F100        (3 mm omhoog, zeker los van de plaat)

G90            (terug naar absolute coördinaten)

O <touchplate_delicate> endsub
M2

Hi all,

Thanks for all your input—everything is working fine again! There’s still some tweaking to do, but I’m getting there.

For the inputs, I made a small PCB breakout with terminal blocks, each protected by a pair of 0.5W resistors (2x 3K in parallel, so 1.5K total) to protect the Mesa card inputs. This limits the input current to a maximum of 0.016A (16mA) and 0.384W per pair.

I do have one last question. When testing my axis with the PNCconf wizard, I was able to achieve insane speeds—acceleration around 2500 and a max velocity of 15,000 (even higher values just made it wait or go slower). This seemed very promising. However, those values didn’t end up in the generated .ini file.

In reality, I had to limit my velocity to 200 to avoid errors in LinuxCNC, specifically:

hm2_7i76e: 0.stepgen.00.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.01.maxvel is too big for current step timings & position-scale, clipping max possible.
hm2_7i76e: 0.stepgen.02.maxvel is too big for current step timings & position-scale, clipping max possible.

By lowering the timing values like this:

DIRSETUP = 6000
DIRHOLD = 6000
STEPLEN = 3000
STEPSPACE = 3000

(from the original 10,000 / 10,000 / 5,000 / 5,000), I could push the velocity up to 250, but then I started getting joint following errors.

So, I think I must be missing something fundamental, because the speeds I got in the wizard are nowhere near what I see in actual LinuxCNC. I don’t need crazy speeds for milling, but jogging 20cm takes a bit too long right now. Is there a way to make it faster, or can someone explain why the wizard speeds were so much higher than what’s actually possible in LinuxCNC?

Thanks!

Many of us use a USB to RS485 converter plus the mb2hal or vfdmod hal module.

Installation step failed
An installation step failed.  You can try to run the failing item again from the menu, or skip it and choose something else.  The failing step is: install the system.

Anyone else see this and found a solution?

Yeah this thread is really the only reference. The first post maybe needs a consolidation of "this is what we do".

I'm curious about tuning these things now that we know they "work". Would like to know how arduous or easy that turns out to be.

S curves. I neeeds it.

So how stable is this at this point for "real work"? I have not been paying attention the last 2-3 months much.

Thanks. I need to do my IO and some fine tuning (servo tuning) and then I see about making a nice organised how to including files and what each line is for.



I need to figure out modbus spindle now. I hope that is easier to follow (I haven't looked at it at all yet)

I finally managed to implement this and it seems to work very well.

What it does:
- Detects the first G5x coordinate system (G54–G59.3) used in a G-code file
- Prints a debug log to the terminal: [DEBUG] G57 on line 4
- Sends the detected G5x via MDI so that the GUI updates to reflect the active work coordinate system

How I implemented it:
I added the following method to the StatCanon class in:
/usr/lib/python3/dist-packages/qt5_graphics.py

Notes:
- Make sure this method is placed inside the StatCanon class with consistent 4-space indentation.
- The initial G54 on line 0 and final G54 at the end (due to GUI reset) are ignored using: self.lineno > 0
- Only the first explicitly used G5x is applied via MDI.
- Verified to work reliably in QtDragon simulator config.

This improves usability by ensuring the GUI’s coordinate system matches what the G-code will actually use.

Tested with:
- LinuxCNC 2.9.4
- QtDragon (QtVCP)
- sim.qtdragon.qtdragon_tool_probe configuration

Let me know if this is helpful or if there’s a cleaner way to hook into the coordinate system logic.

Great info thanks. I will most likely go with the 48v supply I bought , although I will then have to add another step down supply as the board max is 24v so I will need a 48v to 24v and then 24v to 5v I already have. Worthwhile though going by the graph. I don't expect to drive at high speeds either.

Ich habe den Fehler gefunden: es war der doppelte Eintrag "net machine is on.." in der Handrad.hal. und in der Maschinen.hal. Wenn dieser Eintrag in der Maschinen.hal auskommentiert wird, dann funktioniert das Handrad korrekt.