From EuSurplusWiki
Jump to: navigation, search

One of the most crucial steps off all the process is obtain the best performance of the motors present on the machine. This can be done in two steps, the fist is to insert correct parameters and tuning of motor on the Argon servo drive, and lately, the tuning on LinuxCnc.

Motor tuning on Argon servo drive

For fist step we will tune the motor on the Argon servo drive. The best approach how to do that can be found on manufacturer documentation.

Toque tuning

The Toque tuning is the first step to follow. It is recommended that a torque tuning is made before velocity or position tuning, as part of the torque tuning results will prevail even after the position or velocity tuning.

It is recommended to tune the motor torque response before the position tuning or velocity tuning.Torque tuning will complement the position or velocity tuning.

Manual tuning of torque controller is some times done in order to optimize the torque controller response or to find the correct motor resistance MR and inductance ML parameters if unknown. Manual tuning also usually yields better torque response than the direct method which may help tuning of velocity or position tuning.[1]

When MR and ML values are unknown, the initial MR and ML test values can be entered by one of the following methods:

  • know values of a same size motor/weight motor
  • measure the resistance between two phases of the motor for MR, then use for ML = 4*MR, that is a typical valid approximation.


We need to introduce, on Granity software, what can be an approximated values of the motor characteristics. The information should be as accurate as possible. In our case, motor number of poles, current limits and maximum speed are exactly know, but [MR] and [ML] not. Measuring the resistance between two coils, about 2Ω were obtained. Using the method described before, for the motor in question (see also Pitfalls):


Note that for this motor, the [MR] and [ML] are values that we will tuning to obtain the best response. The first entered values are a trial and error approximation.

To start the test: Steps to do to begin torque tuning:

  • Ensure that motor is parameterized correctly and working (can be powered though the Argon and no error is signaled)
  • Fix the motor shaft so that it cannot rotate under full peak torque of the motor
  • Make following parameter changes to Granity and click apply afterwards:
    • Set drive in torque control mode CM
    • Set torque bandwidth limit TBW to maximum
    • Choose Serial only setpoint input CM
    • Untick Setpoint smoothing CIS
    • Set Goals tab DIV and MUL to 50
    • Make other necessary adjustments to have drive powered and enabled
  • Set-up the test stimulus and capture settings from Testing tab:
    • Set target setpoint 1 TSP1 to 5000-15000
    • Set delay 1 TSD1 to 0.05 seconds
    • Set target setpoint 2 TSP2 to 0
    • Set delay1 STD2 to 0.5 s
    • Choose sample rate TSR of 10000 Hz or more
    • Choose Capture setpoint change ind positive direction from the dropdown
    • Tick Continuously repeating capture
    • Tick Torque setpoint and Torque achieved from signals
    • Tick Start capture to begin continous capture.
    • Tick Enable test stimulus TSE to begin a pulsed torque generation

Once the steps above are done, motor should be generating short torque pulses to a fixed shaft and torque response graphs should appear on the right side of Granity about once in 3-5 seconds.

In this test case, the output response was the following:


For the first try, it was a great result. Normally is expected a worst response on first attempts. But it should be tuned further.

As described on manufacture tutorial ,the [MR] will need to be higher, so after some attempts, the best obtained value was 1,6 Ω

And the following response was registered:


After some more improvements with the [MR]= 2,6 Ω and [ML]= 17 mH.


That is a very accurate result and concludes the torque tuning of the motor.

Velocity tuning

The Velocity tuning is the next step as the motor will be controlled in this mode.

In this wiki the Argon will be set up for velocity mode as we will be using linuxCNC in velocity control mode. It is also very common to use servo drives in position mode (also know as step direction mode). For this case, and if using Mesa hardware, the 7i76 generates step direction signals compatible with the Argon and Ioni drives.


Steps to do to begin position tuning:

  • Ensure that motor is parameterized correctly and working and torque control tuning has been properly done.
  • Attach motor to the target load and ensure it can rotate in both directions infinitely
  • Make following parameter changes to Granity and click apply afterwards:
    • Set drive in velocity control mode CM
    • Choose Serial only setpoint input CM
    • Make other necessary adjustments to have drive powered and enabled
    • Untick Setpoint smoothing CIS
    • Set Goals tab DIV and MUL to 50
    • Set acceleration CAL & velocity CVL limits reasonably to the levels that motor is expected to handle
  • Set-up the test stimulus and capture settings from Testing tab (an example, may be varied):
    • Set target setpoint 1 TSP1 between 1000 and 16383 (16383 equals the max speed that is configured via CVL)
    • Set delay 1 TSD1 to 0.25 seconds
    • Set target setpoint 2 TSP2 to same, but negative, value of TSP1
    • Set delay1 STD2 to 0.25 s
    • Choose sample rate TSR of 500 to 2500 Hz
    • Choose Capture setpoint change in positive direction from the dropdown
    • Tick Continuously repeating capture
    • Tick Velocity setpoint and Velocity achieved from signals
    • Tick Start capture to begin continuous capture.
    • Tick Enable test stimulus TSE to begin a continuous position back and forth spinning motion generation

Once the steps above are done, motor should be generating direction reversing spinning and velocity response graphs should appear on the right side of Granity about once in 3-5 seconds.

For our test, with TSP1= 2000 , TSD1= 0.5 , TSP2= -2000 , TSD2= 0.5 and in tuning tab the values of TBW= 1000Hz, KVP=100 and KVI=10, we obtain the following response:


that leaded to the following test:

It is advisable to start with a slow movement, like the one in the video so that the user can understand if it is safe for the mechanical parts and for the electronic parts to continue. Amperage that flows from the Argon drive, achieved speed, vibration and mechanical noise are good signals if the test can proceed and if the test conditions can be increased.

40px-Caution.png WARNING: The testing procedure can be dangerous. It is advisable that limit switches are installed and connected to the simplemotion break out board, to one STO input. It can be connected to the J5 plug, but in the future, linuxcnc will use limit switches as home switches, so drive limit switches functions will not be used. The controller will disable the drive in case of a emergency. As we aren't using LinuxCNC not, linking the switches to STO will provide a desirable level of safety. For example in this test case, both limit switches are present 50mm before the end of the travel (positive and negative direction), and both were tested before the servo test started. Since in this case the servo motor have a brake attached, made the testing more safe, but on a high mass, fast movement axis without a braking system, it is advisable the the user places the limit switches at a reasonable distance before the end of travel so that in case of problems the axis does not reach the end of travel causing mechanical or physical damages.

After increase the values KVP=300 and KVI=70 we start to increase the velocity of the tests, increasing to the acceleration. So the procedures of the test is based on the following steps:

  • start the test with a short range of movement of the motor, with low acceleration.
  • see if the range of movement of the motor is enough, the motor have to reach the maximum setpoint velocity during the movement.
  • rise the velocity of the motor.
  • if the motor don´t reach the setpoint maximum speed, rise the acceleration, or if the acceleration is the desired, rise the TSD1 and TSD2 values to turn the test wider.

During these steps, correct the KVP and KVI values to optimize the motor response.

This procedure is sometimes time expensive, so do not expect to achieve a good result instantaneous.

Velocity result

In the final we reach the graph on the following image. Note that this is a velocity test response where the velocity is calculated from a large number of samples (resolver on this test case have 6144 PPR). Any small variation on the nominal speed can lead to instant oscillations, like those present on the graph. During acceleration and deceleration the system behaves very well as the graph is almost totally overlapping the desired speed.

In granity we have the following motor dynamics values:

Granity motor dinamics.png

The result:


40px-Note.png NOTE: Units in the grapth raw value from inside drive which has "arbitrary" scaling, so this values should be used only for refence. The axis fully reverse to the oposite direction in less than 0.25 seconds

After further more tuning, resulted in the motion of the following video.

  • Velocity: 426.003 mm/s (25 560 m/minute)
  • Acceleration: 6711.18 mm/s^2

40px-Note.png NOTE: This resulted in the axis to reach top speed in just 0.08 seconds.


Not all went smoothly on the Argon tuning. In fact the tuning was time expensive mostly due to an initial error. After the torque tuning was made as described, and as the velocity tuning was initiated we noticed that the motor did not replied as expected. It was observed that the motor did not had enough strength to achieve the needed velocity and it was also observed that the amperage sent from the Argon to the motor was very high (reaching about 10A without the motor moving) and finally if the shaft was forced to move it would rotate on its own a full (or near a full) turn, as the following video shows.

It was not clear enough what could be wrong, and after we rechecked almost all settings and connections (many hours lost) we noticed that we did not had the information from the motor manufacturer about the number of poles, and we used 8 poles as it is a very common. After setting the motor characteristics to 6 poles, we could continue our tuning and obtained the results posted on this page. Strangely enough the torque tuning worked out fine even with the pole settings wrong, so it hard to find that the pole count was wrong after the torque tuning was correct.

On the manufacturer page, it explains 2 methods of count the right number of motor poles, please see this link

A easy way to verify correct settings is to put drive in torque mode and give torqe setpoint command from Testing tab. Motor should start spinning maximum speed if everything works properly (test without motor attached to machine). If feedback resolution and/or pole count is wrong, motor will rotate some amount and stop, and when forced with hand, it will have certain zero torque positions where it stabilizes.

Motor tuning on LinuxCnc

After the Argon drive was fully connected to the 7i77 and the tuning was made on the drive itself, the PID internal velocity controller of linuxCNC needed to be tuned.

A good tutorial to servo tuning was made by John Thornton and can be found here. Its reading is recommended.


The tune is made by changing the PID value. PID stands for Proportional, Integral and Derivative controller. In a very short, incomplete resume, information arrives at LinuxCNC and LinuxCNC decides what to do with that information, based on the PID settings to achieve a determined task. In a velocity control, that is the case here, LinuxCNC reads the speed provided by the motor feedback device (encoder, resolver, ...) and outputs requested velocity, based on its PID setup.

40px-Note.png NOTE: In this particular case, using the 7i77 and the Argon, the request made by LinuxCNC will be in the form of the analog signal (-10v to +10v) that the Argon is prepared to accept.

Before starting the tuning, understanding the halscope utility (included in LinuxCNC) is mandatory. Without understanding its basics is useless any effort as all actions depends on the halscope information. Please visit the EuSurplus halscope page with the basic information needed to proceed with the axis tuning. A more general document about the halscope can be found on the LinuxCNC official docs, here.

Tuning start at last

This process is normally time consuming and many tests need to be done in order to achieve a good motor performance.

40px-Note.png NOTE: Test should be done at a slow speed to avoid run outs or unexpected movements as the axis it not calibrated. In order to have a good comparison between tests, the same jog speed and direction sequences should be used (for example, 1st right from left then left to right)

40px-Caution.png WARNING: Emergency stop and limits should be already wired.

Test 1

Without any tuned made the test response was obtained and the result is present on the following image. A slow feedrate was used so that the probability of a following error was low. We recommend between 5 to 10% of the target max speed. In this case the initial tests were done at about 1000mm/min.

Since the expected error is large, the maximum permitted error should also be large. Therefor the .ini file was changed and set up for allowing 10mm of following error. Note that two types of errors for each axis are present:

  • FERROR - This is the maximum allowed following error for rapids.
  • MIN_FERROR - This is the maximum allowed following error for non rapids (cutting/following movements).

The rapids following error are normally more permissive than the cutting following error for obvious reasons.

We can see that as soon as a commanded position (red channel) was provided to the machine the motor feedback value (blue channel) took some time to catch up the commanded position. This reflects on the axis following error represented in yellow. On this test, made at a slow jog speed, it was observed that the signal amplitude was about 3 entire vertical squares, meaning that about 3mm of following error were obtained.

1 notune.png

Test 2

The most commune approach to tune a PID is to increase the proportional (P value) factor until oscillation occurs. In order to set the PID values, the .INI file can be edited and to linuxcnc to reload the values, it must be restarted. Fortunately, it was implemented a calibration menu, where the PID values can be changed and applied instantly. This way testing and verification is possible without shutting down linuxCNC.

On the next image the testing was made with a P value of 150. Oscillation was visible, this means that for now, P should be set lower that the 150 value. The other settings can influence how far the P value can be set higher.

2 lowerP.png

Although the system is oscillating, it can be observed that instead of 3mm of following error, we now have about 1.5 x 200m = 300m or 0.3mm. So about 10 times less error than before. It is recommended that the jog speed is the same among tests to understand how the settings are improving the system response. P was set to about half than 150, so that we get a smooth - no oscilation (but unfortunately with higher following error).

Test 3

After testing several other settings, we started to touch the FF1 value (feed forward). This setting value is often crucial to lower the constant following error. Setting it at 0.6, we got the following result:


That corresponds to about a 0.2mm max following error. If the FF1 was set too high, the obtained step response looked like:

5 ff1toobig.png

Clearly the error was inverted despite the fact that the movement was made on the same direction. This means that the ideal FF1 value if between the two previous tests.

Test 4

As the tuning appeared to be reasonable, we started to test the axis behavior at larger speeds. At 20m/min the following was obtained:

7 20ms acelarationrised notune.png

Test 5

Changing the FF1 setting (after several attempts) we got a reasonable response:

8 ff1tuned.png

Test 6

Then tuning the integral and derivative:

9 ff1 I D tuned.png

Test 7

And finally the tuned system response:

10 tuned.png

where it can be observed that the following error is amazing small at velocity of 1 m/s.

11 tuned 1ms.png

40px-Note.png NOTE: Is normal to obtain different responses from equal test conditions. We even obtained different responses on the same working area with the same settings, just testing several times. Motor temperature and drive temperature also plays a important aspect in fine tuning.

Final test

Final test was done using the linuxcnc logo, with a path feedrate of 8000mm/min (315 in/min) and rapids between paths of 21300 mm/s (838.58 in/min). The following error was captured during the full movement of the test, and the result was very good, where we got maximum following errors of about 0.1mm that certainly was during a fast movement.

Final test.png

This category currently contains no pages or media.