Config file with TAP. HELP!

[7milesup]

Background...  I'm a total beginner when it comes to configuration files because this is my first 3D printer build (other than a Prusa 2.5s that I "built").  

I am going nuts trying to figure out a z_offset issue when trying to update Klipper.  Here is what the ERROR states...  (sorry, I was going to do a screenshot but can't figure out how to do that either in a Linux ecosystem).

 

Option 'z_offset' in section 'probe' must be specified

Once the underlying issue is corrected, use the "RESTART"
command to reload the config and restart the host software.
Printer is halted

I followed the "Updating your Klipper config for Tap" instructions from Github BUT, I have no idea where or how the "PROBE_CALIBRATE" line is used.  

There are no values at the end of my config file because this error, and others that I have encountered, will not let the printer run.  I have attached my config file, which probably has a bunch of errors in it. 

Build is Voron 2.4r with Phaetus Rapido and TAP as the only non standard mods from the Formbot kit.

Help would be greatly appreciated. 

 

printer.cfg

[mvdveer]

Firstly, You had the [probe] section defined twice and though the z_offset is defined under the first [probe] heading, klipper read the second [probe] heading as well (the one you put the code for the TAP) and could not find the Z-Offset. I have rectified that in the attached file (rename it back to printer.cfg), but you can just remove the second [probe] statement. (Use the attach file as a reference)

3 hours ago, 7milesup said:

BUT, I have no idea where or how the "PROBE_CALIBRATE" line is used.  

There is no line in the printer.cfg for this, it is a command line entry. In your mainsail/fluid interface, you enter this command in the console/terminal window and it will then execute.

See here for further information.

Process:

1. Home the printer

2. In the terminal window type PROBE_CALIBRATE and press enter

3. Have a piece of paper ready to use under the nozzle after you have executed the command.

4. Change the nozzle position by using the pop-up box (Z- or - will move the nozzle closer to the bed. Z+ or + will move Z away from the bed)

You can see the probe in this case is 4.483mm above the bed. Using the controls I would -1 the probe x 4

and the probe is now 0.483 above the bed. Again , I will use -0.1 x 4 which will bring the probe to 0.083.

I will then use -0.01 x 8 which will put the probe at 0.003, etc

5. Move Z till as described above until the nozzle just grips the piece of paper. Click the accept button.

6. Save this position by typing SAVE_CONFIG in the console/terminal window. (This is your new Z-offset)

7. Your Z-offset will be saved in a section at the end of your printer.cfg file that will appear green and says Do not edit below this line:

#*# <---------------------- SAVE_CONFIG ---------------------->
#*# DO NOT EDIT THIS BLOCK OR BELOW. The contents are auto-generated.
#*#
#*# [probe]
#*# z_offset = -0.505
#*#

8. Fine tune / Babbystep this value from the console when printing to get the prefect first layer:

After the print, again type SAVE_CONFIG into the console/terminal to save the value.

 

Hope this is of benefit and helps

 

 

Secondly:- When the file says to comment out a section you do this be entering # in front of the line.

Need to comment out the Z_endstop in the [stepper_z] with a # in front of that line and not change it to 0. (I have done that in the attached file)

If you are going to use the attached file, remember to rename it to printer.cfg

If any other errors pop up, let me know

 

 

 

 

printer7miles up.cfg

[7milesup]

Awesome!  I will give it a try in a little while here.  Thank you!!

[7milesup]

@mvdveer  I uploaded your config file and now get the error "Unknown pin chip name "probe."

 

EDIT:  I just realized that my printer.cfg file does not have the serial number of my orange pi in it at the beginning.  I am not sure if that is an issue?

Edited February 6, 2023 by 7milesup

[mvdveer]

33 minutes ago, 7milesup said:

"Unknown pin chip name "probe."

Have looked at the file again and my apologies. When I removed the 2nd [probe] section it removed the original as well.

Have re-uploaded

33 minutes ago, 7milesup said:

I just realized that my printer.cfg file does not have the serial number of my orange pi in it at the beginning. 

Yes it will! You need to get the device id and enter that into that section - it is how klipper knows who to talk to so to speak.

You need to open a terminal to your orange pi by ssh

e.g ssh [email protected]

(Replace pi with the username you used and orangepi with the name you gave it during format) I do not know the orange pi, so I cannot be more specific.

 

It will ask for a password. Once you are connected, then issue the following command

ls -l /dev/serial/by-id/

It should return something like:

/dev/serial/by-id/usb-Klipper_lpc1768_1BF00011A90825AEF4722D52861E00F5-if00

Copy that and enter that into the spot where it says: {REPLACE WITH YOUR SERIAL} in the printer.cfg file

 

printer7miles up.cfg

[7milesup]

Uggghh.  Now I get the error...

Klipper reports: ERROR

Option 'pin' in section 'probe' must be specified Once the underlying issue is corrected, use the "RESTART".

This does not make sense to me because I have the probe pin identified as PG15 (line 315) which is what I have my Tap sensor plugged into.

 

 

 

[mvdveer]

3 minutes ago, 7milesup said:

Option 'pin' in section 'probe' must be specified Once the underlying issue is corrected, use the "RESTART".

My fault - sorry am at work and trying to help in between.

I hade the [probe] defined after the pin

Fixed it

 

printer7miles up.cfg

[7milesup]

@mvdveer Your help is very much appreciated!  

Ok, huge step... I now have a blue screen instead of a red screen.  Woot!

I had some other errors pop up but figured out that I need [include mainsail.cfg] in my printer.cfg file.  

WOW, a huge learning curve for me but cool!  I need to do all the homing yet but that might be a tomorrow to-do.  I have a headache, LOL.

Thank you for responding so quickly @mvdveer, especially while working.  

 

[mvdveer]

21 minutes ago, 7milesup said:

WOW, a huge learning curve for me but cool!  I

Part of the fun - happy to help

[smirk]

4 hours ago, 7milesup said:

I now have a blue screen instead of a red screen.  Woot!

 

As an IT person I find it strange anyone would celebrate seeing a blue-screen , however glad you're on the right track with @mvdveer excellent help.

[mvdveer]

28 minutes ago, smirk said:

seeing a blue-screen

I remember the "blue screen of death" on the early windows based machines.. Just had to give it a tripple salute (Ctrl, Alt, Del) and hope it worked

[7milesup]

6 hours ago, smirk said:

As an IT person I find it strange anyone would celebrate seeing a blue-screen , however glad you're on the right track with @mvdveer excellent help.

Lol, I did think of that when I posted it.  At that point I was so happy to not have the red "ERROR" screen on Klipper. If I remember correctly, my first Windows machine was Windows 3.1.  In 1983 or '84 I taught a computer class in high school because I knew more about computers than the teacher did. I got an "A" in that class, lol. I originally went to college for computer programming but decided that I liked the view out of an aircraft cockpit, so I went that route instead.

I am having another issue with Voron.  When doing the QGL it would get to the right front corner, do the first "probe" and stop, with an eventual time-out.  I haven't figured that out yet.   I am wondering if I have a z-offset limit set wrong or something similar.

[claudermilk]

6 hours ago, smirk said:

As an IT person I find it strange anyone would celebrate seeing a blue-screen , however glad you're on the right track with @mvdveer excellent help.

 

6 hours ago, mvdveer said:

I remember the "blue screen of death" on the early windows based machines.. Just had to give it a tripple salute (Ctrl, Alt, Del) and hope it worked

 I had the same thought "Someone is HAPPY to see the blue screen?!"

BTW, you all will be happy to know the BSOD still exists. It even now has a big ":(" included on the screen. You just don't get to see it nearly as often as in Win 3.1 days.

[smirk]

3 hours ago, claudermilk said:

It even now has a big ":(" included on the screen.

Clearly you're just bad!

[mvdveer]

7 hours ago, 7milesup said:

When doing the QGL it would get to the right front corner, do the first "probe" and stop, with an eventual time-out.

Sorry to be a pain, but I deleted your config file - can you re-upload again and I will have a look at it some time today.

[7milesup]

23 minutes ago, mvdveer said:

Sorry to be a pain, but I deleted your config file - can you re-upload again and I will have a look at it some time today.

Oh, you certainly are not a pain.   More like an angel. 

I actually had to do some work today so I did not get much time to mess with Voron.  There is definitely something going on with the front right Z motor (Z-3).   I looked through the printer and mainsail cfg files, but didn't pick up on any anomalies, which of course, means nothing.    

I should point out that when I do the X-Y home, I can move that Z-3 stepper by hand, whereas the other ones are locked during that movement. 

I also had this error shown in my screenshot. It seems like I was able to get through that because that error is no longer showing up.

I am going to be gone for a number of hours. I'll be home later on this evening so you may not get a reply for a while.

 

printer.cfg mainsail.cfg

Edited February 6, 2023 by 7milesup
added image

[mvdveer]

6 minutes ago, 7milesup said:

I also had this error shown in my screenshot. It seems like I was able to get through that because that error is no longer showing up.

It will still be there under the notification button on the top right hand corner of mainsail, unless you fixed this. Easy fix, just need to change the path under [virtual_sdcard]

Will look at the configs sometime today (Is day here in Oz) when I get a break.

[mvdveer]

2 hours ago, 7milesup said:

 I looked through the printer and mainsail cfg files, but didn't pick up on any anomalies,

I have reviewd the files and other than haveing [virtual_sdcard] in both mainsail.cfg and printer.cfg, all looks good.

I have removed it in your printer.cfg

One thing to check before we go on is to ensure that the steppers are in the correct positions on the octopus board. I know because I made this mistake.

The slots are Motor0, Motor1, Motor2_1, Motor2_2, Motor3, Motor4, Motor5, Motor6, etc

Thus the 4th slot is NOT motor3, but motor 2 (runs of the stepper for motor2)

However the drivers need to follow the slots consequetively - do not skip a driver slot because of the above.

When you do a STEPPER_BUZZ, does all your Z axis move in the correct direction (starts moving up initially). Check for all 4 z-steppers eg 1st stepper will be

STEPPER_BUZZ STEPPER=stepper_z

then replace stepper_z with stepper_z1 and test again, then stepper_z2 and stepper_z3.

All should buzz in a positive direction = upwards when they start then down (up,down,up,down,up,down,etc)

Let me know how you go

mainsail.cfg printer.cfg

[mvdveer]

A picture is worth a thousand word they say:

You'll see 9 slotes to plug in the motors but only 8 slots for the drivers. The third stepper driver slot runs both motor2_1 and motoar2_2, the fourth stepper driver slot drives motor3 and so on

[7milesup]

@mvdveer Well, I think this thing is possessed and is determined to fry my brain.  I shut the printer down before heading out, come back and fire it up and the monitor that I have plugged into it via HDMI shows nothing.  I unplug my computer monitor and plug in the printer to it and it works fine.  I plug the printer monitor into my desktop and it works fine.  I then plug the original printer monitor back into the printer and it still doesn't work.  Good grief...

My Z3 motor is plugged into the Motor 5 slot.  I removed the driver to verify that the one jumper was placed correctly, and it is.  I checked the wiring, although not with an ohm meter yet, and it appears to be congruent with the coils. 

I did stepper buzz check and they all checked out except the Z3, which had no movement.  So, is the motor the issue, the driver on the Octopus board, or some other gremlin that is running rampant in my house.

I unfortunately will be at work tomorrow so won't get back to this until later tomorrow.

Sidebar:  I read Bill Bryson's "In a Sunburned Country" a little while ago.  It was entertaining and informative. Makes me want to visit.

[mvdveer]

4 minutes ago, 7milesup said:

I did stepper buzz check and they all checked out except the Z3, which had no movement.  So, is the motor the issue, the driver on the Octopus board, or some other gremlin that is running rampant in my house.

I'll start with changing the stepper driver first. If that does not work I will change the motor to a different motor port e.g motor7 and change the pin accordingly. (Assuming the extruder is on 6). If this fails - then most likely it is the motor itself.

[7milesup]

Well @mvdveer, I have done a number of diagnostic test and am left scratching my head.  

I unplugged Z3 and placed it in another stepper motor port, which after sending the STEPPER_BUZZ STEPPER=stepper_z(#) command, the Z3 motor did move as it was supposed to.  I then plugged the left front motor into the Z3 port and used the STEPPER_BUZZ command with no result.  I swapped the TMC2209 drivers around with the same result (Z3 dead).   Lastly, I installed everything back in the order I originally had the board and wiring configured, except the drivers.  Honestly, I lost track of which was the original Z3 driver.  I did a XYZ home which sort of worked except the Z was messed up a little.  The print head is close enough to the bed that Z, Z1, and Z2 move my tap far enough that the software knows where the bed is.  Here is the interesting par...After I am done doing that, all of the Z motors can be turned freely but the Z3 has a slight buzz to it like it is trying to hold position.  I have checked all of the jumpers under the drivers and they do seem to be in order.  I have attached a picture also for your review.  At this point I am wondering if it is the Octopus board?

Edited February 8, 2023 by 7milesup

[mvdveer]

1 hour ago, 7milesup said:

I unplugged Z3 and placed it in another stepper motor port, which after sending the STEPPER_BUZZ STEPPER=stepper_z(#) command, the Z3 motor did move as it was supposed to.  I then plugged the left front motor into the Z3 port and used the STEPPER_BUZZ command with no result. 

This would suggest to me that you had a bad stepper driver in that port OR the port is defective, which would then be the octopus board.

Easy way to test. (May be a bit tedious)

Leave your motors plugged in as they are;

Add your stepper drivers one at a time - testing that motor with stepper_buzz. It it works, onto the next driver (Turn power off when inserting the drivers) untill you find the faulty stepper. Should it happen that when you replace that "faulty" stepper with another and it still does not buzz, then it is the port. Unplug that motor, plug it and the stepper motor in the last port (motor7), change the pins (Step, Dir, Init, UART)  accordingly and test.

Hopefully this will fix it

[7milesup]

@mvdveer  I am afraid that that did not fix the issue, although it did stop the buzzing of the stepper.  When I do a QGL, the Z3 is dead, and yet, when I do a home it works.  There has to be a software glitch somewhere, but it escapes me.  I am not sure what to do at this point.  Maybe a complete reload of everything at this point?  

I am using an Orange Pi 3 LTS, but since I was able to get Mainsail and Klipper loaded onto it, the flavor of Pi shouldn't matter, or at least that is my theory.  

I just tried a INIT_TMC command and it says "missing STEPPER".  The same message appears when I try a "DUMP_TMC".  

I need to go to bed. It seems that I have to work tomorrow.

printer.cfg mainsail.cfg

[atrushing]

4 hours ago, 7milesup said:

the Z3 has a slight buzz to it like it is trying to hold position.

This sounds like it could be a loose wire connection. It might be worth re-verifying the crimping and that the wire isn't nicked/pinched somewhere..

[7milesup]

16 hours ago, atrushing said:

This sounds like it could be a loose wire connection. It might be worth re-verifying the crimping and that the wire isn't nicked/pinched somewhere..

I am going to check that tonight.  I did however move Z3 to a different port and it operated correctly but when I plugged another motor into motor5 (Z3's port), that motor then did not work.  I then proceeded to re-map Z3 to port 7, thinking that it was a hardware issue, but even after re-mapping to a different port I ended up with a Z3 that did not work.

This leads me to believe that it might be a software issue, whether it is a config file or firmware issue or...? 

I feel bad for not getting this resolved and chiming back in here all the time with issues, but this is somewhat new to me.