View Single Post
Old 10-14-2015, 03:43 PM   #2181 (permalink)
e*clipse
Permanent Apprentice
 
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 314 Times in 215 Posts
After reading the FRM manual and the DSpic4011 manual some more, I think I understand a bit more about how the DS pic deals with simultaneous AtoD conversion.

What I didn't understand was how the CHx's were assigned to the analog inputs. For some reason I thought they were all like CH0, which allows any analog input to be assigned. NOT SO. Apparently Ch1, Ch2, and Ch3 can only be assigned to AN0, AN1, AN2 OR AN3, AN4, AN5 respectively. page 416 FRM

Paul probably said that previously, but I guess I didn't get it or didn't want to listen.

What does this mean from a hardware perspective? It means that for the very critical current1 and current2 feedbacks used for FOC and Sensorless code should not be changed, according to configurations. The current sensors are etched in stone, tied to pins 3 and 4.

Pin2 is AN0 and is tied to CH1 through the simultaneous sampling definition. The only choice left is CH0, which can be pretty much any analog input.

Just so there's some semblance of sanity, I suggest that this input be AN3. Then all critical timing issues would be handled by analog inputs AN0 > AN3. If anyone comes up with some cool device that requires time-critical sampling, that part of the board will be a known set entity.

This presents a problem regarding the resolver input, which I was hoping could simply plug into the same pins the encoder (QEI) plugs into. These are pins 5,6 and 7; also tied to analog inputs AN3, AN4, and AN5. As the resolver driver is currently built, motor temperature is AN3, resolver sin is AN4 and resolver cos is AN5. To work properly sin and cos should be sampled simultaneously, which cannot be done unless things were re-defined so AN3, AN4, and AN5 were simultaneously sampled. This would be really dumb, because now the current couldn't be sampled. I am totally against re-defining input ports on the fly, because I think it would lead to reliability problems. Secondly, I'm pretty sure that the resolver will work together with the current inputs for FOC. This can potentially save serious computing time and I'm working on that end.

This means I'll have to re-do the resolver-driver board. It also will require some main board changes. These can be done with a number of options:
1) re-route inputs using jumpers for different configurations.
2) add a set of connections for resolver input from an add-on board and a way the ensure both a resolver and encoder can't be plugged in at the same time.
3) add the circuits of the resolver driver to the main board.

In any case, I think it would be best to move the throttle input to AN6, AN7, or AN8 where it can hang out with other throttle and temperature inputs. AN0 could also be used for another current sensor to help out with the sensorless control stuff.

For testing purposes, I'm just going to go with option1. It'll be a bit ugly, and hopefully noise won't be too much of a problem. By using this method, I'll also have a free analog input pin that I can use for the double throttle setup I was talking about.

- E*clipse

  Reply With Quote
The Following User Says Thank You to e*clipse For This Useful Post:
thingstodo (10-14-2015)