Crash Z-Axis after placement for a while

[Joerg]

Hello openpnp members,
I have a problem with my PnP machine.
The machine places components very precisely and quickly, but:
The Z axis stops at some point...
With the same assembly job, around 149 of 298 components, the Z axis stops with the nozzle at, for example, -14.9mm !
The crazy thing is: I can reproduce this, and then, of course, it crashes.
I've broken a lot of nozzles by now.
I've seen the Z axis freeze elsewhere as well.
There was even a case where the job ran through...

I've been working on the T2 machine for a while now here
The firmware in the controller is from China: fly cdy v3 China
Detected Firmware: FIRMWARE_NAME:Marlin bugfix-2.1.x (May 21, 2024, 4:47:06 PM)

I think I should replace the controller and install the Duet 3 mini 5+.
The X and Y axes each have a closed-loop motor and never had done wrong. 
The Z axis doesn't have a loop, but as far I now it is not a bad idea to do so.
The A axes aren't doing anything stupid as well, at least that's how it looks at the moment.
The log file, I shortened it; I didn't want to upload the 148 components...
I can't go any further now.
Maybe someone can take a look at the log file.
I'm grateful for any help, but I've now ordered the Duet controller,

best regards, Jörg

[Jan]

Hi Jörg!
According to your log, there are a lot of z-motion commands like G1 Z0.11 even very close to the end and this commands are acknowledged. That looks as if the controller has received them. So he is either not processing them (unlikely) or there is a motor driver issue or the motor is loosing steps. Did you checked that already? Did you tried to run the job slower?
Feedback on z axis is probably a nice feature but some commercial setups use the homing switch (with homing in the up position) for that. That's cheaper and works well because the z axis is very often in or close to it's home position.
Jan

[Joerg]

Thanks Jan for your quick reply.
I also suspect that for some reason the controller is no longer processing the Z commands, even though it acknowledges them.
The X and Y axes are equipped with closed-loop motors and external servos, and they're running well.
It can't be a step loss; the Z axis places the components very precisely – until it just stops. There are only these two states.
If I run the job at 100% (pretty fast for the small machine), the error doesn't occur!
But I've only tried that once. It could be a coincidence.
There have been several crashes outside of the job described here.
Do they measure the motor current on such a board ? 
I don't know what's wrong with the controller, or with the STM-32 setup/firmware .
I saw that the controller doesn't have a WiFi module, even though the board isn't available without WiFi .
This could mean that someone in China desoldered the WiFi chip – in which case, such overflows are conceivable...
So what:
It's important for me to know that there are no bugs with the OpenPNP software that fulfills this scenario.
Since the software is apparently cleverly and meticulously programmed, I would also be surprised to find a bug at this level...

Maybe I'll replace the Z-motor with a closed-loop motor.
But the closed-loop issue is certainly overrated.
I'm installing the Duet board now, which will take some time.

Two more things:
I've removed the Advanced Motion Planner.

That doesn't change the error !

Should I use the GcodeAsyncDriver?
RepRap version 3.5 on Duet 3 Mini 5+

 

Jörg

[Toby Dickenson]

With the same assembly job, around 149 of 298 components, the Z axis stops with the nozzle at, for example, -14.9mm !

Does it always stop after doing some work? That could be a thermal shutdown. Can you temporarily point a fan at the z stepper controller?

 

The crazy thing is: I can reproduce this, and then, of course, it crashes.

If you can reproduce it, then you can debug by investigating what fixes it once in that condition. Moving a connector? Cooling? Power cycle? At this point I would ignore openpnp; that is a complicated black box that can only add confusion. Sending single gcode commands to move the z axis should have an unambiguous effect.

 

[Joerg]

Dear Tobi

I've just observed this again and have seen the following:

While a Job is running 

1. The head had loaded two components at N1 and N2, but didn't execute any Z-moves to place them.

2. The head then moved to the stop for N1 

Probably the following move to Safe Z but the Z axis is not at -14.5mm. 
So the crash happens.

3. With the nozzle N1 lowered to the stop, the machine continues to run!  (No nozzles present, not a big  problem).
4. I press Pause, and the program stops.

I have now try to send G codes in the driver's console:  G1 Z -1 F6779

The nozzle moves to the Z value, but Z Home is no longer correct due to the previous crash.
Park in the OpenPNP controller works the same way, but not does a Home z.
So Openpnp acts as normal.
This is the scenario, it happens after a while placing. 
I assume the controller isn't executing a Z command, but confirms them.
Yes thermal shutdown ... Bad wiring... or the missing Wifi Module and a floating input Pin on the Contoller ???
Did they have secured this in their firmware - Missing Wifi ?

Single commands on the console  and a fresh RepRap 3.5 at the Duet is my goal - 
thank you for this advisory 
Jörg

[Jan]

Hi Jörg!

On August 19, 2025 9:01:52 AM GMT+02:00, Joerg <joerg.f...@ed-fichtner.de> wrote:
[...]

>There have been several crashes outside of the job described here.

That's a common "feature" while setting up and tuning a machine and provides good indication for improvements.

>Do they measure the motor current on such a board ?

I don't know. As is written in all setup guides, OpenPnP relies on a working controller, driver, motor and hardware setup. I've seen a few setups where where one or the other component was weak and required a replacement.

[...]

>So what:
>It's important for me to know that there are no bugs with the OpenPNP
>software that fulfills this scenario.
>Since the software is apparently cleverly and meticulously programmed, I
>would also be surprised to find a bug at this level...

The log file provides a good starting point for gebugging. OpenPnP is like every other software never guaranteed bug free. However the core is very good and in most cases issues caused by other components. Raising them here is always a good idea for others to learn from and to verify that there is really no underlying bug left.

[...]

>I'm installing the Duet board now, which will take some time.

That's a rock solid base and well supported (by OpenPnP and the maintainers).

>Two more things:
>I've removed the Advanced Motion Planner.
>That doesn't change the error !
>
>Should I use the GcodeAsyncDriver?
>RepRap version 3.5 on Duet 3 Mini 5+

Both are (IMHO highly) recommended because they provide features for higher machine performance but applies more stress on the controller. Duet (and others) can handle that very well.

Jan

>>> <https://groups.google.com/g/openpnp/c/9pVffXp2D2Y/m/_chHoLjkCQAJ?utm_medium=email&utm_source=footer>

[Joerg]

Hi
I meanwhile have running openpnp the Duet 3 Mini 5+ Board , and the Z-Crash is gone.
It workes perfect , and I´m now able to do my own setup.
I have seen that the Crimp contacts on the Z-Motor and all others was crimped very poor or not at all. 
Instead the chinese put hotglue on all the Plugs on the FLY CDY Board. 
What ever ...
I  will change to the GcodeAsyncDriver, and recalibrate the machine.
Thank you Jan and all here ...
Regards