Contraptor

arthurwolf · 13 Oct 2010 19:16

Hello.

So, I'm still trying to get my mini-cnc to work with the pololu steeper drivers and my sanguino.
I have run into some trouble, all of which seeming to be related to the fact that I use 1/16 micro steeping.

This leads me to values like :

#define X_STEPS_PER_MM   2500
#define X_MOTOR_STEPS    3200

Which the firmware seems not to like.

First problem I ran into was the firmware didn't do accelerations for feed-rates superior to 217 mm/m ( went directly to full speed ).
I'm not sure who writes this firmware so I'm posting this here, tell me if you know who to report this to.
Fix is, in stepper_control.pde , replace :

next_move_ptr->steps_to_accelerate = (int)floor(square(master_axis_feedrate) * steps_per_unit / ( 120 * units_based_constants[MAX_ACCEL] ));

with:

next_move_ptr->steps_to_accelerate = (long)floor(square(master_axis_feedrate) * steps_per_unit / ( 120 * units_based_constants[MAX_ACCEL] ));

Otherwise you get negative values for values bigger than int, and it skips acceleration.

The second problem is one I'm still stuck with :
During acceleration, at higher feedrates, the motor stops working after accelerating for a while. Depending on values, it might start working again when maximam speed is reached, then stop working again during deceleration.
I asked on pololu forums, where I was told it may be resonnance from the stepper, or a problem with the signals my microcontroller sends.
I disconnected the stepper driver, and connected a speaker on the step pin instead : the problem is with the signal the step pin sends.
I have read most of the code for this pin, and still can't find where the problem is.
Here is the detail of the problem:

I have added the following code just before the end of the pin interrupt loop thing ( OCR1A = timer1LoadValue; ) :

  if( sequence_step_number % 100 == 0 ){
    Serial.print(millis()-last_dump);
    Serial.print(" ");
    Serial.print(sequence_step_number);
    Serial.print(" ");
    Serial.println(timer1LoadValue);
    last_dump = millis();
  }

Note : the problem exists even without this debug code, it's not causing it, it just adds a bass line to the sound from the speaker.
So now every 100 steps I get the time it took to do that step, the step's number, and the duration we will wait untill sending the next step signal.
I made a graph with the data :

X is step number, green Y is timer1LoadValue, and red Y is the time the step took ( it's supposed to be the same as the green one ).

What it looks like is that when the timer1LoadValue variable gets near 255 and 127, the steps take a lot longer to iterate than they should.
These two values don't seem random, but I don't find the problem in the code.

Anybody has an idea ?

Thanks a lot !
( will post this in the reprap forums in a few days if no answer here )

EDIT :

To get only the iterations that are too long, I put the following debug code :

  if( (double)(micros()-last_dump) > 30000 ){
    Serial.print((double)(micros()-last_dump));
    Serial.print(" ");
    Serial.print(sequence_step_number);
    Serial.print(" ");
    Serial.println(timer1LoadValue);
  }
  last_dump = micros();

Here is an example of the data this outputs :

start
1775536.00 2 23432
ok
32876.00 13308 246
32876.00 13315 246
32876.00 13322 246
32876.00 13379 244
32876.00 13510 244
32872.00 14889 232
32876.00 14910 232
32876.00 14916 232
32876.00 14964 232
32876.00 14989 232
32876.00 15010 232
32876.00 15183 230
32876.00 15218 230
32880.00 15234 230
32876.00 15249 230
32876.00 15252 230
32876.00 15265 230
32876.00 15330 228
32876.00 15334 228
32872.00 15367 228
32876.00 15383 228
32876.00 15589 226
32876.00 15748 226
32884.00 15758 226
32884.00 15764 226
32876.00 15779 226
32876.00 15791 226
32888.00 15793 226
32876.00 15795 226
32876.00 15797 226
32876.00 15799 226
32876.00 15801 226
32876.00 15805 226
32876.00 15807 226
32888.00 15809 226
32876.00 15811 226
32876.00 15813 226
32876.00 15815 226
32876.00 15817 224
32876.00 15831 224
32876.00 15841 224
32876.00 15853 224
32876.00 15862 224
32884.00 15866 224
32876.00 15870 224
32888.00 15877 224
32876.00 15881 224
32876.00 15886 224
32876.00 15896 224
32884.00 15930 224
32872.00 15962 224
32876.00 16030 224
32876.00 16036 224
32872.00 16053 224
32876.00 16063 224
32872.00 16068 224
32876.00 16073 224
32876.00 16096 222
32876.00 16103 224
32876.00 16119 222
32876.00 16130 222
32876.00 16133 222
32884.00 16136 222
32876.00 16148 222
32884.00 16152 222
32876.00 16159 222
32892.00 16182 222
32888.00 57610 214
32872.00 57661 214
32872.00 57666 214
32872.00 57676 216
32872.00 57682 216
32872.00 57726 216
32872.00 57880 216
32872.00 57891 216
32872.00 57899 216
32872.00 57927 216
32880.00 57935 216
32872.00 57939 216
32872.00 57950 216
32868.00 57956 216
32872.00 57968 216
32872.00 57979 218
32872.00 57989 218
32868.00 57991 218
32872.00 57993 216
32872.00 58015 218
32872.00 58024 218
32872.00 58026 218
32872.00 58035 218
32872.00 58050 218
32872.00 58055 218
32872.00 58067 218
32868.00 58073 218
32884.00 58099 218
32892.00 58129 218
32884.00 58498 220
32876.00 58538 220
32876.00 58558 220
32872.00 58571 220
32872.00 58574 220
32872.00 58601 222
32872.00 58612 222
32876.00 58614 222
32872.00 58616 222
32872.00 58661 222
32872.00 58803 222
32884.00 58823 222
32876.00 58838 222
32872.00 58850 222
32872.00 58866 222
32876.00 58872 222
32872.00 58878 222
32872.00 58886 224
32876.00 58898 224
32872.00 58922 222
32876.00 58935 224
32876.00 58952 224
32872.00 58958 224
32872.00 58973 224
32872.00 58997 224
32880.00 59086 224
32872.00 59166 224
32876.00 59183 226
32884.00 59200 226
32872.00 59217 226
32872.00 59252 226
32872.00 59258 226
32876.00 59301 226
32872.00 59426 226
32876.00 59435 226
32876.00 59456 226
32884.00 59489 228
32876.00 60514 236
32872.00 60942 238
32872.00 60949 238
32876.00 61045 240
32828.00 75002 120

So it seems the loop lasts 32768 microseconds too long for some values.

EDIT 2:

Putting the last_dump = micros(); just after ISR(TIMER1_COMPA_vect) { shows the problem is not with the calculations being too long ( never lasts over 200microseconds ), so the problem is with the PWM thing.

Albanetc · 14 Oct 2010 05:09

Hmm, very interesting. Can you increase the sampling rate near the spikes, just to see if there is a pattern?

Not sure what to make of it. Seems like an issue with the timer, but I'm wondering if it's helped by the fact that ISR routine modifies its own triggering timer.

arthurwolf · 14 Oct 2010 20:51

Ok, found it !

The problem was the following : changing the upper limit for the timer (OCR1A) to a lower value without stopping it/reseting it, caused it to run all the way to overflow before starting again.
The problem is solved by removing this line in the interrupt :

OCR1A = timer1LoadValue;

and doing this at the beginning of the interrupt :

ISR(TIMER1_COMPA_vect) {
  TCNT1 = 0;                                        //reset timer
  OCR1A = timer1LoadValue;                          //change timer value

Solves my problem, does not seem to create more.
However, it seems like the correct solution to this is to use the fast PWM mode using OCR1A for defining TOP (WGM13:0 = 15) since the OCR1A then will be double buffered, but I have very little idea how to do it.

I strongly recommand testing then commiting this to the svn repo in case someone else later tries to use it for 1/16 microstepping.

Pfew !

Albanetc · 21 Oct 2010 03:48

Wow, good find! Will test this as soon as I try microstepping.

alexmos · 14 Nov 2011 17:07

Thanks for your investigation! I had the same problem with the high pulse rates, and this topics helps to find it. But your solution works not well in my case. My setup needs 1280 steps/mm, and maximum fedrates I have got with default firmware, was 250mm/min running at 16MHz microprocessor. The problem rises when a step interval becomes lower than 150-200 us in the acceleration phase, because the code to calculate it takes the same time, and TIMER1 skips it's interrupt and runs until it overflow (~32000).

You solution reset the timer and prevent overflow run, but as negative result, it doubles the step interval. Motors sounds "noisy" in the acceleration phase (and I suppose they skip steps).

I have a better solution. On non-modified firmware, add a line after

  if (inTimer1InterruptRoutine) return;
  inTimer1InterruptRoutine = true;

  // set very long time to disable timer1 interrupt until we are finished here
  OCR1A = 0xffff;

and replace

  OCR1A = timer1LoadValue;

with

  OCR1A = max(timer1LoadValue, TCNT1+10);

If the calculation time is longer than the wanted step time, next step will follow just after calculations will be finished.

Another problem of current firmware is variable (and not-predicted) pulse duration. I have added a code to set precise and configurable pulse duration using second timer. It is to complicated to write differences here, but it is about 10 lines of code total.

As a result, I can now get smooth motion with feeds 300 and even 500 mm/min without skipping steps. It is 2 times better than before.

Albanetc · 25 Nov 2011 08:00

I tried your code and can see (or rather hear) a slight improvement over Arthur's fix. I'm running a different revs/inch ratio, but recalculated to your ratios, previously I could hear a stutter in acceleration/deceleration when moving at 400 mm/min (but not at 375 mm/min). Now I can't hear that stutter at 400 mm/min, but can detect it at 425 mm/min and can clearly hear it at 500 mm/min. Not sure if the acceleration rate plays a role here, or if it's the pulse duration improvement (that I don't have) that results in a smooth motion. I'd be interested to try out the pulse duration modification.