如何屏蔽ST72T141上的Z和C中断？

亲爱的大家，
 
 我们在无传感器电压 - 闭环模式下使用ST72T141驱动PMDC电机时遇到问题。
在低速（1000-1500转，4极电机）和高PWM频率（12kHz）时，电机在退磁后立即产生一些假Z事件;这显然会在驾驶中产生不均匀性（显然会产生虚假的C事件）。我们尝试使用Delay例程（使用TimerB中断）屏蔽此Z中断。我们通过以下方法在正确的Z事件中断例程中屏蔽了伪Z中断：
bres MIMR，＃2
bres steph_imr，＃2; （该var用作神田生成代码中MIMR的RAM中的副本）。
然后我们启动了延迟例程（1毫秒）。
 
当这个延迟过去时，在相应的中断程序中我们包括以下代码：
bres MISR，＃2; （清除假的Z待定）
bres steph_isr，＃2
bset MIMR，＃2
bset steph_imr，＃2
 
但是我们注意到Z中断总是被服务并且生成了相应的C事件。
 
我们也没有意识到如何掩盖C事件！我们在＃0位上做了相同的工作，但没有发生任何事情并且虚假的C事件得到了服务。
 
所以：如何屏蔽Z和C中断？
 
预先感谢！
恩里科



以下为原文




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

恩里科，
 
即使如此，您也可以屏蔽Z和C中断，它不会阻止事件发生在电机控制单元内。
因此试图掩盖事件并不是正确的方法。
 
看起来你的退磁结束过早被发现，因此退磁的真正结束被认为是Z事件。
 
我建议你试着理解为什么。
 
- 如果您正在使用硬件退磁检测，请确认所有边缘都已正确设置（如果您可以以更高的速度运行，这应该没问题）
 
- 如果使用硬件去磁，寄生脉冲可能会触发退磁结束。
在这种情况下，您可以找出此脉冲的原点并尝试将其删除，或者您可以开始使用软件退磁。
 
- 如果您正在使用软件退磁，请增加退磁时间：它应该可以解决问题
 
- 软件退磁作为消隐时间，不会发生Z事件。通过增加消隐时间，您应该能够解决问题。
 
- 如果您正在使用软件退磁，那么在您的程序中，您应该在每个步骤中执行：
MDREG＆lt; = MCOMP + demag_time
实际上demag_time是Z事件消隐时间。
 
- 这次可能是：
 测量（使用硬件退磁功能），
 根据您系统的参数估算:(电感，电压......），
 或计算为步长时间的一部分（例如MZREG / 4或MZREG / 8）
 
如果有帮助，请告诉我们......



以下为原文




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...

非常感谢Max ...
 
我们的案例是硬件退磁后的一个小故障。这个故障被MC外围设备视为Z事件，这就产生了不希望的换向。
我认为解决这个问题的唯一方法就是仅使用软件退磁来屏蔽Z事件足够长的时间以避免任何故障。
我问你是否有一些电压闭环模式的参考软件（我认为只有C中断就足够了），其中只使用了软件Demag。我们正在使用由神田电机控制器套件衍生的软件，我们意识到这样的修改不会那么容易！
先谢谢你...
最好的祝福
恩里科



以下为原文




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