Paul & Sabrina's cheap DIY 144v motor controller

[MPaulHolmes]

Well, the ISR is still being called with a frequency of 16kHz. It's just the extra stuff inside the ISR is artificially being run every 1kHz, because of the ISRCounter variable I'm using. So, I think about 1 time out of 16 calls, it may take too much time inside the ISR. But the ISR is the only thing that's happening in the whole program, except for a watchdog timer reset, which is ever 2 seconds. Is a rare (every 16 times) periodic overflow acceptable?

My understanding is that if I change the timer1 ISR frequency to 1 or 2 or 4 kHz, that it will mean that the pwm waveform will lengthen, and I'll hear an annoying buzz, since the interrupt is triggered each time the pwm waveform completes a single cycle (which takes 1024 clock counts. up to 512 and back down to 0, at which point the interrupt is called).

I could use a different timer (say timer2) with a different prescaler so that its interrupt would be called with a frequency of let's say 2kHz, but I would perhaps lose the measurement of the current at the exact same point on the pwm waveform. However, since 16kHz is a multiple of 2kHz, maybe it would be at about the same point on every 8th pwm waveform??? I'm not sure though. That would be really really nice later if I needed to do other stuff that took longer too, like sending data through the usart while driving. The nice thing is, if I try it out, go take a drive, and everything feels perfect, then it doesn't really matter too much I guess.

[dcb]

Ok, if the typical ISR call takes 80us and it is being called every 63us, then that is probably a lot more than 1 out of 16 interrupts getting dropped.

The non critical stuff can go in the main loop (not in an interrupt) and figure out when to run based on a "system clock", and the critical stuff can be updated in the interrupt. Dont forget about volatile on globals updated in interrupts.

[MPaulHolmes]

Did you have your simulator set to 16 MHz? It sounds like it's set to 8 MHz. Mine takes about 45 uS typically at 16 MHz in the simulator.

Specifically, if ONLY current happens (no throttle and no temperature), then it takes 45.75 us. The interrupt is then called again 18.13us after that. I can make it so that throttle and temp don't happen in the same loop. uh oh my son is waking up!

Oh! I'm getting 89uS for both current and throttle, which happens once every 16 times.

[dcb]

I just was looking at the change in the number of clock cycles it took to execute the function by itself, but I think it was running the interrupt in the background and doubling the resulting number of clock cycles (running the code twice). When I disable the isr it takes more like 600 cycles to run the code in the isr (about 40us). Sorry for the confusion.

[steiner]

Paul/Adam,

If you want, I have a cad program that has an embedded cam program. It allows me to either import or draw a cad file and then generate the necessary g-code to machine it. It also has the ability to drill all of the holes. I would be more than happy to do this and then send the g-code to someone with a cnc machine. My cnc is currently waiting for parts.

If you are interested, I would need either the cad drawing or a hand sketch with dimensions. I would also need to know what diameter cutter you intend to use for the machining and if your machine is 2-axis or 3-axis.

[esoneson]

Originally Posted by MPaulHolmes

I could use a different timer (say timer2) with a different prescaler so that its interrupt would be called with a frequency of let's say 2kHz, but I would perhaps lose the measurement of the current at the exact same point on the pwm waveform. However, since 16kHz is a multiple of 2kHz, maybe it would be at about the same point on every 8th pwm waveform??? I'm not sure though. That would be really really nice later if I needed to do other stuff that took longer too, like sending data through the usart while driving. The nice thing is, if I try it out, go take a drive, and everything feels perfect, then it doesn't really matter too much I guess.

Now, remember Paul, you only want to put real-time critical processing in the ISRs. Functions like reading and writing through the UART should be done in the main loop. Data can be accumulated within the ISR (counters, fault codes, etc) but it is not critical to send and receive serial data, so let the main loop perform those kind of tasks.

When serial I/O is implemented, then you will be able to adjust those constants on the fly to further tune your response times without having to recompile/reinstall/re-feedthebaby thus shortening that development cycle big time.

Your code is looking snappin' turtle good.

Eric

[MPaulHolmes]

Eric, you are funny! I tried out a completely new ISR with a separate timer that runs at 2 kHz. It went really really bad. hehe. I sampled the current in that ISR, still did the rolling average and even tried to do a rolling average for the throttle, just because I was messing around, and I wanted to see what would happen. Each second, it would be a pulse that was almost as if the motor was being shut down. It would drive normal for almost a second, and then that pulse again! Weird!

Good point about the usart stuff. That DEFINITELY doesn't belong in any ISR.

I think I need to sample the current during each pwm period, which is kind of bad because it eats up so much of the system resources. That's 2/3 of all computing time gone! But I guess it's worth it. Throttle is only needed at maybe 1kHz frequency or perhaps 500Hz. Maybe inside that ISR, I could take turns with current and throttle? Maybe skip a current sample every 16 times, to allow time for throttle? And then every 32000 times or so, skip both current and throttle to take temperature? Then, there should be 1/3 of the processing time avalailable for "other things..." Duh Duh Duhhhhhhh!

If I do throttle and temp outside, maybe that would be fine! Maybe just set a flag inside the ISR that says "timeToReadThrottle", and then I get to it when I get to it? I would have to disable the interrupts when I got to the throttle conversion moment so nothing weird would happen, but that's OK! I might try that! heck ya dude! You can't teach that, it's instinct! hahaha!

YO, STEINER! I think that would be really really helpful! I'll write out the directions for the etching and drill hole coordinates and drill hole diameters and etching width and who knows what!?

[adamj12b]

Hey Steiner,

We can give it a try. I have a few programs also for creating gcode ranging form free to +$1k. But im still not sure of which one I want to use. I need to see the layout first to make a decision. A DXF file of the layout would be a ton of help.

As for a bit, It would probable be one of the V bits I have. They are larger, but are great for larger cuts and thicker copper.


EDIT: It also comes down to how long it takes to machine. I want to run as fast as possible with a good finish.
-Adam

[dlaing]

Paul, if you take out your spin loop in the ISR you'll have a lot more time for everything else. You should have your ISR that triggers in the middle of the pwm (TIMER1_OVF_vect) start the ADC, then have the ADC trigger an ISR on completion (Bit 4 – ADIF: ADC Interrupt Flag). The ADIF then makes the current available to the main loop.

[MPaulHolmes]

dlaing! That's super sneaky! I'm going to try that one out! Sometimes an idea comes along that is so pretty, so... just plain awesome, that I just have to just sit there a second, and say.. Man, that's goood..... Really really really good....