Posts made by Shen

@dc42
Yes, I did allow a few second between M84 and re-enabling. I think this might be a driver issue. My Leadshine EM503 can be reset by M84 and re-enabling. I will probably just go with the re-wiring solution you provided.

@dc42
I'm using leadshine ES-D508. As far as I can tell, send M84 and re-enable does not reset the driver; emergency stop with ENA+/ENA- detached from the driver does not reset the driver; emergency stop with ENA+/ENA- attached to the driver resets it. I've connected a multi-meter to the ENA+ and ENA- of my driver, when I press the emergency stop bottom the multi-meter does read 0v for almost a second. The only reason I can think of is the driver requiring 0v to reset.

When my external drive goes in to fault mode(I'm using it as endstop), it can be cleared by toggle the enable signal. The Duet Expansion Breakout Board output either 3.3v or -3.3v between ENA+ and ENA- which does not clear the fault. The drive requires 0v to clear. The workaround I found is to reset the duet board, during the process, the voltage between ENA+/- goes to 0v temperately which clears the fault. Is there a better way or workaround I can use to set the voltage to 0v?

I had exactly the same issue on my Leadshine ES-D508. I was using the Duet Expansion Breakout Board for my drivers. And I also noticed the layer shifting becoming less as I increase the micro step, which makes sense, the more distance a single micro step takes, the more layer shift it would cause if it's not recognized by the driver or if it stepped to the wrong direction.
I was force to use the integrated stepper drivers but would love to get the external ones working some day.

Try gcodeanalyser.com as well.

@phaedrux I’m running them at 2A.

@dc42
Thanks. I didn’t put E in the M584 command since I was just testing the xyz motion. That must be the problem.

https://youtu.be/wwUYVX4Vpjw
Here is a link to the video. It's easier to see the direction of the motors by looking at the couplers. The right motor would sometimes go in the wrong direction, and recover, and go wrong direction again. I'm using 2.0 firmware.

I'm building a custom machine for a customer on their new duet wifi board. I set M584 Y0:3 two use two motors on each side of the Y gantry. The two motors would be in sync if I just move the gantry around in the web interface, but when I run a micro or gcode which probably have a lot of Y direction changes, one of the motor(always the same one) would go in the wrong direction. When I move the motor from port 3 to port 1 and change only M584 Y0:3 to M584 Y0:1, everything runs fine as expected. Is driver 3 a faulty driver which doesn't receive or process direction signal reliably?

Ok, I found that if I lower the bed after the first G30 then the second G30 would work. Maybe the second G30 did not reach high enough speed? but then why would the second probe in the first G30 succeed? Strange...

Also I forgot to mention. This only happens when I set M558 A3 to probe three times, and it ALWAYS fail to trigger on the second G30. When I only probe once(M558 A1), it's successful every time.

@dc42
Here is the video showing 4 G30 executions. The first one is successful, the second one fails. After the second one I ran M84 Z to release Z motors so I can balance the bed. The third G30 runs fine, the fourth one fails again. It's always the second G30 that fails.
https://www.youtube.com/watch?v=n8dddFaQKXk

@deckingman
The point that video of mater make is that with the S curve acceleration, moving mass comes to a stop without oscillation. In 3d printer this would result in less ringing.
When I say “the distance nozzle overshoot on a 90 degree corner is usually between 0.05 and 0.1mm”. That is just referring to this particular print. If you print the perimeter slowly or have very low jerk acceleration, you may not see the overshot, but the overshot still happens. The print head along any an axis cannot go from 5mm/s to 0mm/s instantly, it will overshot more or less, it might just not be visible for you. This is backed up by physics. Just like you compensate the elasticity of filament by pressure advance, you can also compensate for the elasticity of xy motion.
I don't know why you are so against the idea of an different different motion system. You want to see real world test results before you believe but every time this is brought up you just strongly oppose the idea, and even an experiment build. This might work well, or it might not bring any improvement, but how do we know without testing?

I'm having a problem with stall detection as Z probe. Every time when I run two G30 commands in a row, the probe always fail to trigger on the second G30. However, I can run my homez.g script that uses stall detection as endstop as many times as I want, and it would always trigger.

The rounding of corners I proposed is on a very small scale just to counter the effect of flexibility and inertia. The distance nozzle overshoot on a 90 degree corners is usually between 0.05 to 0.1mm. So I won't only add a arc with that radius to just counter the overshoot, and while it does that it also proves a smoother motion. And the rounding compensation should be proportional to the acceleration experienced by the nozzle, so when you draw perimeter with a slower speed, the amount of compensation would be less.

First of all the graph is exaggerated. In practice it would be a much smaller amount. When you make a corner at a high speed, the nozzle would go over the instructed position, as in the picture below.

It compensate for that. Also I would imaging this work the similar to pressure advance, it would have a constant k to decide the amount of compensation, and the compensation is proportional to the acceleration the nozzle experiences. So when you print at slow speed, or when the cornering angle is small, the acceleration/deceleration would be small, which results in less compensation.

Also I can't agree with you that the controller should do exactly what the gcode instructed it to do. I my opinion, gcode is the theoretical motion path and speed, but in reality you have acceleration/jerk/pressure advance to try to compensate for physical effects and generate the best representation of the gcode.

@dc42
I think it might actually be better if you "deliberately change the motion path to be different from what the slicer specified in the GCode".

Instead of going along the black line as gcode instructs. It might be better to go along the red line. It will not only result in smoother motion, it might actually produce a better representation of the actual gcode path due to inertia of the print head. So basicly it's like a "pressure advance" for the XY motion.

@dc42
Is it possible to implement some kind of filter to equalize the time or rate of change of time in between pulses to some degree(parameter controlled). This will smooth out the small segments. My external driver has a feature to smooth out input signal between up to 0.0256 seconds. It makes a very noticeable difference in the sound the printer makes.

@Ret, For me there are workarounds to the problem. Such as slowing down perimeters, lower jerk/acceleration, but I don't know if you are willing to sacrifice the speed. I had to slow down to 2mm/s jerk and 1500mm/s^2 acceleration for the noise to go away, but before I switch to the internal drivers, with the filter function of my external driver I was able to achieve 10mm/s + jerk and 3000mm/s^2 + acceleration without any issue.

This would probably not work very well on deltas. If you use 5mm pitch screw with 0.9 degree stepper on Z axis, each full step is only 0.0125mm.