Strange motor problem

Hi,

I'm using an Azteeg X3 controller with repetier firmware and I have a strange motor behaviour.

When motors are disabled, the first move on the Y axis often generated a short noise ("CLAC') when it starts. It also occurs on the first Y move after each Z move. And it sometime produces a shift in the print, especially if I print faster.

Someone suggested that the firmware may disable the motors when Z moves, and then re-enable them before moving again. If the delay after enabling the motor is not long enough, the motor may really start whith a higher speed than min speed...

I only have DISABLE_Z set to true; all other motors are false. I even tried to set DISABLE_Z to false, but it does not change anything.

Any idea how I can fix that?

Thanks.

---

Frédéric

So, nobody has this problem? I'm pretty sure it's a firmware issue, as it only occurs when motors are disabled.

I think that the firmware disables the X/Y axis when Z moves, leading to the issue after each layer. Moves whithin the layer are perfect, even at very high speed (>150mm/s)...

Edited 1 time(s). Last edit at 05/15/2013 03:54PM by fma.

---

Frédéric

I need some time to check that one. Much other problems in my queue.

disabling the motors and reenabling could really explain the problem. Depending on the microsteps, the motors can move back into a more stable position when disabled causing a larger move when it gets reenabled. On the other side xy should not get disabled during print.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thanks for your answer.

BTW, I tried to reduce the acceleration (500mm/s², inseatd of 2000mm/s²), and it is better. But slower!

What are the standard values for all the speeds/accel/jerk and so? I also may have a bad combination...

---

Frédéric

I also have sometimes a sound I do not really like during z changes. Always thought it was the z axis that causes it when started. After reducing Speed to 250mm/s and with Acceleration 1000mm/s I have at least no lost steps. I will try to test if you combination z-move then y move can cause this consistently. When I can get my printer to do it every time debugging the source is much easier. Especiall since I'm not sure if it is hardware or software related.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Mmm, I may have said something wrong. In fact, the noise comes from X axis, but the shift problems occur on Y!!!

Could it be a timing problem in the step generator or something? I have no way to monitor signals going to stepper amplifier...

I will also give a try to last firmware version, as soon as I have time.

---

Frédéric

Just checked with v0.82.2: same problem.

I made some scripts to tests params. First script:

G90
G1 Z5 F150
G1 X25 Y25 F15000
G91
G1 Z0.1 F150
G1 X100 Y100 F15000
G1 Z0.1 F150
G1 X-100 Y-100 F15000
G1 Z0.1 F150
G1 X100 Y100 F15000
G1 Z0.1 F150
G1 X-100 Y-100 F15000
G1 Z0.1 F150
G1 X100 Y100 F15000
G1 Z0.1 F150
G1 X-100 Y-100 F15000
G1 Z0.1 F150
G1 X100 Y100 F15000
G1 Z0.1 F150
G1 X-100 Y-100 F15000

Second script:

G90
G1 Z5 F150
G1 X25 Y25 F15000
G91
G1 X100 Y100 F15000
G1 X-100 Y-100 F15000
G1 X100 Y100 F15000
G1 X-100 Y-100 F15000
G1 X100 Y100 F15000
G1 X-100 Y-100 F15000
G1 X100 Y100 F15000
G1 X-100 Y-100 F15000

With the first script, the problem is easy to see (ear!). Accels above 750mm/s² don't work. With the second script, you can increase the accel up to 3000mm/s² without any problem.

Could it be related to jerk computation? Is it used when starting a move from speed=0, or only when changing direction?

Also, I think there is a missing param: a start speed (I assume you start from 0 for the ramps)? At work, our motor controllers always have such param, and it is really usefull, to limit the acceleration without limiting the overall travelling time. Without it, if the acceleration needs to remain low, because of inertia, it takes too long to reach full speed. Most of the time, you can start at speed >>> 0.

Edited 1 time(s). Last edit at 05/17/2013 02:57AM by fma.

---

Frédéric

Just tried to test it on my printer, but it failed due to other problems. So tomorrow next try.

Start speed is jerk/2. I double checked the jerk computation and it looks ok. The only part that might cause it is the z-switch, but I have to think about that formula and how it could influence the jerk. More tomorrow, when I get the same problem with your script.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Ok, for the start speed; I understand why increasing the jerk (~200-300) was helping! But then, the standard jerk computation was leading to bad movement.

So, I think this is the issue: we need a start speed param which can be set much higher than jerk/2.

I can give this idea a try: can you point me in the code where you compute this start speed? I will try to put a start speed not from jerk, to see if it solve the problem...

Thanks!

---

Frédéric

Can you confirm the start speed is computed in the safeSpeed() function? Is it OK if I do:

inline float safeSpeed(PrintLine *p) {
    float safe;
    #ifdef USE_ADVANCE
    if((p->dir & 128) && printer_state.isAdvanceActivated()) {
        safe = min(p->fullSpeed,printer_state.minimumSpeed);
    } else
    #endif
    safe = min(p->fullSpeed,max(printer_state.minimumSpeed,printer_state.maxJerk*0.5));
#if DRIVE_SYSTEM != 3
  if(p->dir & 64) {
    if(fabs(p->speedZ)>printer_state.maxZJerk*0.5) {
      float safe2 = printer_state.maxZJerk*0.5*p->fullSpeed/fabs(p->speedZ);
      if(safe2&ltsafe) safe = safe2;
    }
  }
#endif
  if(p->dir & 128) {
    if(p->dir & 112) {
      float safe2 = 0.5*current_extruder->maxStartFeedrate*p->fullSpeed/fabs(p->speedE);
      if(safe2&ltsafe) safe = safe2;
    } else {
      safe = 0.5*current_extruder->maxStartFeedrate; // This is a retraction move
    }
  }
  safe = 100;  // <<<<<<<<<<<<<<< Force start speed here >>>>>>>>>>>>>>>>>>>>>>>
  return (safe&ltp->fullSpeed?safe:p->fullSpeed);
}

---

Frédéric

Yes, the start/end speed is computed in that function. But if you think 100mm/s is a good start speed I must ask what kind of printer you have and what you jerk is?

I have a first theory I have to prove, what your clack sound is. xy speed and z speed are considered separately. So if a move comes with 250mm/s and jerk is 40 it is allowed to stop with 40mm/s. Then you have the tine z switch of 0.1mm and then you go back starting again with 40mm/s. If you didn't have the 0.1mm z it would be a 180° turn with a jerk of 80. So if delta z is too small, it can be the like the double jerk instead of a single jerk and that is what you hear. If you would reduce jerk to 50% it should go away. That said I will now repair my printer and test myself and if 'm right I need a solution reducing jerk to 50% if z move is included without doing it for normal autolevel moves, which is the difficult part.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

My printer is an ORD Bot Hadron.

In fact, the problem only occurs with travel moves, which are very fast (250mm/s). My above tests use this speed, and I found that increasing the jerk reduces the problem (starting from null speed after a Z move).

But with a high jerk, the 180° turn does not work anymore (I can clearly ear that the motor looses a lot of steps).

Ok, during printing moves, I can't start at 100mm/s; I think it is too high. The hack is just to see how the start speed computed from the jerk changes the problem.

I will check tonight when the problem occurs, depending on the last move (Z or not, and how much Z moved)...

---

Frédéric

I'm currently testing on my ord bot hadron and have the same problem. So it moved quite a bit forward on my todo list :-)

Reducing jerk to 50% didn't help. Seems more like a problem with starting speed beeing zero. That causes mathematical problems in the timing. But I'm still investigating what exactly is going on.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

I tested the hack as shown above, but it does seem to change anything, whatever the value I use...

BTW, I was able to run the second script with speeds up to 500mm/s and accel ~5000mm/s² Ok, the tork falls dramatically, and as soon as I touch the bed, the motor looses steps...

---

Frédéric

Ok, found a fix and the sound is completely gone now. Please update to 0.83. Configuration.h is the same as in 0.82.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thanks! I'll try that ASAP...

---

Frédéric

Yes, yes, YES!!!! Great job! I can now print faster than ever

Keep on doing such good job!

Edited 1 time(s). Last edit at 05/19/2013 02:24PM by fma.

---

Frédéric