Thanks for the fix, I have tried every solution and every damn thing I have tried has failed to get it to run consistently. really starting to annoy me!  MONEY BACK time if I cant get it to work soon!!!!!!!!!

Where do you place the code and do i delete some of the other code?

I am fairly new to arduino programming and am not sure how to apply the fix.

Thanks Jason

after using the code from vincenzo.matacelo I can say it really really improves the behavior.  It dampens the acceleration and deceleration enough to give it time to recover from a shadow as well as gives it a much more consistent speed and improves diameter control.  With this small change I don't need my ugly hack for behavior when it loses the line.   I didn't really have a problem with my filawinder resetting so I can't speak to that.

I really think this should become part of the standard firmware, with perhaps a change to give faster deceleration when in manual mode

The slow PWM changes is a bit of a hack or workaround on the PID values, though it helps.  I had to dial them down a lot, and it only barely got smooth enough.  It ended up only going up to 150 PWM during auto mode even when it needed full speed.  Adding the scale factor to get top speed up to 255 also made the movement a little more rough so the code to slow down PWM changes helps there.   There is an Autotune function to go with the PID library.  If I can figure out how to implement that, it may smooth everything out enough on its own.

All things being equal and ignoring the rest of the schematic - the circuit you describe will prevent it being able to draw current from the capacitor (assuming we are below the reverse breakdown voltage of the diode in question ).  So yes, when it starts drawing more 'power' , then it will be sourcing this only from the power supply and not the bypass/filter cap on the arduino.

However - as the motor spins down and voltage is suddenly removed/reduced, it causes 'flyback' as the motor is now a generator - If you've ever turned your Solidoodle off, then rapidly moved an axis back and forth (say by pulling/pushing the X-axis quickly) you can actually power up the Sanguinololu/Ramps/etc (if you have an LCD attached, it will light up..) In the circuit described, it will cause that additional voltage and current (sometimes 100's of volts depending on motor size) to be pumped back into the circuit and pop goes the arduino (or the cap if its above its voltage rating - which is why capacitors on motor circuits are usually rated for 100's of volts...)  . To solve THAT problem, you use another diode which then gets installed 'reversed' across the inductive load which will cause that additional generated load to be 'harmlessly' dumped straight into ground.  A diode in that arrangement is called a 'flyback diode' or 'snubber' or 'freewheeling' diode...

And if you were really paranoid about ensuring a clean/protected circuit, then you'd also use a Schottky diode rated for 5.1v (or whatever specific load you are seeking) across the power rails to the arduino.. a Schottky will basically allow anything up to its stated voltage to 'pass' but as soon as say 5.5V's appears on the power rail, it will 'clamp' and again just dump the excess 'harmlessly' to ground...

Oh and agreed re caps - caps and more caps are important and solve lots of problems - many IC's will stop working and go out for long lunches and return rolling drunk if they dont have a small .1uf cap right next to their power pins... in these scenarios its about smoothing out the tiny DC ripple that will creep into any and all circuits...

Anyway - It should be noted im not an EE, ME or any E... so don't actually take anything I've just said at face value

In my mind I am assuming the diode prevents any flow of current from the cap responding to the load of the mosfet/motor.

Just a general question I've had as an ME with other dc motor projects.

That's, like, 101 for fixing electrical problems .

[by 101 I mean not basic fundamentals, I mean, when you have electrical problems throw caps everywhere and it can help, i've found.]

I don't know much about the filawinder but if we're talking PWM I assume we're also talking about a DC motor. Caps on the motor can also help noise in the system. Check out this doc. http://www.pololu.com/docs/0J15/9. But if you're thinking it's power-sag related, then that's a different problem then documented in the pololu note. Still a worthwhile read, tho .

I really think this should become part of the standard firmware, with perhaps a change to give faster deceleration when in manual mode

int puller_speed_old = 255;

after

unsigned int line_position; 
int spooler_speed = 200;
int puller_speed = 255;
int rotation_status = 0;

I've been playing with the behavior when it loses the line.  Ive changed QTRSensors.cpp... with my changes it no longer stops if it loses the line above center mark or goes wide open if it loses it below center mark.  Instead it will pick a speed based on the position of the knob.  If its below center line it will have approx 3 times the effect as above instead of off/on
It does however mean that if it goes above the line it will continue to move some so you need to pay attention to how you set your knob.  These changes are in the QTRSensors::readLine function

 if(!on_line)
    {
        // If it last read to the left of center, return slower speed based on knob.
        if(last_value < (_numSensors-1)*1000/2)                   
                       return  (analogRead(knob_Pin)*.5)+1500; //never fully shutoff                                 
        // If it last read to the right of center, return faster speed based on knob.
        else
                    return analogRead(knob_Pin)*1.4+1500;
    }

and you also need to add

        int knob_Pin = 6;

after

unsigned long avg; // this is for the weighted total, which is long
                       // before division
    unsigned int sum; // this is for the denominator which is <= 64000
    static int last_value=1; // assume initially that the line is left.

My thinking behind these changes is my winder seems to often lose the line because of a shadow then because the two speed options are so extreme the filament is out of position before it resets itself.  So hopefully by allowing a configurable speed it will buy itself more time for reset

I understand why my filawinder rebooting at random causing a reset of all calibration...and so stopping working in automode.

i've seen the v10 firmware version with eeprom storage for calibration value but i don't like this reboot that can be very dangerous for arduino board..

so... the problem is in Hardware.. let me explain..

the motor is directly connected at the mosfet.. connected at the power ... when motor is stopped and the PWM raise to a high level "200 or more" in less than 0.5 second , motor drain MORE AMPERE that the alimentator can... and the tension at arduino core goes down , resetting arduino board..

there are 2 possible solution..

1° software solution

void pull_control()
{
  qtra.readCalibrated(sensorValues);              
  unsigned int line_position = qtra.readLine(sensorValues, QTR_EMITTERS_OFF, 1);  
  

  Input = line_position;                         //Get line position from sensors


  if (!pullPID.Compute()) return;              //Run the PID 

  int ScaledOutput = (Output * 1.7);             //Scale the Output from 0-150 to 0-255)       
  if (ScaledOutput <= 0) {ScaledOutput = 1;}     //Limit the output to the range of 0-255) 
  if (ScaledOutput >= 255){ScaledOutput = 255;}
  puller_speed = ScaledOutput;
    
  if ( (puller_speed - puller_speed_old) > 25) puller_speed = puller_speed_old + 25;
  if ( (puller_speed - puller_speed_old) < -25) puller_speed =  puller_speed_old - 25;
  
  analogWrite(motor_spoolerPin,puller_speed);    //Set the spool speed to the PID result
  puller_speed_old = puller_speed;

}

Force PWM to raise only by +-25 every 0.1 second (using the pullPID.Compute 100ms).

2° hardware.. put a capacitor in parallel with the motor that cut some of pwm wave...

with 1° solution in auto mode my filawinder didn't reboot more..