Tweet
John Stone,
I am sorry to hear that your wife is not doing well. You have my best wishes for a speedy recovery.
You obviously have had a lot more time to deal with the issues of the Imperial motor than I have, and given it a lot more thought. Keep in mind that I am a student of this technology learning at the feet of every one here. You have asked a lot of questions that are fairly technical in nature but I will try my best to answer your concerns and in so doing give an outline of my plan as I do have one that is subject to change upon new information. It is said that software is never finished.
1. variable frequency
I am not sure why this is a problem. I think that the 2 millisecond pulses fit nicely into our target rpm range. 3600 rpm works out to 16 milliseconds per revolution divided by four gives us 2 pulse cycles per on period. I do not subscribe to the method of varying the wait period to make adjustments to load that will be handled by the duty cycle, with the exception of ramp up to speed and catastrophic load(will talk about this later)
2. variable duty cycle
Surely 8 bits of resolution is more than adequate for our needs.
3. scalable 4/6 phase signals
The uno has 6 pwm pins, and all others have more
4. low processor load
I can't imagine that having one pin active at a time would create any more of a load than any solution we make come up.
5. timing
I have thought about this for days. In a gasoline engine all timing is mechanical in nature. The distributor is adjustable to advance or retard the timing and the valve train is kept in time with chains or belts and gears. The only help that we have with a DC motor is the commutator and brush combination. That does help significantly. If you are speaking of the race that ufo was talking about that is actually very easily implemented with pauses and a loop turning on the pin pauseing and then turning off the pin, move to next pin. and repeat. then loop back through. The problems that I for see are two and there could be more.In cases of extreme load does the rotor have enough weight to give an adequate flywheel effect, or is there insufficient inertia to keep it moving and the rpms drop precipitously. If the second condition arises it is possible that the rotor would get out of sync with the program and would need to be ramped up to speed again. If out of sync could it possibly lock up. That would be a worse case scenario. I am not that familiar with the archetecture of the Imperial to know how would could be certain that the signal will always be synchronized with the motor. Like I said hopefully the brush commutator will help us here.
While we are on the subject any attempt to enter into the clocks of the processor and come up with more control on the timing of the pulse waves as I understand will defeat the interrupts at pin 0 and 1. Whereas the pwm pins will allow the interrupts to be used without affecting their timing.
Something that I am equally concerned about is the lack of information available to us in a timely fashion to respond quickly to downturns in rpms. I would like to respond to movements down in rpms in no more than 100 milliseconds. There would only be a count of 6 interrupts available at 3600 rpms. at 3400, 5 and then it would drop all the way to 4 at 2400 rpms. Using a hall effect sensor or an infrared emitter receiver as a tachometer with one signal per revolution would only yield these amounts. I am leaning more towards the infrared emitter receiver because I could then drill extra holes to get more signals and get fractions of a revolution.
Can one Arduino be used?
Like all questions of this nature it depends. I believe that one Arduino can be used for the setup that I envision. I own several and they all have usb capabilities. The problem with all serial signals is that the signal degrades with any significant distance. If you are in close proximity, 8 to 9 feet little or no degradation. 14 feet or more will depend on the quality of your wire and components and you are rolling the dice. blue tooth not much better but doesn't require wire. How elegant is your solution? How much memory will you need to implement it. If you have an lcd you will use a lot of memory on the characters for the screen, the Arduino is a very limited platform when it comes to memory. As far as pin outs for input there should be enough, 6 and 2 interrupts should be sufficient for voltage, temp, rpms, amps, watts. and still have enough out puts for the 6 pwm and the lcd. More than that and you will probably need another or the mega.
I prefer simple solutions. Most of the time they are more than adequate. You can really overthink things when it comes to solutions. Building in the ability to quickly change and adapt to the new situation is more important than having a perfect solution. You don't know what you don't know until it bites you in the,,,,
As far as PID. I read an article by the author of the library and came away with more questions than answers. First the math is way over my head. Second he said that it works best for things that have repeatable events that require the same response each time. It wouldn't work well for something like controlling a car. In one circumstance you need to give it gas, in another a lot of gas and yet in another the brakes. Is not that what a motor speed control is all about? 3d Do we need it? I think we can do everything we need to do with several nested loops of code as far as motor control.
Last
A governor is possible with the speed control except in the event of a catastropic failure of a mosfet. If it fails with the circuit open there is no way to shut it down without pulling the cables on the battery with our present setups . I am no electronics expert but perhaps you could come up with an idea, a solonoid or something like that that could break the circuit.
Cheers,
Garry
I am sorry to hear that your wife is not doing well. You have my best wishes for a speedy recovery.
You obviously have had a lot more time to deal with the issues of the Imperial motor than I have, and given it a lot more thought. Keep in mind that I am a student of this technology learning at the feet of every one here. You have asked a lot of questions that are fairly technical in nature but I will try my best to answer your concerns and in so doing give an outline of my plan as I do have one that is subject to change upon new information. It is said that software is never finished.
1. variable frequency
I am not sure why this is a problem. I think that the 2 millisecond pulses fit nicely into our target rpm range. 3600 rpm works out to 16 milliseconds per revolution divided by four gives us 2 pulse cycles per on period. I do not subscribe to the method of varying the wait period to make adjustments to load that will be handled by the duty cycle, with the exception of ramp up to speed and catastrophic load(will talk about this later)
2. variable duty cycle
Surely 8 bits of resolution is more than adequate for our needs.
3. scalable 4/6 phase signals
The uno has 6 pwm pins, and all others have more
4. low processor load
I can't imagine that having one pin active at a time would create any more of a load than any solution we make come up.
5. timing
I have thought about this for days. In a gasoline engine all timing is mechanical in nature. The distributor is adjustable to advance or retard the timing and the valve train is kept in time with chains or belts and gears. The only help that we have with a DC motor is the commutator and brush combination. That does help significantly. If you are speaking of the race that ufo was talking about that is actually very easily implemented with pauses and a loop turning on the pin pauseing and then turning off the pin, move to next pin. and repeat. then loop back through. The problems that I for see are two and there could be more.In cases of extreme load does the rotor have enough weight to give an adequate flywheel effect, or is there insufficient inertia to keep it moving and the rpms drop precipitously. If the second condition arises it is possible that the rotor would get out of sync with the program and would need to be ramped up to speed again. If out of sync could it possibly lock up. That would be a worse case scenario. I am not that familiar with the archetecture of the Imperial to know how would could be certain that the signal will always be synchronized with the motor. Like I said hopefully the brush commutator will help us here.
While we are on the subject any attempt to enter into the clocks of the processor and come up with more control on the timing of the pulse waves as I understand will defeat the interrupts at pin 0 and 1. Whereas the pwm pins will allow the interrupts to be used without affecting their timing.
Something that I am equally concerned about is the lack of information available to us in a timely fashion to respond quickly to downturns in rpms. I would like to respond to movements down in rpms in no more than 100 milliseconds. There would only be a count of 6 interrupts available at 3600 rpms. at 3400, 5 and then it would drop all the way to 4 at 2400 rpms. Using a hall effect sensor or an infrared emitter receiver as a tachometer with one signal per revolution would only yield these amounts. I am leaning more towards the infrared emitter receiver because I could then drill extra holes to get more signals and get fractions of a revolution.
Can one Arduino be used?
Like all questions of this nature it depends. I believe that one Arduino can be used for the setup that I envision. I own several and they all have usb capabilities. The problem with all serial signals is that the signal degrades with any significant distance. If you are in close proximity, 8 to 9 feet little or no degradation. 14 feet or more will depend on the quality of your wire and components and you are rolling the dice. blue tooth not much better but doesn't require wire. How elegant is your solution? How much memory will you need to implement it. If you have an lcd you will use a lot of memory on the characters for the screen, the Arduino is a very limited platform when it comes to memory. As far as pin outs for input there should be enough, 6 and 2 interrupts should be sufficient for voltage, temp, rpms, amps, watts. and still have enough out puts for the 6 pwm and the lcd. More than that and you will probably need another or the mega.
I prefer simple solutions. Most of the time they are more than adequate. You can really overthink things when it comes to solutions. Building in the ability to quickly change and adapt to the new situation is more important than having a perfect solution. You don't know what you don't know until it bites you in the,,,,
As far as PID. I read an article by the author of the library and came away with more questions than answers. First the math is way over my head. Second he said that it works best for things that have repeatable events that require the same response each time. It wouldn't work well for something like controlling a car. In one circumstance you need to give it gas, in another a lot of gas and yet in another the brakes. Is not that what a motor speed control is all about? 3d Do we need it? I think we can do everything we need to do with several nested loops of code as far as motor control.
Last
A governor is possible with the speed control except in the event of a catastropic failure of a mosfet. If it fails with the circuit open there is no way to shut it down without pulling the cables on the battery with our present setups . I am no electronics expert but perhaps you could come up with an idea, a solonoid or something like that that could break the circuit.
Cheers,
Garry
. If I leave the interpoles, i could make it an 8 pole. 
Comment