Closed loop posiiton behaviour has changed!

After some issues with my old LDC1430 controller, I have used the extended warrantee to change to the current MDC1460 controller. I have found that its behaviour is quite different.

My system uses a large 12V DC winch motor (SuperWinch) to move a rolling roof weighing about 1 ton via a chain drive. I use Closed Loop Position mode and the encoder is a self-made device using two IR LED/phototransistor pairs and a 3d-printed IR-opaque chopper wheel. I attach an image. It has worked well with the previous controller.



This generates 24 Pulses Per Rev (or maybe it's Counts Per Rev, but anyway, it's not changed).

Due to all the gearing involved in the chain drive it means that the full opening extent of almost 6 metres corresponds to count of 2352, while other commonly used positions are at 1912, 515 and 0.

The full-speed RPM of the motor (and encoder) is 55 RPM, but this results in frighteningly fast roof movement so I run it at a working speed of 20 RPM. I use acceleration and deceleration of 7 RPM/sec, which results in nice jerk-free operation.

With the old controller I used a Proportional Gain of 20.0, and both Integral and Differential Gain were set to 0.0. It worked perfectly, with nice smooth movements and no overshoots, the only niggle being a residual loop error of 2 or 3 at the destination, which I worked around by setting the close position to -3.

With the new controller, with the same settings, I first tried moving to the 515 position. it stared out well, but overshot up to about 800, then slowly oscillated around the target position with only a very slow convergence. Eventually i hit the emergency stop button and returned it to the 0 position using RoboRun+ in open loop.

I have spent some time with it this afternoon, using RoboRun+ exclusively. Playing with the PID parameters I have been able to reduce the overshoots but it is not consistent, often producing more overshoot in reverse than forward. I'm attaching a number of ChartLog files, but beware that they cover quite a lot of changing parameters (PID, Acceleration/deceleration and operating speed). I finished with Proportional Gain = 1.5, and Integral and Differential Gain = 0.0.

It seemed to me that the loop error is too big in all cases. I understood that the controller calculates the evolution of the loop counter based on the required profile and the loop error is the difference of this from the actual counter. Something seems to be amiss in this process, which was not in the older firmware (v1.4) in the previous controller, I have searched the change log and not found anything very helpful in this regard. What I have found is the following:

v1.4 08/01/2014

1.4a 11/21/2014
- Fixed Count Position bugs
- Fixed position count mode bug
- Added continuous count position tracking

1.4b 03/31/2015
- Fixed abrupt speed change in Position Count mode

1.5 10/02/2015
- Fixed overflow and several bugs in Count Position mode.

1.6 04/14/2016
- Optimised Closed Loop modes (Emergency Stop, Start-up, Track Overflow).
- Fixed Closed Loop Count Position in MDC2XXX V3.0.

1.7 10/13/2106
- Fixed bugs in Close Loop Modes (Resume from Safety Stop, Iteration, Deceleration)

1.8 07/12/2017
- Fixed Motor Jerk when loading configuration in closed loop and Encoder as feedback (EncTimer reconfiguration).
- Fixed bug when Current Limit takes place in Closed Loop Position modes.
- Fixed jumps in Closed Loop Count Position when in motion and P is executed.


1.8b 11/20/2017
- Fixed misfunctionality after restart in closed loop count position and closed loop speed position.

Any ideas what has changed?

cheers,
Richard

While waiting for a reply on my problem, I have done more investigation.

I re-installed the old controller (LDC1430), downloaded the configuration (attached) and used closed-loop position commands in the console of RoboRun+:
!S 20 followed by !P 500 (which moves the system about 20% of its total travel). The chartlog of this is also attached

Then I again installed the new one (MDC1460), downloaded the configuration, restored it to the same settings as the old controller and saved it (also attached).
Again I commanded !S 20 followed by !P 500. The chartlog is attached.

Please note that I have appended an extension .txt to the .xml profile names to allow upload here.

Instead of a smooth movement taking about 35 seconds, the new controller overshot up to a position of 881 and very slowly oscillated around the target position, arriving there after about 7 and a half minutes.

Both controller only have proportional gain, set to 20.0. The old controller is behaving as expected, with loop error never more than 20 and the motor power always about 20 times the lop error. As expected.

The new controller rapidly builds up a loop error of about 50, and the motor speed builds in as a linear ramp. While the counter and loop error become quasi-sinusiodal (though with flatter peaks) the power is a linear sawtooth. I have integral and differential gain terms of 0.0

I realise that my encoder is very low resolution and should be rebuilt, but the old controller worked fine with it.

I can't use the system like this, and am re-installing the old controller until there is a fix.

Please respond.

cheers,
Richard Francis

Sorry for the late response, I have been away from the office.

Let me know which closed loop mode you are using. I suspect that this has something to do with your minimum and maximum encoder value settings, which are used by our closed loop position implementations.

Hi Gabriel,

Kudos to you for replying on a Saturday evening -- I'm impressed. I was not expecting a response before Monday.

I'm using Closed Loop Position Count (I had hoped that, and the min/max value, would show up in the the Profile file). Since the Profile files didn't seem to transfer so well, I can add that the encoder min and max for the controllers are:
MDC1460 Min: 0
MDC1460 Max: 20000
LDC1430 Min: 0
LDC1430 Max: 20000

Note that both are the same, so it doesn't, at least to somebody unfamiliar with the internal workings of the code, look like this is an obvious culprit.

cheers,
Richard

Does your encoder put out a quadrature signal?

Yes, A and B, just like any quadrature encoder. It could not measure direction otherwise.

Okay, I have just got back to the office from a trip today, and have been catching up on emails and support. I'll test out your configuration tomorrow and let you know if I catch anything.

Hi Gabriel,

Did you make any progress with this?

I am still running on the old controller, and therefore not able to return it as planned, and nor the older SDC2130 either (since I only want to send one package).

best regards,
Richard

I have been having some problems with this since I do not have access to an enocder with a low enough resolution.

So far I have been unable to reproduce your issue. Can you confirm that you are on Firmware 1.8d?

Yes, It's v1.8d 1/8/2018

I understand that this low resolution encoder is not ideal, but in my system it's not possible to access the motor before the gears, so I have no choice.

And, it works perfectly with the old controller (at least as far as this issue is concerned). There's a real and major difference between the old and new, which I do not understand.

cheers,
Richard