Advanced Search

I think tootall did an updated version.

If these are voltage mode (bare PWM) drivers, the tuning is somewhat like
velocity mode servos (with low velocity loop gain) That means that FF1 is critical.

I would first set a relatively  low P term and adjust FF1 so that during constant velocity
the motor neither lags nor leads the desired position (too much FF1 will make the
position lead and too little will make it lag) Note that this is just for tuning during constant
speed motion.

Next I would adjust D as high as possible while remaining stable.

Next do the same with P and back off about 30% from where it becomes unstable

You can now add some FF2 to compensate for the following error during acceleration
and decceleration.

Finally you can add as much I term as is stable (watch out for big oscillations)
and then back off about 50% from the point where it became unstable

Note: If you need to retune FF1 , you need a low P term and zero  I term

Also if you can decrease the Ethernet latency and run a higher frequency servo
thread, the performance will be improved.

Ignore what Langdon suggests, his advice is unreliable at best, mostly uninformed and most formed in an empty head and produced rectally.
My apologies for sourcing the thread and being so crass but many a time I have seen the above mentioned member not answer the topic and speak non sense.

Whilst I myself don't have correct answer Tommy or some other more knowledgeable member may chime in.

As for decreasing the thread period, aka increasing thread frequency I would run a latency test using the new figures the see how this affects latency, just to be sure there are no surprises, the Linuxcnc docs will have this information, but it will be need to run from the command line.

Once again apologies for the crass warning.

The guidelines would be in the raspberry pi config.txt docs. As I'm sure has been mentioned previously.
You will have to read the main thread to find the location of this file as it is not in the same location as the raspberry pi images.
Honestly for your case use I would ditch the Linuxcnc image, install Linuxcnc via apt to a RaspiOS, there is information on the forum regarding this, or as I mentioned earlier build from source, you don't require an RT kernel to build from source.
The zswap fix is to actually have swap a compressed swap in memory. It is not just to "fix an error log message", which you don't seem to understand.
If you aren't going to bother to try I can't be fucked to give you help on what is really a non issue for an image created to run a CNC machine which is something you admitted you are not intending to do. And in that case you have been given suggestions to overcome what is a very minor issue.
Regarding the zswap it seems you didn't see or ignored the issue it caused for a user when the system was left idle. I'll repeat this one more time, it is not a fix for an error log message, the error log message pointed to an actual issue and the fix was to fix the actual issue.
So far I have offered some suggestions, yet you have not bothered to attempt any. Maybe this image is not suitable for your intended use and another solution maybe a better path to take.
Good luck in your endeavours but I have exhausted my patience and will to help

I have a question. How to use Fixed PDO mapping on Lichuan LC Servo?

I used 10 entries in PDO 1600h ( Variable PDO ) in ethercat-conf.xml ( 10 entries are maximum )
So I just moved some <pdoEntry>  to FixedPDO (1704h )
But it didn't work.

Do I have to do something to use FixedPDO ?
Are there any good example for it ?
 

There is the LinuxCNC homing documentation:

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

There are also some you tube videos around
that will show up if you google "linuxcnc homing tutorial"
 

The machine worked before, but basically your saying due to the amount of power being used aka the P needed to get the motor to move and then the drift is evidence that the motor is probably a little under powered? So maybe I need to redo the tuning overall instead start from P = 300, D = 0, I = 0, BIAS = 0 FF0 = 0 FF1 = 0 and FF1 = 0 and see if im still getting drift? The other option is to see if i can increase the servo-thread update frequency? from 1000000 to 900000? That would get more more cycles per P right giving me more response, but is essentially the same as increasing right?

Just to close the loop on this from a Teknic/ClearPath perspective, they have a Jitter delay that can smooth out motion, that was set at 14ms, when turned off the f-error dropped to 2ms which is in the ball park of a timing loop. 

Long story short, I am turning off everything PID related since I am using CSP and DC as long as my jitter setting is the same on all the motors they will all end up at the same commanded place at the same commanded time even if LinuxCNC is 2ms behind. 

Hello.
I had to recreate LC10 homing code from zero reading manual designated for a driver with a motor with incremental encoder . ( I thought original code was difficult to fix )

If you still have some problems, I consider to open my codes...( I have something to do for some improvement )