RPi5 and 7C81, manual control is choppy

I had a couple of Mesa cards laying around for years and finally found some time to put it into operation.
Especially because the RPi5 comes with this massive performance boost
It’s all basically working, except for the pinout (had to solder an adapter), and everything seems to work in auto or MDI mode,
although I only tested a few moves; but manual control is extremely choppy.

The constant movement is just interrupted, as I would have stopped pushing the the button.
Acceleration/deceleration is working, so it’s not a communication issue.

Here: 


Probably unrelated, but strange:

At the end of rapid moves, controlled via MDI, the controller or LinuxCNC creates some extra steps.
I did not count them yet, but will check this after the rest is okay:

 


Are these “user space” issues? Currently I exclusively have older RTAI setups working;
never used this one kernel thingy.

Did I set up anything incorrectly?


thx
AS

 

The jogging issue is probably the standard problem with KB repeat


The overshoot is likely a tuning issue, I would use the standard velocity mode/PID stepgen control
(use a pncconf created configuration for an example) Also make sure to use the DPLL for stepgen
configurations (use pncconf again as an example here)

Keyboard jogging issue
www.forum.linuxcnc.org/38-general-linuxc...elocity-fluctuations

tommylight wrote:

Keyboard jogging issue
www.forum.linuxcnc.org/38-general-linuxc...elocity-fluctuations
 

Grundgütiger. Lol; thx!

Maybe I should borrow $CHILD2's gaming keyboard and set the polling rate 
to 20kHz. I bet that the movement then cannot be stopped in time, hehe.

PCW post=332736 userid=481[...]  
The overshoot is likely a tuning issue, I would use the standard velocity mode/PID stepgen control
(use a pncconf created configuration for an example) Also make sure to use the DPLL for stepgen
configurations (use pncconf again as an example here)

I created the config file with pncconf and left the

The units all seem to have changed from 2.8 to 2.9. Instead of periods/time we now have rates/frequency.  
I have 20+ years experience with running everything through the parallel port but 0 with Mesa cards.  

I also noticed that the former "BASE_PERIOD" (forgot what the name is now and I currently do not have
access to the new config; forgot them in the workshop) is not in the ini-file anymore.  
Not sure if this value can be changed at all. The Mesa docs are more than sparse, imho.

I must admit that I don't know exactly understand what you mean.  
Is there also an "extraordinary velocity mode"? And what is DPLL?


thx
AS
 

There have been no motion unit changes AFAIK between 2.8 and 2.9

A base period is not needed with hardware stepgens/encoder counters
(nor is it very useful with SPI or Ethernet connections)

The DPLL is a Digital Phase Locked Loop that re-times critical sampling times
(like sampling the current hardware stepgen position) This can reduce
the sample time uncertainty from 100s of usec to 100s of ns

Typical setup for Mesa stepgens is like:

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


 

Thank you very much.
I will test this.

As far as I remember, there also were PID settings, either in
the pncconfig GUI or the config file itself.
Only P was set, which seems odd.

Are these settings even valid or doing something in
an encoderless setup?


thx
AS

For the PID settings for a hardware stepgen, P should normally be
1/Servo-thread-period so 1000 for a 1 ms servo thread period,
and FF1 should be 1.000.

The physical meaning of these setting is this:

P=1/Servo-thread-period means correct any detected position
error by the next servo thread invocation.

FF1= 1.000 means set the base stepgen velocity to LinuxCNCs commanded
velocity (to center the operating point of the PID loop on the current velocity) 
This means the P term has little to do besides correcting for minor time base
differences between LinuxCNC and the hardware.