Potential firmware issue - bltouch

Phaedrux

If it deploys and retracts fine before moving, but not after moving, that makes me think it's the moving that is causing a loose wire or something.

Instead of homing X and Y can you turn the motors off and then gently position the print head by hand and then send G30/M401/M402 to test if it's a positional problem?

If you need to force it to be homed first send G92 X100 Y100 Z100 to trick it into being homed.

dc42

@alex-cr, it's also worth running M558 without parameters, to check that the BLTouch is properly configured on the correct input pin as probe type 9.

Alex.cr

@dc42 said in Potential firmware issue - bltouch:

@alex-cr, it's also worth running M558 without parameters, to check that the BLTouch is properly configured on the correct input pin as probe type 9.

It looks like it has taken most information correctly. Should it return "output pin nil" ? I can't find any info for this.

Alex.cr

@phaedrux said in Potential firmware issue - bltouch:

If it deploys and retracts fine before moving, but not after moving, that makes me think it's the moving that is causing a loose wire or something.

I was thinking wiring as well at first but no matter how I move my probe, as long as I don't use my homex/homey or homeall programs I can get the probe to deploy using M401. I even faked the endstop locations so the homez G30 move was not in the center of the bed and no dice.

Instead of homing X and Y can you turn the motors off and then gently position the print head by hand and then send G30/M401/M402 to test if it's a positional problem?

If you need to force it to be homed first send G92 X100 Y100 Z100 to trick it into being homed.

The probe will deploy after the G92 line to home it. No matter where the head is, no matter how far it has moved.
I ran a run-in program to exercise the wiring. I homed XY using the home commands and no luck with G30. In the same exact X and Y position I fire G92 X100 Y100 and it will deploy the probe after that.

Alex.cr

@dc42 @Phaedrux

So I got out an oscilloscope to measure the and watch the signal coming from the duet to the Bltouch. The Duet is doing what it is supposed to do, when its supposed to do it. Now I have to figure out why the Bltouch chooses not to respond only during homing commands. I rewired the whole device, temporarily removing as many plugs from the setup as I could and still have the same issue.

Thanks for the help. Disregard my initial concerns.

jay_s_uk

@alex-cr

if it works when the motors aren't energised but fails when they are then one of the motors is generating some electrical interference thats interfering with the signals from the duet.
I would suggest as a first step, changing the wiring on the bltouch so the cables running to it don't run by anything else. if that works then look at changing the routing of your cabling or shielding your motor cables

o_lampe

@alex-cr said in Potential firmware issue - bltouch:

Now I have to figure out why the Bltouch chooses not to respond only during homing commands.

Did you check the 5V rail after homing XY? Maybe it is pulled low because of some endstop issues?

Alex.cr

@jay_s_uk said in Potential firmware issue - bltouch:

@alex-cr

if it works when the motors aren't energised but fails when they are then one of the motors is generating some electrical interference thats interfering with the signals from the duet.
I would suggest as a first step, changing the wiring on the bltouch so the cables running to it don't run by anything else. if that works then look at changing the routing of your cabling or shielding your motor cables

It works while the motors are running/energized. If I fire G92 X0 Y0 and then fire G30 it works great, regardless of where it is located in the travel. It only does not work after running any of the home.g files. This is why I thought it was a firmware issues to start. Thanks for the suggestion though. See my O-scope results below.

I also ran cables outside of the cable chains to test and have the same result.

@o_lampe said in Potential firmware issue - bltouch:

@alex-cr said in Potential firmware issue - bltouch:

Now I have to figure out why the Bltouch chooses not to respond only during homing commands.

Did you check the 5V rail after homing XY? Maybe it is pulled low because of some endstop issues?

Good thought. Here's my analysis for that.

I did check the 5V rail after running homing commands. It shows 4.8xx volts using my Fluke 117 meter. So I decided to break out my oscilloscope and see what I could find. With the exception of the ground, the scope is hooked up as close to the Bltouch as I can manage.

This first image shows what the M401 command looks like without any motors on, probe did deploy successfully. Yellow is the signal to the Bltouch and blue is the 5v rail.

Notice the difference in vertical channel heights in the upper left hand corner. The yellow peak to peak voltage is about 2.93 volts. The blue peak to peak voltages at this state are about 10-20mV.

The next image shows the oscilloscope while performing a homeall.g command at the point when the G30 has fired to home the machine in Z. The probe did not deployed here. Same voltage peak to peak for the Bltouch signal line. The Bltouch was getting the correct command. In fact the parameters at the bottom of the screen for channel 1 show very little change.

The 5v rail only shows about 200mV peak to peak now. So a bit of noise but nothing I would consider major. In fact both rails show the same about of "noise" in them. It just looks way worse for the 5V rail because of the vertical resolution I had everything set to.

Does 200mV of noise in the 5V line really something to shake a stick at? I guess its time to see what my other printers are running into.

Phaedrux

Only thing that sticks out to me is that you define the probe as K0 but only have a single probe. Can you try removing the instances of K0?

You're also using G54 in your homez. Why is that?

Alex.cr

@phaedrux

I will have two other coordinate systems defined. G59.1 and G59.2 for nozzle cleaning and a nozzle height probe. My hope is to get another stationary probe running on K1(hence the bltouch being defined as K0). If you see I have my nozzle height sensor commented out at this time in my config, right below the bltouch setup. So every time a sub is called where the program needs to move to a specific point i want to make sure the proper coordinate system is called, this is why G54 is called as it will be the standard work coordinate system. This is very similar to how I have my work CNCs setup. I was hoping to follow "similar" systems.

I have removed all instances of K0 and K1 in my config and still have the same issue. I will try commenting out G54 and see if that helps. I am really hoping to be able to use the coordinate systems though so lets hope that doesn't fix it...

I have purchased another bltouch and it it on its way. I also have a shielded wire bundle on its way as well.
I am at a loss at this point. I don't think the Duet is doing anything wrong as it is very clearly sending the proper commands.

o_lampe

@alex-cr
There is a missing semicolon, might cause some irritations?

M592 D0 A0.0 B0.00 L0.2                            ; Nonlinear extrusion Tool 0
;M593 F34.48                                        ; Cancel ringing

 

Work Offsets:      <= HERE
G10L2P1 X0.0Y0.0Z0.0  ;Set G54 offset to be machine coordinates
G10L2P7 X0.0Y0.0Z0.0  ;use G59.1 for tool height probing Z zero is top of the setter when not pressed
G10L2P8 X0.0Y0.0Z0.0  ;use G59.2 for nozzle cleaning, center of brush, top of brush

Wouldn't it make more sense to check CAN-bus right after 'M80' in config.g?

 

; Miscellaneous  <= very late in config.g?

M115
M115 B1										   ;Check status of Can-FD exansion board

Alex.cr

@o_lampe said in Potential firmware issue - bltouch:

@alex-cr
There is a missing semicolon, might cause some irritations?

Nice catch! unfortunately it did not make a difference. It also never triggered an error when running an m98P"config.g" so that's interesting.

Wouldn't it make more sense to check CAN-bus right after 'M80' in config.g?

This is mainly for me to be able to easily see which firmware is running on the boards so I can double check that they match. But not a bad idea.

Alex.cr

I have singled down the issue to stepper noise. I have never had this problem before even on similar machines with similar wire runs. Now to figure out how to solve this...

Phaedrux

Do you have your steppers grounded?

Alex.cr

@phaedrux said in Potential firmware issue - bltouch:

Do you have your steppers grounded?

They are not currently but I did install jumpers and grounded them and it had no effect.

I swapped the bltouch into another machine that is working and it worked great. A spare bltouch just showed up today but it is behaving just like all of the others.

Next step I am going to run a completely new harness for the bltouch that does not pass any of the stepper motors and see if I can get that to work. I also have shielded cable coming but I really hope I don't have to use that.

Nuramori

@alex-cr said in Potential firmware issue - bltouch:

M558 P9 C"0.io7.in" H5 A3 S0.005 F120 T9000 K0

This should have the pull up resistor enabled. It’s a commonly overlooked issue with bltouch installations.

Try this instead. Note the caret.

M558 P9 C"^0.io7.in" H5 A3 S0.005 F120 T9000 K0