Freesteel Blog » Gecko drives responds instantaneously

Gecko drives responds instantaneously

Friday, October 30th, 2015 at 7:34 pm Written by:

As you can see, I got lent a G320 servo drive to play with.

geckowiring

This time I put it into a slightly more sophisticated test regime than with my leadshine driver experiments involving sending 8 step pulses 1800 duration (except the first one which was 600ms duration) [in purple], then giving it 12 forward pulses from the encoder with duration 360ms followed by 4 backward pulses from the encoder of 1800ms to simulate an overshoot [in cyan]. The PWM voltage out is in yellow.

DS1Z_QuickPrint8
You can see opposing denser and weaker voltage layers in opposition as the driver delivers more of 24V+ and less of 24V- in equal measure in response to the inputs.

DS1Z_QuickPrint11

To be clear, the purple spikes are the drive pulses, and the cyan spikes are the simulated quadrature encoder pulses. They have to add up to the same amount over time or the driver assumes there is a drift and eventually cuts out when it gets to too much error. (The thin vertical white lines are 200nanoseconds apart.)

DS1Z_QuickPrint9
The unexplained phase half-way along the cyan pulse is actually from the encoderB pulse that is not wired up to the oscilloscope.

pwmplotting2

The PWM from the driver has an average period of 60microseconds with standard deviation of 4microseconds. The horizontal red line is this average value, and the white line represents this period over the 19.1333milliseconds (the gaps between vertical red lines) over which the simulated input cycle repeats. The yellow line is the relative PWM proportion calculated by measuring the timeHigh and timeLow and plotting timeLow/(timeHigh+timeLow) with 50% being on the horizontal red line. The green line is the cumulative energy, which is ascending because we are only moving in one direction.

The variation in the PWM period length must be an implementation issue, as the motor isn’t going to notice it. Only the PWM proportion is going to matter, and I can see some asymmetry in this.

The sawtooth in the middle of the picture must correspond to the 8 step pulses, the first of which is 1/3 the speed of the others, which is why it’s a double spike.

Then there’s a sort of drift as the 12 encoder pulses come in to confirm it. The 4 correcting pulses cause similar spikes to the driver spikes, but somehow the device manages to do them without messing with the PWM cycle time.

The key finding is that the duration of the spike in the signal has little correlation with the encoding error. It’s just a spike of energy lasting less than a millisecond, while the actual encoder “response” doesn’t come in till 9milliseconds later. So we’re not setting a voltage and waiting till we come to position. It’s as if there’s a big jolt on each driver pulse to get the thing moving.

I don’t actually know if this does move the motor or not. You’d think that motors would have very different responses, so it would be a challenge to build an effective driver like this that works on all of them with only two effective trimpots of tuning.

Twiddling the gain trimpot doesn’t make any difference on this scale, but the damp trimpot reduces and broadens this energy spike. I can see so many potential advanced parameters affecting the behavior, but none of them are exposed to the user. Things just kind of work okay, as they do in the world of CAM software where fixed parameters are hard-coded in every place with made up values that never get reviewed because there is no process to do so.

I can’t say whether building our own servo driver is a good idea or not. The observations here don’t fit the homebuilt driver design I read about as the voltage is set too dynamically and not on a 510microsecond cycle.

It’s probably worth doing some various PWM experiments on the servo motors to detect their response times. That is finding out how low the frequency can be for smooth movement, and so forth. This will determin the viability of running an update cycle with an integral pulse count for each window. Or maybe there’s some merit in providing advance notice of the pulses so it can change the voltages before they “arrive” instead of always following it. Later.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>