1HCL probing problem with ***video***

HighFreq

@Phaedrux do you have any news by any chance? We are basicly unable to go forward with the printer because of the problem we are encountering in probing with 1HCL.

dc42

@highfreq are all four Z motors doing the same?

HighFreq

@dc42 Yes the entire gantry jumps up on all 4 corners.

dc42

@highfreq I've tried to reproduce this on a bench system with a single Z motor, but I don't see that issue. The behaviour is the same in open and closed loop mode. The only issues I saw were:

The maximum motor speed is lower in closed loop mode than in open loop mode. With microstepping set to x16 and Z steps/mm set to 4000, the maximum speed in closed loop mode is about 200 mm/min. That's equivalent to 133kHz step rate. This isn't unexpected, because the PID loop runs at between 9740 and 17045 Hz, and the maximum the motor can be commanded in one PID cycle is one full step.
If I run some tests in closed loop mode, change to open loop mode to run more tests, and then change back to closed loop mode, the motor no longer moves. Re-running my tuning macro makes it work again.

To set up for testing I do this

Set up the motor in closed loop node and run basic tuning
Send G92 X0 Y0 to pretend that X and Y are homed (because I am running on a bench system)
Configure a Z probe with dive height set to H0.1

The test I run is:

Send G1 Z20 F200 G30. After it completed the G1 move and starts the probing move, press the Z probe switch.

PS - if I create a homez.g file containing just a G30 command, then when I press Home Z in DWC it also works correctly.

What command are you running to provoke the error?

HighFreq

@dc42 i do G92 x0 y0 to home x and y than i run G30 and press the z probe switch than it jumps.
I don't send any G1 i just send a G30 while the switch is 30mm above a carton box and wait for the switch to hit the box.

I have a dive height of 5mm, could it be the problem? Should i try 0.1mm? To be honest i didn't understand what dive height really is.

dc42

@highfreq I only reduced the dive height so that the motor moves back up less when the probe triggers, so that I can more easily see how far the motor shaft rotates.

I am running a slightly different version of MB6XD firmware from the standard one. I don't think it should make any difference, but I suggest you try it anyway. Here is is. To install it, upload it via DWC. After installation, M115 should return:

FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.4.2+ ELECTRONICS: Duet 3 MB6HC v1.02 or later FIRMWARE_DATE: 2022-09-16 15:25:37

Duet3Firmware_MB6XD.bin

dc42

@highfreq I am trying to reproduce your configuration more accurately.

When you run the G30 command, is the Z axis showing as being homed already, or not?
What is in your homez.g file?

HighFreq

@dc42 thank you for your help, i am out of office now, will test everything tomorrow and will send you files.

dc42

@highfreq tomorrow is a public holiday in UK because of the Queen's funeral; however I may be online some of the time.

HighFreq

@dc42 I am trying updating firmware from web interface, it says i am running sbc and update only if adviced from developers i click yes but m115 command always shows old version.

Is there another way to update if running trough raspberry?

HighFreq

The video shows only one of the z axis during a G30 command, please turn on audio with phases description.

https://share.icloud.com/photos/06cU8ELrfs-zCSDhG1GmE0kaw

We are really at a loss now, we do not know where to look, if we configure our X axis as Z (it uses a different motor driver) probing works as expected with first touch than back than second touch than back. Using 1HCL it never works, not in open nor in closed loop. It is probably a configuration problem on our side but we do not know where to look.

One other thing, if we issue a G1 Z20 F200 G30 , he G30 is ignored, machine only execute the G1, if we issue two G1 commands on same line it executes them.

HighFreq

@dc42 I think we understood where the problem is. Between first and second touch of the probe the axis goes back to whee the G30 started.
As i understand after first touch should go back by the amount set in the dive, instead it goes back more or less where the g30 started, so if i start a g30 200mm above bed, when it touches the bed the first time it goes back to 200mm above and it starts the second touch.

Basicly i think there is a bug on how it handles backup between first ad second touch when in closed loop.

In open loop it works it seems but between first and second touch it emits a beeping sound, maybe it would go back like in closed loop but being in open it skips steps and looks like it works?

JoergS5

This post is deleted!

HighFreq

@joergs5 would you mind let the thread follow what the real problem is and not a simple answer i gave to the developer that used that commands in his tests?

JoergS5

This post is deleted!

HighFreq

@dc42 can you give us any help please? we are pretty much at a loss.

thanks.

HighFreq

@dc42 the problem we have looks very much like

https://forum.duet3d.com/topic/27248/3-4-rc1-1xd-probe-problem-after-update

Is there any chance you reintroduced the bug in following releases?

HighFreq

@dc42 we tested the firmware in the thread i mentioned but it does exactly the same. It keeps jumping back after first touch.

We have been trying pretty much everything in the last days, a sign of life on your side would e nice

As it is now is unusable, i am wondering if it is us or simply nobody uses multi z axis on 1HCL yet.

HighFreq

@dc42 @Phaedrux we attached an external driver to drive one of the z axis, if we drive it directly from the 6XD using step and dir the axis works with no problems, if we drive the external driver using a 1XD (the 1XD gives step dir commands) trough canbus than the problem shows up again.

It looks like there is a problem when using canbus.

Please let us know if we are going to get any help/attention or not because the machine can't be operated at the moment and we need to know how to solve.

thank you very very much.

p.s. we can do whatever test needed to give you as much informations as possible.

HighFreq

@dc42 @Phaedrux We scoped step output of G30 and it is way different if direct on a 6XD board or on a 1XD board driven by canbus.

The two step sould be exactly the same but they are not, when scoped on a 6XD it is clean and G30 works, if scoped on a 1XD right after the first touch there is a ton of rubbish.

Maybe is not rubbish and is there for a canbus timing reason but if devs don't help us out we can't go any further.

I am wondering how other users manage G30 using canbus connected boards, maybe nobody using 1HCL because it does not work at the moment.

I am very very surprised devs do not come back to us for a blocking problem like this and can't even reproduce it.