Feature Request

tommylight wrote:

Maxerror lines should be omitted or deleted on stepper systems.
Using sensors as end stops is not a good idea, hard stops should be where your sensors are and sensors should be mounted sideways.

PCW wrote:

Sounds like somehow there is a step in the commanded position
that violates the machine maxaccel limits. It should be bounded by both
the stepgens maxaccel/maxvel settings and the pid maxerror settings

Would it be possible to plot the motor position command in halscope
to get an idea of what's happening here? (with a finger posed over Estop)

PCW wrote:

Normally they are not needed if you have the DPLL enabled
Basically they prevent the PID from doing crazy things with
the stepgen velocity if the PID component gets bad information

How can the PID get bad information? if you have bad jitter
and you are not using the DPLL, the feedback position
from the stepgen will be sampled sometimes with a significant timing error
causing an error in the feedback position vs LinuxCNCs commanded
position. The PID acts on this bogus error and makes a large velocity
correction, worse case causing a stutter or stall.

The maxerror setting is redundant if you have the DPLL enabled

In this case, the maxerror is limiting the PID correction of what looks like
commanded motion from LinuxCNC that violates acceleration constraints

The LinuxCNC pins that I would watch would be:

joint.0.motor-pos-cmd (for X)
joint.1.motor-pos-cmd (for Y)

PCW wrote:

The DPLL will be enabled (for the stepgen) by something like this in your hal file:

# latch 50 usec before nominal read time:
setp hm2_[HOSTMOT2](BOARD).0.dpll.01.timer-us -50
setp hm2_[HOSTMOT2](BOARD).0.stepgen.timer-number 1

( The [HOSTMOT] and (BOARD) tokens make be the actual card name and 0
depending on how your hal/ini files were generated )

I would try to get a scope capture when the actual stutter occurs.

setp    hm2_5i25.0.watchdog.timeout_ns 5000000

PCW wrote:

Normally the 5I25 configurations do not have the DPLL module as the access latency
tends to be better than Ethernet cards. Its possible to make 5i25 firmware with the DPLL
but standard configs don't have it.

I dont think its an actual issue unless you have quite poor latency (100s of usec)
on the host PC in which case you might get noise/stuttering all the time

phillc54 wrote:

I just laid down to hit the hay

Sleeping on the job, we can't have that.

I pushed some more changes, better feed rate calcs, better error handling and also it will restrict the travel for consumable change to 10mm (0.4") from all limits.

I don't think it will affect the stutter issue but I have something for you to try.
When you get to stage that you see the stutter issue, back away from the limit then in Halshow in this order:

• put a watch on plasmac:offset-enable
• unlinkp plasmac.offset-enable
• sets plasmac:offset-enable 0

Notes:
two lines have a colon and one line has a period.
when you put the watch on, the led should have been on, then it should have extinguished when you did the sets command.

Now jog to the soft limits and see what happens.

Edit: you will need to net the plasmac.offset-enable pin to the plasmac:offset-enable signal to get the table to work again or restat LinuxCNC. (net plasmac:offset-enable plasmac.offset-enable)

• put a watch on plasmac:offset-enable
• unlinkp plasmac.offset-enable
• sets plasmac:offset-enable 0