Zprobe dual Zdrive behaviour?

[Kristian Wall]

Hi Arthur

Something weird happens when I try to use my new Zprobe. I command a probe with G30. This works as expected, up until when the board goes to raise the extruder back up to the initial position. At this point it only drives one of the two Zdrives so the whole x carriage gets out of shape, pretty alarming!

My printer is a I3 type. I am using all the stepper drivers on my smoothieboard, so the two Z steppers are driven by their own drivers.

The z drive behaves fine normally. It is just when it is withdrawing from a Zprobe that only one motor is being driven. Is there something I need to alter in the config? Or is this something in the code that needs to change?

I am hoping my config file (Link at the bottom) will give some clues? I have been printing with this setup for a few years now. But adding the zprobe yesterday now appears to be a problem.

Hopefully this may help others with a similar problem?

Regards

Kris

https://pastebin.com/3HRcRWTv

[Arthur Wolf]

Please decouple the Z motors, and see if/how they each turn when doing a G30 and the other commands you did that had the issue.

Once we know we might be better able to help.

--
You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smoothieware-support/948da30c-edc4-4792-9574-aa1cc4c3c983o%40googlegroups.com.

--

勇気とユーモア

[wolfmanjm]

it has to be a h/w or wiring issue, as the firmware doesn't even know there are two drivers for Z, as they will be wired up externally. I suspect one of the motors is either binding or has a wiring issue.

[Kristian Wall]

Thanks Authur

I agree with that it is most likely HW issue. Interestingly the stepper that does not drive on the withdraw command is the farthest from the board, so longer cables.

The zprobe.slow_feedrate was set to 5mm/s, so the default return feedrate would be at 10mm/s. My gamma_max_rate is set at 300mm/min (or 5mm/s) so there is a conflict here.

My printer is still running on standard M5 studding and spring loaded nuts for the Z axis, so not ideal. I have slightly increased the gamma current to give the steppers a bit more power. I have also reduced zprobe.slow_feedrate to 3mm/s and manually set the

zprobe.return_feedrate to 5mm/s. This should avoid the conflict mentioned above.

I won't have time to test until later, but I will update you on the results.

Thanks for responding so quickly to my request for help.

Regards

Kris

[wolfmanjm]

If you are using a separate driver for the second Z motor I do not see that you are setting the current for that driver.

If you were using the 5th driver for it that would mean you need to set epsilon_current for it. Right now I suspect you are not providing enough current for it. (Look at the M503 output to see what current is set for what driver). Setting gamma current ONLY sets the current for one of the drivers (the gamma driver).

[Kristian Wall]

Sorry Arthur

I missed this coming in. I have been testing, and have come to the conclusion (like you too) that there is not enough current going to the second Z drive.

Your reply makes me very hopeful I can fix this problem. Up to now I have been ensuring that the Z axis is well lubricated and operates smoothly. Normal Z movement of the X carriage is fine with no sign of skipped steps.

But retaction from Zprobe actions appear to use higher step rates and this, coupled with the small diameter, fine pitched M5 thread put a high demand on the stepper...... I was still confused by why this only affected the further (second) Z drive though....

So your latest post is very useful! I had been wondering how the config script configures the fifth driver to operate the second Z drive? After all, this drive could be used for an additional extruder if required......

So I have a definition for one gamma drive....... Do I just duplicate this? and then rename to epsilon so I have two drives defined for the Z axis?

[wolfmanjm]

You disable ALL pins for the epsilon drive EXCEPT the epsilon_current which must be set (proibably the same as gamma_current). The driver is being driven externally by the jupers from the gamma drive to the epsilon driver as per the wiki, so the epsilon pins need to be disabled otherwise they will fight the gamma driver pins. the current however must be set. The firmware knows nothing about the fact you are using two drivers to drive the Z as they are wired externally by those jumpers you added between the gamma and epsilon drivers.

[Kristian Wall]

Problem solved!

Thanks Arthur. As you said, I had not setup the current for the second (epsilon) Z drive. So the current for the second Z stepper  limit was set at the (conservative) default. The printer had been running OK like this since the initial setup (Three years ago) but I was having to re calibrate the height of the x carriage quite often. So in hind site, this would have been down to the second drive skipping steps occasionally when being driven hard.

My recent attempts to try out Z probing exposed the problem when the high Z return rate from the probe put a high load on the Z steppers.

Thanks for all your help Arthur, very much appreciated.

Best regards

Keis

[Arthur Wolf]

On Mon, Jul 27, 2020 at 8:41 AM Kristian Wall <spud...@gmail.com> wrote:

Problem solved!

Thanks Arthur.

That was wolfmanjm not me.

--

You received this message because you are subscribed to the Google Groups "Smoothieware Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smoothieware-sup...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/smoothieware-support/2f3a616d-e313-4b1a-b6ac-90e0f2d5add0o%40googlegroups.com.

--

勇気とユーモア