Matrix user forums

Hi,
I'm running ECIO40P with;
Servo Component (1 channel only)
CAN component (external, channel1)
UART component (software, TX only)
+ a few basic inputs / outputs.

The servo hardware is very responsive (too responsive!) it reacts to the slightest change is control pulse.
Even if the servo position value is kept constant, I can see with the scope random pulses transmitted intermitantly.
Its not noise on the lines, I see the pulse definatly change pulse width but only for a single pulse or so.

Since the pluse train is created by software using PWM0 + PWM 1 + Tmr1 is it possibe other factors behind the scenes in the code could be causing these momentary changes in pulse width?
Any ideas on things to check ?

One option is to just change servo to something a bit more laggy!

Hello,

The servo component is driven using interrupts do you have any other interrupts active in your program which could be occasionally effecting the timing? If you are using other interrupts can you make the interrupt macro more lean and do more of the servicing inside the main loop?

Just working on this now... incrementally removing items from FC program untill is stabilises.
Monitoiring the Servo Pulse with a DSO and persistance so I can catch any glitches.

BTW, Running the Servo component on its only its own macros and with a constant value , a rock steady output.
Hopefully I will corner the issue in the next couple of hours.
J.

Aha I might know what it is then, I've recently had a similar issue here with some 16-bit PIC hardware.

Basically you are using an interrupt based on the timer lets say the timer has a count up to 255 but we are interrupting at 100. Then we change things so that the timer now interrupts at 50. If the count value in the timer is less than 50 everything is ok. If the count value is already over 50 then it will go all the way to 255 and then round again until it hits 50, hence the output glitch.

I'll have a play here and see if I can improve things for you. In my code i simply reset the timer count register to 0 when changing the duty. This is potentially something you could try in your code too.

Hi Ben,
I'm keeping a constant Duty so I dont have a location in the FC to reset the timer counts. I'll try a few things in that direction though.

I've moved the ECIO40P to a EB061 Board to removed any external hardware issues from CAN controllers etc. Edited down the FC to very little and still get glitchy behaviour. See attached. Project is running from a 3A, 12V lab supply but since the DS3218 is a high power servo, I have an external 5v (3A) converter block (cheap ebay job.) to supply power for the Servo. Sharing the 0V so it has a common reference.
Previously ---I did have issues with sudden movment of the servo, transient current demand, browning out the 5V reg supplying the ECIO, I've put a bigger input Cap in and monitoring the 5v rail it look good now.
I'll continue to try to isolate the issue.

Ooooh.. I put that little C snippet into my original program and hardware, just before the main servo move. Looks stable so far, I'm going to leave it over lunch with the DSO monitoring for issues. fingers crossed.

Thanks Ben, looks stable, I'd mark that as a solution!
J.

Excellent thanks, I'll see if I can code it into the component.

Ahh bummer.
It now has another style of instability. Rather than the previous scatter gun changes to the pulse width;
Now a stable 2mS pulse, will randomly drop to 0.192mS...
I'll keep poking around, see if I can find a link to anything.

Hi Ben,
I've replicated the new problem using a spare ECIO on a EB061 base board.
Trimmed down the FC to the base essentials, it does seem to be isolated to the servo Controller component. To observe with a scope, I needed a minimum pulse width but anything above 1.5mS seems to replicate it well.
I have inserted the suggested C code, which did improve behaviour significantly. However a more consistant glitch now occurs.

Internestingly if I put a small delay after the C code I can move the glitch within the pulse, I'm guessing something roll over related but I cant really look any further under the hood.
Hopefully attached FC will replicate the issue, It does replicate the issue without a physical servo attached, just with the waveform very slow on the falling edge.
I'll leave my test hardware setup, if there is anything I can test further here, let me know.
Thanks, J.

Hello,

I've had a quick go and looked at the signals on my scope but it looks ok here. I've seen the occasional strange signal but nothing I could easily repeat.

Does moving the C code block to after the auto move command make any difference?

You could also try changing to this.

TMR0L = 0xF0;
TMR0H = 0xFF;

To try and force an imminent overflow.

Hi,
Tried moving the C code to different positions as suggested but I could still induce the instability.
Tried the alterate TMR reset value. I tried for both TMR0 and TMR1 in case there was a typo in the TMR0L suggestion. No improvment.

Interestingly, to induce the instability, I need to use the Pot to sweep the position value about. Sometimes I have to work the input quite a bit to upset it. Sometimes the I only get the odd glitch, other times I can get it to permanently glitch and oscillate the servo.

Sweeping around the 1.2mS pulse seems to regularly upset it, at least it feels that way.
With this glitch, If I stay in a single position value, thus fixed Pulse width, it seems perfectly stable.

I've kept my test setup as simple as possible to eliminate other influences. As before using a dual lab supply (with ground link) so that the servo 5V transient demands does not brown out the micro.