emc-users Mailing List for LinuxCNC

Thnaks Andy,

All builts and running using your recipe

In less than 15min on the RPi4

TomP

On 6/8/26 9:34 PM, andy pugh wrote:
> udo make setuid

On Mon, 8 Jun 2026 at 11:40, Thomas J Powderly <tj...@gm...> wrote:

> (I always build a RIP after a new LCNC version install)
...
> fakeroot debian/rules binary-arch

Are you sure you mean RIP?

RIP (Run - in - place) is:
cd linuxcnc-dev/src
./autogen.sh
./configure
make
sudo make setuid

Then
. ./scripts/rip-environment.

You seem to have built a deb package. You could just install that as
an installed version. It's a bit more convenient than a RIP as you
don't need to source rip-environment.

sudo apt-get install ./linuxcnc-uspace_2.10.0~pre1_arm64.deb

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Hi Peter,

Yes, no problem.

Thank you.

El lun, 8 jun 2026 a las 10:32, Peter Wallace (<pc...@me...>) escribió:

> On Mon, 8 Jun 2026, Leonardo Marsaglia wrote:
>
> > Hi guys, I hope you're doing well
> >
> > I've been using the following configuration several years now:
> >
> > 5i24 ----(P2) ----> 7i52
> >   |--------(P3)-----> Free to use/unconnected
> >   |_____(P4)-------> 7i44 (with several sserial boards)
> >
> > The firmware on the board doesn't create any PWMGENS even though I'm
> > declaring them on the hostmot2 loading string.
> >
> > I suspect the firmware is not ready to make them. If this is the case. Is
> > there any firmware available that can keep my actual configuration (I'm
> > using several STEPGENS and ENCODERS) and use P3 for the PWMGENS I need?
> >
> > Thanks a lot!
> >
> > _______________________________________________
> > Emc-users mailing list
> > Emc...@li...
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> Can you run:
>
> sudo mesaflash --device 5i24 --readhmid > firmware.txt
>
> and send me the results?
>
> (to not clutter the mailing list)
>
> Its looks like you have a 7I52S so I can guess the firmware
> but its best to be sure.
>
> Peter Wallace
> Mesa Electronics
>
>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

On Mon, 8 Jun 2026, Leonardo Marsaglia wrote:

> Hi guys, I hope you're doing well
>
> I've been using the following configuration several years now:
>
> 5i24 ----(P2) ----> 7i52
>   |--------(P3)-----> Free to use/unconnected
>   |_____(P4)-------> 7i44 (with several sserial boards)
>
> The firmware on the board doesn't create any PWMGENS even though I'm
> declaring them on the hostmot2 loading string.
>
> I suspect the firmware is not ready to make them. If this is the case. Is
> there any firmware available that can keep my actual configuration (I'm
> using several STEPGENS and ENCODERS) and use P3 for the PWMGENS I need?
>
> Thanks a lot!
>
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

Can you run:

sudo mesaflash --device 5i24 --readhmid > firmware.txt

and send me the results?

(to not clutter the mailing list)

Its looks like you have a 7I52S so I can guess the firmware
but its best to be sure.

Peter Wallace
Mesa Electronics

Hi guys, I hope you're doing well

I've been using the following configuration several years now:

5i24 ----(P2) ----> 7i52
   |--------(P3)-----> Free to use/unconnected
   |_____(P4)-------> 7i44 (with several sserial boards)

The firmware on the board doesn't create any PWMGENS even though I'm
declaring them on the hostmot2 loading string.

I suspect the firmware is not ready to make them. If this is the case. Is
there any firmware available that can keep my actual configuration (I'm
using several STEPGENS and ENCODERS) and use P3 for the PWMGENS I need?

Thanks a lot!

I tried to build a RIP on Trixe RPi4B

The way to build a RIP has changed

I ended up with 3 debs

linuxcnc-uspace_2.10.0~pre1_arm64.deb
linuxcnc-uspace-dbgsym_2.10.0~pre1_arm64.deb
linuxcnc-uspace-dev_2.10.0~pre1_arm64.deb


Where I went wrong ( I think)...

the following message appeared :


  : Found operating system 'linux-gnu'.
  I: Argument uspace is accepted for compatibility, but ignored
  I: Successfully configured for 'uspace-Debian-13'.
  I: You can now start the build of LinuxCNC Debian packages.
     To build and test everything: fakeroot debian/rules binary
     To build the executables and man pages only: fakeroot debian/rules 
binary-arch
     To avoid tests: DEB_BUILD_OPTIONS=nocheck debian/rules binary
     To avoid documentation: DEB_BUILD_OPTIONS=nodocs fakeroot 
debian/rules binary
     The DEB_BUILD_OPTIONS environment variable also works with 
dpkg-buildpackage.
  I: All build dependencies available for complete builds including the 
documentation.cnc@raspberrypi:~/lRIP/src $


That message is new to me

(I always build a RIP after a new LCNC version install)

but I tied to follow the message

and exec'd

fakeroot debian/rules binary-arch


The result was NOT the usual,

but instead, 3 debs listed above

AND

a new executable 'linnuxcnc'  in

~/lRIP/debian/tmp/usr/bin



It has taken over 5 hrs to 'fail' so  I ask

Can I salvage the new files into an old style RIP?

what is proper way to  build a RIP on Trixie  RPi4B?


Thanks,

TomP

ceturtd., 2026. g. 14. maijs, plkst. 19:40 — lietotājs Marco
(<li...@ho...>) rakstīja:
>
> This snippet was the key. My setting MAX_LIMIT = HOME_OFFSET was the
> culprit. Giving it a sensible HOME_OFFSET fixed it.
>

That is great that it worked. One thing I use A LOT is to separate
home position from home switch by setting different values for
HOME_OFFSET (that is coordinate for home switch) and HOME (coordinate
for actual home position to which the joint moves after switching and
latching home switch, note that you need to specify home_final_vel
parameter for this). One reason is that I have "Go to machine home"
button in VCP that is linked to corresponding MDI command (containing
G0 G53 and all the coordinates that put all joints in their home
positions) and I use that button a lot and I do not like the idea that
machine is parked on the edge of switch and might trigger it
unnecessarily. Other reason is that I adjust HOME_OFFSET coordinate to
adjust machine position. For example, change home_offset for one joint
of the gantry to finetune the squareness of machine. I find it easier
to add or subtract 0.2 mm in INI file rather than trying to move the
switch for such a distance...

Viesturs

On Thu, 14 May 2026 19:10:29 +0300
Viesturs Lācis <vie...@gm...> wrote:

> I have a feeling that you should look at this part:
> https://linuxcnc.org/docs/html/config/ini-homing.html#_home_ignore_limits

I've set

  HOME_IGNORE_LIMITS = YES

so that's not the issue here.

> practice): max_limit = 100
> home_offset = 102

This snippet was the key. My setting MAX_LIMIT = HOME_OFFSET was the
culprit. Giving it a sensible HOME_OFFSET fixed it.

Thanks for all your replies! Much appreciated. X and Z limit
switches are now installed and working. The Y limit is what I'll do
next. It will not give me any headaches, I suppose.

Marco

Hello!

I have a feeling that you should look at this part:
https://linuxcnc.org/docs/html/config/ini-homing.html#_home_ignore_limits

IMHO the setup might look like this (theoretical idea, not tested in practice):
max_limit = 100
home_offset = 102
home = 99
home_final_vel = 50 (or whatever reasonable velocity)
home_ignore_limits = 1

This way home/limit switch would be 2 mm outside of theoretical work
envelope, so you should never hit it during normal operation, but it
will reach it during homing and move the machine inside work envelope
after doing home_search and home_latch moves

Viesturs

ceturtd., 2026. g. 14. maijs, plkst. 15:43 — lietotājs Marco
(<li...@ho...>) rakstīja:

>
> Hi,
>
> I've got my basic setup working and have made some cuts. Time to add
> the limit switches. For now, I've added one switch on Z+. This
> should act as a limit and homing switch. It's sort-of working but…
>
> When I'm homing the Z axes (joint 2), the machine correctly moves
> towards the switch, the machine stops and I get:
>
>   joint 2 on limit switch error
>   emc/task/taskintf.cc 976: Error on joint 2, command number 95
>
> So this doesn't seem correct. It appears that it acts mainly as a
> limit switch and doesn't quite double-up as homing switch. Likely
> due to misconfiguration on my side.
>
> I also observed that it shuts off all movement, not only movement
> towards Z+ if the switch triggers. Not sure if that's by design or
> another sign of misconfiguration.
>
> I've read
>
>   https://linuxcnc.org/docs/html/config/ini-homing.html
>
> but frankly, that's a lot to digest. Find my configuration attached.
> What do I need to change so I can use this single switch for homing
> as well as a limit switch?
>
> Marco
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

I like your way of describing this.  Went back and looked at how I have the knee home/limit switch set and indeed it's the same way although these are imperial measurements.  

So in my case I have the max limit is 13" away from the spindle nose and the home switch is set as being in essence 12.8" away from the nose so it's seen before the physical limit even though they are the same switch.

#  250 line encoderx4=1000x4:1 reduction pulley / 0.25" per Turn
#STEP_SCALE = 16000.0
#  250 line encoderx4=1000x3.2:1 reduction pulley / 0.25" per Turn
STEP_SCALE = 12800.0
BACKLASH = 0.0042

MIN_LIMIT = -12.5
MAX_LIMIT = 0.5

HOME_OFFSET = 0.3
HOME_SEARCH_VEL = 0.8
HOME_LATCH_VEL = 0.08
HOME_FINAL_VEL = -0.2
HOME_IGNORE_LIMITS = YES
HOME_USE_INDEX = 0
HOME_SEQUENCE = 0

> -----Original Message-----
> From: Luca Toniolo [mailto:lu...@ai...]
> Sent: May 14, 2026 5:53 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Combined limit/home switch
> 
> This is mostly my opinion, but it can be done in other ways.
> 
> HOME_OFFSET
> Set to 1 or 2, this is the position where the sensor will be at, if your limit
> sensor is at 0 and your max is at 0.5 you'll hit it, you want the sensor to be
> above/past the limit, think of this parameter as the position of the sensor.
> 
> 
> On May 14, 2026 8:37:27 PM GMT+08:00, Marco <li...@ho...>
> wrote:
> >Hi,
> >
> >I've got my basic setup working and have made some cuts. Time to add
> >the limit switches. For now, I've added one switch on Z+. This
> >should act as a limit and homing switch. It's sort-of working but�
> >
> >When I'm homing the Z axes (joint 2), the machine correctly moves
> >towards the switch, the machine stops and I get:
> >
> >  joint 2 on limit switch error
> >  emc/task/taskintf.cc 976: Error on joint 2, command number 95
> >
> >So this doesn't seem correct. It appears that it acts mainly as a
> >limit switch and doesn't quite double-up as homing switch. Likely
> >due to misconfiguration on my side.
> >
> >I also observed that it shuts off all movement, not only movement
> >towards Z+ if the switch triggers. Not sure if that's by design or
> >another sign of misconfiguration.
> >
> >I've read
> >
> >  https://linuxcnc.org/docs/html/config/ini-homing.html
> >
> >but frankly, that's a lot to digest. Find my configuration attached.
> >What do I need to change so I can use this single switch for homing
> >as well as a limit switch?
> >
> >Marco
> 
> _______________________________________________
> Emc-users mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-users

The more important thing is understanding why it works, because you will have similar issues with all the other axis, and you want to make sure you have the correct mental model, so you can also switch it around and shift it, when you home in negative and/or not to 0

HOME_OFFSET is the position assigned to the place where homing is sensed, aka the position of the homing sensor.

When homing, Joint does it's thing to read the homing sensor, as soon as it is done with the sensor it sets the current position to be HOME_OFFSET and then moves over to HOME position.

That's my mental model, hope it helps...

On May 14, 2026 9:10:19 PM GMT+08:00, Marco <li...@ho...> wrote:
>On Thu, 14 May 2026 20:52:57 +0800
>Luca Toniolo <lu...@ai...> wrote:
>
>> HOME_OFFSET 
>> Set to 1 or 2, this is the position where the sensor will be at, if
>> your limit sensor is at 0 and your max is at 0.5 you'll hit it, you
>> want the sensor to be above/past the limit, think of this parameter
>> as the position of the sensor.
>
>I've changed HOME_OFFSET and the error went away and it seems to
>work now. Many thanks for the quick reply.
>
>Marco
>
>
>_______________________________________________
>Emc-users mailing list
>Emc...@li...
>https://lists.sourceforge.net/lists/listinfo/emc-users

On Thu, 14 May 2026 20:52:57 +0800
Luca Toniolo <lu...@ai...> wrote:

> HOME_OFFSET 
> Set to 1 or 2, this is the position where the sensor will be at, if
> your limit sensor is at 0 and your max is at 0.5 you'll hit it, you
> want the sensor to be above/past the limit, think of this parameter
> as the position of the sensor.

I've changed HOME_OFFSET and the error went away and it seems to
work now. Many thanks for the quick reply.

Marco

This is mostly my opinion, but it can be done in other ways.

HOME_OFFSET 
Set to 1 or 2, this is the position where the sensor will be at, if your limit sensor is at 0 and your max is at 0.5 you'll hit it, you want the sensor to be above/past the limit, think of this parameter as the position of the sensor.


On May 14, 2026 8:37:27 PM GMT+08:00, Marco <li...@ho...> wrote:
>Hi,
>
>I've got my basic setup working and have made some cuts. Time to add
>the limit switches. For now, I've added one switch on Z+. This
>should act as a limit and homing switch. It's sort-of working but…
>
>When I'm homing the Z axes (joint 2), the machine correctly moves
>towards the switch, the machine stops and I get:
>
>  joint 2 on limit switch error
>  emc/task/taskintf.cc 976: Error on joint 2, command number 95
>
>So this doesn't seem correct. It appears that it acts mainly as a
>limit switch and doesn't quite double-up as homing switch. Likely
>due to misconfiguration on my side.
>
>I also observed that it shuts off all movement, not only movement
>towards Z+ if the switch triggers. Not sure if that's by design or
>another sign of misconfiguration.
>
>I've read
>
>  https://linuxcnc.org/docs/html/config/ini-homing.html
>
>but frankly, that's a lot to digest. Find my configuration attached.
>What do I need to change so I can use this single switch for homing
>as well as a limit switch?
>
>Marco

Hi,

I've got my basic setup working and have made some cuts. Time to add
the limit switches. For now, I've added one switch on Z+. This
should act as a limit and homing switch. It's sort-of working but…

When I'm homing the Z axes (joint 2), the machine correctly moves
towards the switch, the machine stops and I get:

  joint 2 on limit switch error
  emc/task/taskintf.cc 976: Error on joint 2, command number 95

So this doesn't seem correct. It appears that it acts mainly as a
limit switch and doesn't quite double-up as homing switch. Likely
due to misconfiguration on my side.

I also observed that it shuts off all movement, not only movement
towards Z+ if the switch triggers. Not sure if that's by design or
another sign of misconfiguration.

I've read

  https://linuxcnc.org/docs/html/config/ini-homing.html

but frankly, that's a lot to digest. Find my configuration attached.
What do I need to change so I can use this single switch for homing
as well as a limit switch?

Marco

Am Mittwoch, dem 06.05.2026 um 23:35 +0300 schrieb Viesturs Lācis:

[...]
> So I have been trying to get STMBL drive to work with that servomotor
> at least with A and B channels from encoder without index.
> I have connected 24VFC for logics power, 340VDC power for motr, motor
> cable and encoder cable to drive and I have plugged USB cable for
> Servoterm app. I do not yet have it connected to LinuxCNC (I have not
> tried to load smart-serial module in drive config although it is
> visible that I have LinuxCNC open in background - that is for
> enabling
> machine power).

[...]

> I spent a lot of time trying to figure it out and providing separate
> 24VDC logic power improved a lot (now it did not disconnect in a
> split
> second): https://www.youtube.com/watch?v=pCc_dh2BObo

What do you mean with "separate"? Separate from what?

USB disconnect when enabling power sounds like EMI problems. Maybe some
EM spikes couple into the USB cable and cause problems. Does dmesg show
anything? 

Try using different cable, cable with choke / ferrite bead, check for
potential difference between PC ground and stmbl logic ground, move
things around, check shield on servo motor cable, ...

-- 
Robert Schöftner <rm...@un...>

On Wed, 6 May 2026 at 21:41, Viesturs Lācis <vie...@gm...> wrote:

> So I do not understand what am I doing wrong. I would reaalllly
> appreciate if there is someone with experience of getting stmbl drive
> to work and hopefully poke me in correct direction.
> Thank you in advance!

There is an IRC channel linked at https://github.com/rene-dev/stmbl
(Whether there is anyone listening on there I don't know)

The configuration documentation is definitely rather lacking.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Hello!

It has been quite a long time since I have tried unsuccessfully to get
STMBL drive working with the Yaskawa servomotor. A little context: I
posted here a year or so ago about Biesse retrofit that I was doing
and 8i20 drives that I fitted because original Yaskawa drives were
showing some errors but I kept them to provide normal ABZ encoder
signal because actual encoder output is quadrature signal in AB lines
and commutation pattern in 3rd channel (normally used for index). I
posted about the C channel pattern and asked about possibilities to
decipher it in LinuxCNC and/or Mesa firmware. So I have 8i20 drives
for X and Y motors and original drives providing ABZ signal to
LinuxCNC. The thing is that servodrive for Z axis died completely. So
I got STMBL drive because 8i20 was not available at the moment and
STMBL has a HAL module for Yaskawa encoders (only to discover later
that it is for absolute encoders, not incremental).
I got the drive from a guy in Italy that seems to be making his
version of them
(https://freakontrol.github.io/stmbl/docs/introduction/) and I managed
to contact him on Element but he is not much in to responding to say
the least).
So I have been trying to get STMBL drive to work with that servomotor
at least with A and B channels from encoder without index.
I have connected 24VFC for logics power, 340VDC power for motr, motor
cable and encoder cable to drive and I have plugged USB cable for
Servoterm app. I do not yet have it connected to LinuxCNC (I have not
tried to load smart-serial module in drive config although it is
visible that I have LinuxCNC open in background - that is for enabling
machine power).
First thing I started with was a stmbl config as follows:
link pid
link pmsm
link enc_fb0
link misc
link id_pmsm

And I was having issues with connection of servoterm to stmbl drive.
But I managed to notice in servoterm app suggested values for conf0.r,
conf0.l and conf0.psi (I have not found any datasheet of the motor so
I have to trust the drive to sense/measure for me). Polecount should
be 8 but the app insists that it is 4 so I gave up especially after I
had specified conf0.mot_fb_res to 32768 (it is 8192 PPR encoder) so
then it should be able to detect pole count correctly.
The connection problems looked like this (I had move on from id_pmsm
to id_mot as per suggestion in servoterm app):
https://www.youtube.com/watch?v=SkFTIcRQUL0

I spent a lot of time trying to figure it out and providing separate
24VDC logic power improved a lot (now it did not disconnect in a split
second): https://www.youtube.com/watch?v=pCc_dh2BObo

But it did freeze and I could not do anything but close the app.
And when I restarted the servoterm app, it was this:
https://www.youtube.com/watch?v=z35EzysD0Pk

So I do not understand what am I doing wrong. I would reaalllly
appreciate if there is someone with experience of getting stmbl drive
to work and hopefully poke me in correct direction.
Thank you in advance!

Viesturs

> From: Robert Schöftner [mailto:rm...@un...]
> command number 110
> 
> Am Mittwoch, dem 06.05.2026 um 15:05 +0200 schrieb Marco:
> > The actual problem (on all axes) is that I can jog once, twice maybe
> > three times and then get:
> >
> > � joint 0 following error
> > � emc/task/taskintf.cc 976: Error on joint 0, command number 108
> >
> > The command number changes every time and of course the joint number
> > if I try jogging the other axes. Any ideas?
> >
> 
> The PID doesn't do much, I and D gains are 0. It is mostly there to
> compensate for jitter. The "feedback" is just the step-count from the
> mesa-card internal step pulse generator, no real hardware feedback is
> involved. So this will also happen exactly like this if the actual
> motors are turned off.
> 
> 
> Where does "P=300" come from? AFAIK in your case it should be 1000 for
> a servo period of 1000 but I would be surprised if that would be the
> cause of your problem, most of the heavy lifting should come from the
> "FF1=1.0" term.
> 
> I have a similar config (with about 5� max speeds) that works, the
> other difference apart from P is that i have MAX_OUTPUT=0 and I didn't
> define any backlash.
> 
> --
> Robert Sch�ftner <rm...@un...>
> 

I agree.  My P=1000 on my system and the FF1=1.0  

I wonder about your STEPGEN_MAXVEL and STEPGEN_MAXACCEL since you have Backlash set to 0.02

Here's a fragment from your INI file.
[JOINT_0]
TYPE = LINEAR
MAX_VELOCITY = 16.6666666667
MAX_ACCELERATION = 200
# 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 = 33.33
STEPGEN_MAXACCEL = 250
BACKLASH = 0.02

The comment says 25% larger or if using BACKLASH also 100% for the STEPGEN_MAXACCEL.
To make something 25% larger I'd multiply by 1.25 so 
STEPGEN_MAXVEL = 20.83
And 100% of 200 is 200 so 
STEPGEN_MAXACCEL = 400

Or have I misunderstood that?
John

On Wed, 06 May 2026 16:35:29 +0200
Robert Schöftner <rm...@un...> wrote:

> The PID doesn't do much, I and D gains are 0. It is mostly there to
> compensate for jitter. The "feedback" is just the step-count from the
> mesa-card internal step pulse generator, no real hardware feedback is
> involved. So this will also happen exactly like this if the actual
> motors are turned off.

Ok, thanks for the info. So not a real PID at work here.

> Where does "P=300" come from?

Me experimenting and failing to revert back to the defaults.

> AFAIK in your case it should be 1000 for a servo period of 1000
> but I would be surprised if that would be the cause of your
> problem, most of the heavy lifting should come from the "FF1=1.0"
> term.

It works now with P=1000

> I have a similar config (with about 5× max speeds) that works, the
> other difference apart from P is that i have MAX_OUTPUT=0 and I didn't
> define any backlash.

Yes, the speeds are very low. Since I don't (yet) have any limit
switches and couldn't get the machine to move, I set them low, so I
can intervene if things go haywire.

Marco

On Wed, 6 May 2026 16:41:42 +0300
Viesturs Lācis <vie...@gm...> wrote:

> I tried some quick maths and theoretically your step length and step
> space should be fine for your scale and maxvel (1 step = 10 us, so 1
> mm = 320 steps = 3200 us = 3.2 ms and theoretical maxvel at this
> timing is 1000/3.2 = 312.5 mm/s).

DM556 is set to 8 microsteps, so

200 steps/rev * 8 = 1600 steps/rev

X, Y, 5mm lead screw → 1600 steps/rev / 5 = 320
Z     4mm lead screw → 1600 steps/rev / 4 = 400

Conservatively the machine should do 3m/min on X,Y and 2m/min on Z.

> First thing I would check is making sure that the drives are happy
> with the increased step frequency you are reaching - reduce
> microstepping and step_scale accordingly as well as steplength and
> stepspace.

The DM556 datasheet states a minimum pulsewidth of 2.5µs, so
STEPLEN=5000 = 5µs should be fine, I guess.

> Second thing is about PID parameters - IMHO P=300 will not
> be correct

I was experimenting with that value and reverted to the default of
1000. It's working now. That was my mistake fiddling with too many
values without a clue what they do.

Marco

Am Mittwoch, dem 06.05.2026 um 15:05 +0200 schrieb Marco:
> The actual problem (on all axes) is that I can jog once, twice maybe
> three times and then get:
> 
>   joint 0 following error
>   emc/task/taskintf.cc 976: Error on joint 0, command number 108
> 
> The command number changes every time and of course the joint number
> if I try jogging the other axes. Any ideas?
> 

The PID doesn't do much, I and D gains are 0. It is mostly there to
compensate for jitter. The "feedback" is just the step-count from the
mesa-card internal step pulse generator, no real hardware feedback is
involved. So this will also happen exactly like this if the actual
motors are turned off.


Where does "P=300" come from? AFAIK in your case it should be 1000 for
a servo period of 1000 but I would be surprised if that would be the
cause of your problem, most of the heavy lifting should come from the
"FF1=1.0" term.

I have a similar config (with about 5× max speeds) that works, the
other difference apart from P is that i have MAX_OUTPUT=0 and I didn't
define any backlash.

-- 
Robert Schöftner <rm...@un...>

On Wed, 6 May 2026 at 14:10, Marco <li...@ho...> wrote:

> I'm a bit confused about the PID stuff. My steppers don't have any
> sort of feedback. How can a PID work without feedback?

The feedback in this case is the number of steps that the FPGA reports
having made (actually the distance it thinks it has moved, as the
command and feedback are both in distance).

For an open-loop stepper the P term of the PID should be exactly 1000.

I think if you set P to 1000 it will start working.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Viesturs

trešd., 2026. g. 6. maijs, plkst. 16:10 — lietotājs Marco
(<li...@ho...>) rakstīja:
>
> On Wed, 6 May 2026 12:09:21 +0100
> andy pugh <bod...@gm...> wrote:
>
> > This typically means that the scales are set wrongly so that more
> > steps per second are being requested than are physically possible
> > within the constraints of the step length and step space.
>
> I've set
>
>   # X, Y
>   STEP_SCALE = 320
>   # Z
>   STEP_SCALE = 400
>
> That should be correct for my machine. But maybe not. I've tried to
> adapt the default values to match my machine to the best of my
> ability. My current INI and HAL are attached.
>
> I'm a bit confused about the PID stuff. My steppers don't have any
> sort of feedback. How can a PID work without feedback? Is that PID
> code even required for my setup? I've tried to uncomment it, but the
> issue remains. So maybe it has nothing to do with that.
>
> The actual problem (on all axes) is that I can jog once, twice maybe
> three times and then get:
>
>   joint 0 following error
>   emc/task/taskintf.cc 976: Error on joint 0, command number 108
>
> The command number changes every time and of course the joint number
> if I try jogging the other axes. Any ideas?
>

I tried some quick maths and theoretically your step length and step
space should be fine for your scale and maxvel (1 step = 10 us, so 1
mm = 320 steps = 3200 us = 3.2 ms and theoretical maxvel at this
timing is 1000/3.2 = 312.5 mm/s).
First thing I would check is making sure that the drives are happy
with the increased step frequency you are reaching - reduce
microstepping and step_scale accordingly as well as steplength and
stepspace. Second thing is about PID parameters - IMHO P=300 will not
be correct (and the behavior you describe makes sense - actual
following error accumulates until it reaches the limit). Increase
ferror and min_ferror by a factor of 10 or even 100 and check if you
can jog for larger distances. This thread seems relevant about PID and
open loop steppers:
https://www.forum.linuxcnc.org/38-general-linuxcnc-questions/31046-open-loop-stepper-pid

Viesturs

On Wed, 6 May 2026 12:09:21 +0100
andy pugh <bod...@gm...> wrote:

> This typically means that the scales are set wrongly so that more
> steps per second are being requested than are physically possible
> within the constraints of the step length and step space.

I've set

  # X, Y
  STEP_SCALE = 320
  # Z
  STEP_SCALE = 400

That should be correct for my machine. But maybe not. I've tried to
adapt the default values to match my machine to the best of my
ability. My current INI and HAL are attached.

I'm a bit confused about the PID stuff. My steppers don't have any
sort of feedback. How can a PID work without feedback? Is that PID
code even required for my setup? I've tried to uncomment it, but the
issue remains. So maybe it has nothing to do with that.

The actual problem (on all axes) is that I can jog once, twice maybe
three times and then get:

  joint 0 following error
  emc/task/taskintf.cc 976: Error on joint 0, command number 108

The command number changes every time and of course the joint number
if I try jogging the other axes. Any ideas?

Marco

On Wed, 6 May 2026 at 10:31, Marco <li...@ho...> wrote:
>
>  I removed the enables (the
> physical cables to be clear) and now all three axes move. Just for
> one second and then throw an error, but hey – I got it moving, which
> was the 1st milestone.

This typically means that the scales are set wrongly so that more
steps per second are being requested than are physically possible
within the constraints of the step length and step space.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912