DT-Ints latency and other interrupt conciderations

[boroko]

Hi Henrik,

Discussion on the servo driver has been quiet for a while. I hope you haven't lost too much of your work!

As far as the comm, are you just using it to adjust the PID or is the intent to feed data out frequently?

Bo

[HenrikOlsson]

Hi Bo,
I managed to redo what I had lost fairly easily and have been working on it since then. I moved the serial send rountines to the main routine, sending one char each pass thru the routine - if there's nothing more important to do. The serial comms are mostly for setting the various parameters but also for sending internal variables out to help tuning. Currently I have a mode where it spits ot the current error at 50Hz.

I've added velocity feed-forward to the PID routine and I'm now working on acceleration feed-forward. Code size is my biggest concern at the moment, I'm up to 7400 words so it's starting to get tight - and I have many more features I'd like to add.

Have been adding and changing a lot of stuff withot retesting what kind of step-rates I can get so I may need to take a step back again - we'll see how it goes.

/Henrik.

EDIT: Duh....make that 7400BYTES - not words, plenty of space left in other words :-)

[boroko]

Cool!
UHU, watch out!
I have been trying to piece together a servo driver on a much smaller scale and attempting to glean from you and others the best way to do it. Speed, error, and mass are of minimal concern due to the application. I am going to drive an LMD18200 and 18F2431.
Looking forward to seeing your progress
Bo

[HenrikOlsson]

Still got a long way to go before it can compare with the UHU-chip, it's quite impressive how much Uli has been able to get that little AVR to do - without hardware encoder counter. But yeah, the long term plan is to be able to replace the UHU chip on my HP-UHU boards with this one - but that's still a long way to go.

My "developing platform" is exactly what you have, a 18F2431 and a LMD18200. I can't believe that the LMD18200 still lives after all the abuse I've put it thru.... Still using CCP1 for the PWM here but will change over to PCPWM module after re-designing the board.

So, how's your project going? What type of control, position, velocity? Command source, ananlog, step- and direction, high level serial commands?

/Henrik.

[boroko]

HI Henrik,

The project is an extension of a prior post regarding electronic gearing. I have been using a Gecko 320 and it is way overkill for this app. The most that it will see is 500 Hz from the encoder at x4. It has very little mass and that makes the error handling easier. Like everyone else, I have way too many projects going on simultaneously, so this one is not getting the concentration that it needs. So far, I have been just following this and 3 or 4 other related threads and trying piece everything together to learn.

I hope to get back on it by the weekend.
Thanks for all your work, it is encouraging.

Bo

[DDDvvv]

hi everyone,
i burned my 18f4431 after reversing the 5v power supply (warning!!!>if using power on the icsp cable on the ql200 dev board, black cable is +5v and red cable is gnd!! thanks to the hongkong designers for defying convention!!!!

now im stuck using the 2431 until my mouser order arrives on thursday. this means that all parameters are to be adjusted through hserin to eeprom. i managed to get this working:

     DATA @0, WORD $0140          ;P EEPROM
     DATA @2, WORD $0020          ;I EEPROM
     DATA @4, WORD $0025          ;D EEPROM
     DATA @6, WORD $0000          ;INTEGRATOR CLAMP value in eeprom
     DATA @8, WORD $01FF          ;OUTPUT CLAMP value in eeprom
     DATA @10, 8                  ;I TERM value in eeprom
     DATA @12, 5                  ;MINIMUM DUTY value in eeprom
     
     READ 0, pid_Kp.LOWBYTE      
     READ 1, PID_KP.HIGHBYTE                    
     READ 2, pid_Ki.LOWBYTE
     READ 3, PID_KI.HIGHBYTE                                          
     READ 4, pid_Kd.LOWBYTE
     READ 5, PID_KD.HIGHBYTE                                                                      
     READ 6, pid_I_Clamp.LOWBYTE
     READ 7, PID_I_CLAMP.HIGHBYTE                                          
     READ 8, pid_Out_Clamp.LOWBYTE
     READ 9, PID_OUT_CLAMP.HIGHBYTE               
     READ 10, pid_Ti                  
     READ 12, MIN_DUTY

i can display all these variables using a hserout, with no sweat. the problem starts when i try to adjust the values using hserin, from a terminal program on my pc (realterm) i tried using a serial dt-interrupt routine and it shows that pc and pic are communicating, but i cannot figure out how to grab the word variables from the receive buffer and load them onto eeprom. how are you guys doing it? im just playing around with this, until i get my 4431's of which ill be using adcin to change all variables.
here's what im trying:

on serial receive interrupt, read RCREG, TO RX_TEMP1
if rx_temp1 = "P" then read RCREG to rx_temp2, then read rcreg to rx_temp3
write value of rx_temp2 and rx_temp3 onto "p" in eeprom

thats the idea in pseudocode. i know im doing it all wrong, and please be gentle with a beginner. thanks for reading.

[HenrikOlsson]

Hi,
The way I do it is (basically) having an interrupt triggered by the USART when a character is received. The ISR takes the char and puts into an array that acts as a buffer, then it increments a "pointer" so it knows where in the array to put the next byte when it comes in. Finally it checks if the recieved char is a LF or CR - if it is it sets a flag, telling the main rountine that there's data to take care of.

The main routine sees the flag and looks at the first character in the array, if it's a "P" it knows it's supposed to set the proportional gain. Next it uses the "pointer" to determine how many charcters there are in the buffer and finally it uses ArrayRead to "convert" the correct number of ASCII characters in the buffer to a value.

In reallity it does a bit more than that but that's pretty much how I did it.

/Henrik.