I call the Generate_PWMs() function every program cycle and my equipment jitters/doesn’t respond!
**Most equipment will not work if you call the Generate_Pwms() every program cycle. It is best to have a significant delay between the times you call it. The Generate_Pwms() function should not be used lightly, so keep the following in mind when considering its use.
In most cases, YOU WILL RECEIVE NO ADVANTAGE BY USING Generate_Pwms(…) over allowing the Master processor to generate the PWM signals. In many cases you will experience problems if you use this function because not all equipment can handle a faster PWM signal. The ONLY cases in which you might need to use this function are if you have feedback loops that need a quick response, such as a balancing robot or holding an arm at a constant position. Even then you must verify that your equipment will work correctly with a faster signal.
Many hobby servos and some speed controllers require at least a 17ms period between PWM pulses to operate correctly, so it is best to leave the corresponding PWM output to the Master if you want to control such equipment.
Innovation First’s Victor Speed Controllers can handle a very fast update rate, so you should be able to call Generate_Pwms very frequently, with only a very small gap in between. If you still see jitters on your motor, try increasing the time between calls of Generate_Pwms(…).
Newer EDU Multi-Speed Motors should also be able to handle a relatively fast update rate, while older ones may not.**
In the original default code, for the v2.2 compiler, PWMs 13-16 use a generate function to control the PWMs. How does this function work and what exactly does it do? How are PWMs 13-16 different from PWMs 1-12? I am asking this because yesterday we were testing our modified default code using optical encoders connected to the digital I/O pins. The wierd thing that happened was that as the encoders were rotated faster (about 900rpm attached to a cordless drill) the drive wheels started rotating. I looked through the code and did not see any other function other than the generate function that calls pwms 13-16. For now we just changed our drive wheels to operate off of PWM 9-12 and the wheels do not turn by themselves when the encoders are rotated really fast.
Also, is there a reason why the default code used with the camera uses pwm 11 and 12 while the default code without the camera uses pwms 13-16? Is this similar to the issue I am having now?
The PWM outputs 1 - 12 are handled by the Master microprocessor. PWM outputs 13 - 16 are generated via the user code. All four of these PWMs get generated within 2ms at a 26.2 ms rate. These PWMs are susceptible to interrupt interference. PWM signals have 255 steps and each step is ~5us. Since interrupts have at least a 5us latency, they will stretch a PWM signal up to the amount of time it takes to process the interrupt. So if your user code is processing interrupts at a high rate or your interrupt routines are long, the pwm signals on outputs 13 – 16 could be modified/stretched to create a forward condition on a motor. PWM outputs 13 – 16 should be avoided if user code is interrupt intensive.