External Drives and Layer Shifting
-
I have a largish 3d printer that I am fine tuning. (4 independant print heads, 420mm x 420mm print area, proper ballscrews for Z and Belts for Y, X, U, V & W). I chose a while back to use closed loop steppers to try and make the machine a little quieter, and hey, closed-loop control is better than open-loop, right?
I chose a a 2HSS57 driver and matching motor from JMC-driver.com (bought on AliExpress). Every looks very good and seems to work just fine. Except when I go to print. I get wobbly layers that are not regular or consistent at all. Be fore anybody starts in on me, I have done the following to checkout the mechanical system.
-Frame is sturdy and connected firmly (all structural aluminum extrusion)
-Adjusted tension on all the belts (all axis have independent tensioning)
-Confirmed free and easy movement of carriages and hotbed
-confirmed no play in the hotend itself. Hotend does not move when shaken.
-removed bearings at the top of ballscrew to mitigate any Z-Wobble.
-Printed with hotter and colder extruder temps
-printed with hotter and colder heatbed temps
-taken apart machine to check for bent ballscrews/linear guides (guides are beefy 12 and 16mm linear shaft)
-verified all the steps/mm are correct
-slowed everything (Accel, Jerk, Max Speed) way down and am printing at 30mm/sec, 245 deg nozzle, 90 deg bed and material is ASA (I love the ASA, i use it in my other printers - for anyone who hasn't tried it, please do)I can't seem to find any issue with the mechanics of the system.
So on to the electronics. I've emailed the techsupport for the drives as i am concerned that the position feedback loop is not tuned properly for this system. Notice from the pic that the shifted layers are not always severe.
One other issue is the step and direction signals from the duet. The picture below shows my scope hooked up to the STP and DIR pins for the Y axis. Notice how they start and stop at the same time. From the manufacturer's note, the DIR signal needs to be on at least 6 usec before the step pulse. Is there a way to get the duet to output this type of timing? My thought is that every time there is a direction change, i may be moving the wrong direction. Over lots of moves, maybe this is adding up? It's just a theory, I thought i'd throw it out to the group as I am grasping for straws here.
I am ordering a couple straight NEMA 23 steppers to replace X and Y and at least eliminate the rest of the mechanics and the printer/slicer settings as a problem.
Any other ideas?
-
Hi Doug
I assume you have seen this:
https://duet3d.dozuki.com/Wiki/Gcode#Section_M569_Set_axis_direction_and_enable_valuesThe T parameter allows you to set the minimum pulse width. so try 3 as your drivers say they need a minimum of 2.5
That does not fix the issue with needing 6us after a direction change, I do not believe the current firmware allows for that but David will no doubt confirm when he sees this thread.
-
I currently have the T parameter set to 10 for good measure. It has been 10 since i setup the firmware a month ago.
Thanks
-
Right, well that direction lead looks a likely candidate
-
Your driver wants negative-going step pulses, whereas the Duet provides positive-going step pulses. So you will need to invert the Step signals. If you are using the Duet external stepper driver breakout board, you can exchange the STEP+ and - connections. If you are driving them directly from the expansion connector, connect STEP+ to +3.3V and STEP- to whichever STEP pin on the expansion connector you are using.
-
I am using the breakout board.
I have done as suggested and the results are that the print is still shifting but in the opposite directions as before. 3DBenchy was printed in the same orientation and print settings as before. The good news is that this does represent a change. I have been messing with this and getting the exact same results every time i do it.The bad news is that I don't know what it means and I fried one of the logic converters on the breakout board attempting to hookup both the step and direction to get a chart on the oscope to show. I inadvertently connected 5v to ground. Whoops. I'll be ordering another shortly. It looks like the controller is fine though, as the other axis move. If I swap X & Y to U they move too, so drives are okay.
Back to the original problem, Why has the distortion mirrored itself in the Y axis? I believe the following to be correct now that the step + and - have been swapped
Could I now be moving the last step an incorrect direction based on the direction signal going low at the same time? I have to believe that the distortion is somehow related to the drives as the distortion (shifted layers) changed direction once the step polarity was changed. Looking at the manufacturer chart, should i have swapped the direction polarity too? wouldn't that just give the same response with them both hooked up the initial way?
-
I am puzzled by your scope trace, because the Duet never changes the Step and Dir signals at the same time. If you have T6 in your M569 command then there should always be at least 6us between Dir changing and the leading edge of the Step pulse.
However, the Duet does change the polarity of Dir signal before the end of a step pulse. My guess is that your drivers don't like this. Other drivers only care about the value of Dir at the leading edge of Step.
-
I wander what mhallett's experiences were with the 2HSS57 drivers. I take it, he had a similar setup at some stage. I have a pair of closed loop 2HSS57 drivers and steppers. It will be a shame if they will not work for me….
-
I have changed the code in 1.21RC3 so that when using external drivers, the step pulse is ended before the direction signal is changed.
-
Alright, I've got some logic level 3.3V to 5V converters. I'll try to "fix" my x and y axis to to bypass the burnt out optocouplers and give it a try.
I also heard back from the manufacturer of the drive. They have asked me to try and go from 1600 pulses per revolution to 3200. I don't think it will fix the problem, but it should make it less noticeable. I'll try that on a second run and see if I get any improvement.
Thanks, I'll report back.
