RPi5 and 7C81, manual control is choppy
- AkkiSan
- Offline
- New Member
-
- Posts: 14
- Thank you received: 1
Especially because the RPi5 comes with this massive performance boost <3
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
Attachments:
Please Log in or Create an account to join the conversation.
- langdons
- Offline
- Platinum Member
-
- Posts: 535
- Thank you received: 54
Maybe it'll work!
When the motion stops, does LinuxCNC show anything?
That's really weird.
Are these stepper motors?
Please Log in or Create an account to join the conversation.
- PCW
-
- Away
- Moderator
-
- Posts: 18996
- Thank you received: 5245
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)
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
- Posts: 20513
- Thank you received: 6979
www.forum.linuxcnc.org/38-general-linuxc...elocity-fluctuations
Please Log in or Create an account to join the conversation.
- AkkiSan
- Offline
- New Member
-
- Posts: 14
- Thank you received: 1
Grundgütiger. Lol; thx!Keyboard jogging issue
www.forum.linuxcnc.org/38-general-linuxc...elocity-fluctuations
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.
I created the config file with pncconf and left thePCW 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)
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
Please Log in or Create an account to join the conversation.
- PCW
-
- Away
- Moderator
-
- Posts: 18996
- Thank you received: 5245
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
Please Log in or Create an account to join the conversation.
- AkkiSan
- Offline
- New Member
-
- Posts: 14
- Thank you received: 1
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
Please Log in or Create an account to join the conversation.
- PCW
-
- Away
- Moderator
-
- Posts: 18996
- Thank you received: 5245
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.
Please Log in or Create an account to join the conversation.