How to mask Z and C interrupts on ST72T141?

econfalonieri · ‎2003-06-24

Posted on June 24, 2003 at 11:20

econfalonieri · ‎2011-05-17

Posted on May 17, 2011 at 10:16

Dear all,

we are encountering a problem in driving a PMDC motor using ST72T141 in Sensorless Voltage - Closed Loop Mode.

At low speed (1000-1500 rpm, 4 poles motor) and high PWM frequency (12kHz) some spurious Z event is generated by the motor immediately after the demagnetization; this obviously create a disuniformity in the driving (a spurious C event is obviously generated). We tried to mask this Z interrupt using a Delay routine (using TimerB interrupt). We masked the spurious Z interrupt in the correct Z event interrupt routine by a:

bres MIMR,#2

bres steph_imr,#2 ; (this var was used as a copy in RAM of MIMR in the Kanda generated code).

Then we launched the delay routine (1msec).

When this delay was elapsed, in the corresponding interrupt routine we included the following code:

bres MISR,#2 ; (to clear a spurious Z pending)

bres steph_isr,#2

bset MIMR,#2

bset steph_imr,#2

But what we noticed was that Z interrupt always was serviced and the corresponding C event was generated.

We also didn't realize how to mask the C event too! We did the same working on the #0 bit but nothing happened and the spurious C event was serviced.

And so: How to mask the Z and C interrupt?

Thank in advance!

Enrico

maxime2399 · ‎2011-05-17

Posted on May 17, 2011 at 10:16

Enrico,

even so you can mask the Z and C interrupt, it won't prevent the event to happen inside the motorcontrol cell.

consequently trying to mask the events is not the right approach.

It looks like your end of demagnetization is detected too early, therefore the real end of demagnetization is recognized as a Z event.

I recomend that you try to uderstand why.

- if you are using the hardware demagnetization detection, verify that all the edges are set-up correctly (if you can run at higer speed, this should, be ok)

- if you are using the hardware demagnetisation, a parasitic pulse may be triggering the end of demagnetization.

in this case, either you can figure out the origin of this pulse and try remove it or you can start using the software demagnetization instead.

- if you are using the software demagnetization, increase the demagnetization time: it should solve the problem

- The software demagnetization works as a blanking time where no Z event can happen. By increasing the blanking time you should be able to solve your problem.

-If you are using the software demagnetization, in your program you should be doing at every step:

MDREG <= MCOMP + demag_time

practicaly the demag_time is the Z event blanking time.

- This time may be:

measured (using the hardware demagnetization feature),

estimated according to the parameters of your system: (inductance, voltage...),

or calculated as a portion of the step time for example (MZREG/4 or MZREG/8 for example)

Let us know if it helps or not...

econfalonieri · ‎2011-05-17

Posted on May 17, 2011 at 10:16

Thank you very much Max...

Our case is a glitch following a hardware demagnetization. This glitch is considered as a Z event by the MC peripheral and this created the undesired commutations.

I think the only one way to solve this problem is to use just Software demagnetization in such a way to mask Z events for enough time to avoid any glitches.

I'm asking you if you have some reference software for a Voltage-Closed Loop Mode (just the C interrupt will be enough I think) in which just the Software Demag is used. We are using a software derived by the Kanda Motor Controller Kit and we are realizing that such modification won't be really so easy!

Thank you in advance...

Best Regards

Enrico