DT-Ints latency and other interrupt conciderations

[Ioannis]

The AN I think is 774 not 744. The driver you have might be based on pure assembly. What clock does it have?

Ioannis

[HenrikOlsson]

Of course, you're right! I've mentioned it twice now and managed to get it wrong both times.

Obviously I don't have access to the source code for the drive but I was told by the developer that he was using MPLAB+BOOSTC (that probably means ASM for the time critical stuff and C for the rest). I don't know what oscillator speed it uses but I suspect it's 10*4MHz.

/Henrik.

[Ioannis]

It makes sense to be so. Are you clocking at this speed too?

Ioannis

[HenrikOlsson]

The protoype, on which I managed to get 60kHz+ yesterday, is still running on 20Mhz which makes me believe I should be able to reach my target of 100Khz even after adding the "front end" and some other features.

But right now these serial routines is making me go nuts....

[Ioannis]

Well, if you go from 20 to 40 MHz then your nice 60KHz is made with no pain 120KHz. That is more than 20% of your target, leaving you with a margin for the serial communication.

Why not try this first, to ease the pain?

Ioannis

[DDDvvv]

once again, thanks for the wonderful pid filter. im still troubleshooting, and my main problem is this;

 MAIN:                                             
     IF POSITION < SETPOINT THEN                  ;decreasing the setpoint                
     pid_Error = setpoint - position            ;calculate error
     ENDIF
     IF POSITION > SETPOINT THEN                  ;increasing the setpoint
     PID_ERROR = 65535-(POSITION - SETPOINT)    ;calculate error                                                              
     endif         
     gosub pid                                  ;take error to pid filter  
     DIRECTION = pid_out.15                     ;determine direction
     PID_TEMP = ABS PID_OUT
     DUTY = PID_TEMP                            ;load duty cycle from pid_out
     select case DIRECTION                      ;direction bit to control    
     case 0                                     ;  hpwm 1 for forward or hpwm2     
     GOSUB FORWARD                              ;  for reverse to corresponding
     case 1                                     ;  h-bridge circuit 
     GOSUB BACKWARD                             ;
     END SELECT
     LCDOUT $FE, $80, "POS=" ,DEC5 POSITION, " SP=" ,DEC5 SETPOINT; temporary
     LCDOUT $FE, $C0, "DT=" ,DEC5 DUTY, " ERR=" ,DEC5 PID_ERROR   ; temporary                 
     goto Main

my calculated pid_error jumps from 65534 to 00001 , skipping two numbers; 65535, and 00000. i have the recommended position calculation,

 position = 256*poscnth + poscntl

this runs from a dt_interrupt (thanks Darrel Taylor). i tried to change setpoint and position variables to byte, instead of word, but pid filter works on word variables, and all calculations get messed up. any solutions? this has been my biggest headache on this project, for the last three weeks. and any help from anyone will be highly appreciated. thanks in advance.

[HenrikOlsson]

Hi,
It "skips" 0 because when Position=Setpoint (ie. Error should be 0) neither of your < and > evaluations are true so it won't even calculate the error. Why it skips 65535 I haven't figured out though. Can you explain why you have those two comparison statements?

All you really should need to do is pid_Error = Position - Setpoint or Setpoint - Position if you prefer it the other way around, it doesn't matter as far as the PID routine is concerned.

Let's say pid_Error = Position - Setpoint (all three are 16bit variables):
If Position is 10000 and setpoint is 9000 the error will be calculated to 1000
If Position is 9000 and setpoint is 10000 the error will be calculated to 64536 (-1000)
If Position is 1 and setpoint is 0 the error will be calculated to 1
If Position is 0 and setpoint is 1 the error will be calculated to 65535 (-1)

Just pass it to the PID-filter, it figures out the sign of the error.

/Henrik.