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]

20 minutes ago, 7milesup said:

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.

Don't feel bad - we are here to help

[mvdveer]

It might be obvious, but have you got a stepper driver on Motor 7?

[mvdveer]

Here is my printer.cfg file for the 2.4 for you to compare

mvdveer_printer.cfg

[7milesup]

19 minutes ago, mvdveer said:

It might be obvious, but have you got a stepper driver on Motor 7?

Yes. 

[smirk]

8 hours ago, 7milesup said:

I feel bad for not getting this resolved and chiming back in here all the time with issues,

Dont feel bad, we've all been there with some intractible issue. It can be soul destroying (as diagnosing things is a long, slow and tedious process) and confusing when lots of people chip in advice so  sorry for chipping in

I might not lay the issue at software's door just yet. Despite the knowledge required to "drive" klipper the firmware [on the MCU] is fairly simple (relatively speaking) and therefore reliable, and the configuration is fairly robust and "consistent" (in the sense that Z1 ..... Z4 motor driver sections should all be the same). Where I'm going with that I wouldn't expect a software bug to be taking out a single motor/driver/ port rather I would expect none of your drivers to work or all to work.

Having said that it could be a configuration typo. Not the first time I've double checked and trippled checked something only to realise on the fourth (or more) check that I've mispelled something or not added "!" or "^" when needed. The definition for Z3 should be a copy'n'paste of any other other (working) Z motor drivers with the exception of the actual pin names used to control the driver.

However, swinging back to your comment about the Z3 resisting movement, I would agree with @atrushing that does sound like a wiring issue almost like one of the pairs is shorting out (a simple way to figure out which pairs are which on a motor is to deliberate short them out and see if it causes "resistance" when trying to manually turn the motor). I guess part of the challenge is all the wiring is in place and tied in and the motors bolts into their respective places...

If you had a spare motor (not in the printer) you could use that as a diagnostic to move between ports to verify their operation (and the operation of the motor itself if it's an unknown quantity). Granted that's an ideal and if you don't, dont't worry about it. Also to state obvious (back to the tedious part) make sure the system is powered down before plugging and unplugging motors.

Sorry a couple of questions  - are the TMC2209 drivers all the same (same model, same manufacturer). If you say had one FYSTEC TMC2209 driver and the rest were BTT TMC2209 drivers there can be subtle differences between manufacturers which (sometimes) annoyingly require differences in pin-outs on boards. That is an absolutely long shot and I doubt it would be the case as you've been testing the drivers as per @mvdveer excellent guidance.

The other question is when you remapped Z3 to port-7 did you move the TMC2209 driver (from Z3)  or did you use a "new" one. Always worthwhile checking none of the physical pins on the drivers have become bent so they're not mating with the connector properly. The nightmare scenario is multiple hardware issues (wiring and driver).

[7milesup]

@smirk First, I love your avatar; make me smile.

Second, thank you for your lengthy response.  To answer a few of your questions...

The TMC2209 driver that was on port 5 was moved, but since I had all of the drivers off to check on the jumpers underneath the drivers, they got scrambled while on the bench so I actually don't know where that port 5 driver currently resides.

All of the drivers are BTT drivers that came with the Octopus board.  Confirmation was made when I had them off that the pins would function as intended with no bent pins.

I did check the wiring harness for Z3 via ohm meter, and it confirmed continuity.  However, there might be more to that story and my intent is make a new harness; more on that to follow.

I used a new config file last night but was having continued issues with the software.  I was exhausted after a long day at work (I was retired but came out of retirement.  What was I thinking!?), so that did not help.  However, tonight I looked at the file and noticed an error or two, although seemingly unrelated to the Z3 issue.  One of them was the address of the Orange Pi at the beginning of the config file.  The other one was Z stepper direction, but that was because it was a new file.  After those changes were made I brought up the console and did an X,Y,Z home.  That worked!  I then followed on with QGL and after much probing, it..... wait for it.... worked!   I honestly don't know what I did that made it work tonight vs. a No Bueno last night.  Maybe the electronics needed a nap like I did.  There is one thought though, and that revolves around the wiring harness for the Z3.  Since I had it off of the motor and Octopus board last night, I am wondering if me messing around with it indicates that there may be a connection that is not secure.  I will build a new one for piece of mind.

Hopefully this part of the saga is over.  I did watch the QGL numbers as it was running through that test and noticed that there instances where it said "Probe exceeds tolerance" or something like that.  Not sure if I should be concerned about that or not.  It did pass the QGL at the end of the probe passes, but maybe that should be revisited.

Again, THANK YOU so much everyone for their help.  I am thinking that I am not going to far away because this machine has not printed any plastic yet and there still remains a lot of setup before that can happen.

[mvdveer]

2 hours ago, 7milesup said:

"Probe exceeds tolerance" or something like that.

There is a section in the printer.cfg file under [probe] where you can specify the tolerance (samples_tolerance). This normally is around 0.075. However mine is set at 0.05, a much tighter tolerance. I adjust this as the printer gets better tuned. See what this is set at and perhaps increase this initially untill you get no errors, then decrease the value slowly.

The relevant section of my file:

[probe]
#pin: ^PG10                ; Z-endstop pin
pin: PB6                  ; BLTouch Port
x_offset: 0                ; probe is offset 20mm back from nozzle (was1)
y_offset: 0               ; probe is 0 mm from nozzle in Y direction (was-12)
#z_offset: 0                ; trigger point is 0 mm below nozzle. larger numbers move effective Z0 CLOSER to the nozzle (was9.5)
speed: 8                     ; probing speed of 5mm/second ideal is <10mm/sec  
lift_speed: 5               ; probe lift speed (was10)
samples: 3                   ; number of probes to perform per sample
samples_result: median       ; normalization method: see config reference
sample_retract_dist: 1.0
samples_tolerance: 0.05
samples_tolerance_retries: 3

There is also a section under [quad_gantry_level] there is a tolerance section which is much tighter.

speed: 130
horizontal_move_z: 5
retries: 6
retry_tolerance: 0.00550
max_adjust: 10

As you can see mine is set at 0.00550, which is lower than the recommended 0.0075. So if the gantry is out by more than 0.00550 after 6 tries, it will give an error "probe tolerance exceeded"

Again until you have done multiple QGL's, then maybe set this as 0.009 or even 0.01 to start and as your gantry gets leveled over multiple attemps, tighten this tolerance back to 0.0075.

Glad you got the printer going. Thanks @smirk and @atrushing for jumping in and asisting. Unfortunately sometimes work gets in the way of play and work has been really busy lately. Also difficult being at the ass end of the world. When you guys are awake I am asleep and vice versa.

Shout out anytime

[smirk]

4 hours ago, 7milesup said:

I love your avatar

My ever helpful doggy, who is currently snuggled into me as I type.

4 hours ago, 7milesup said:

I was retired but came out of retirement.  What was I thinking!?

Our lunatic government would love you, they seem to be on a constant warpath thinking of yet more ways to drive people out of retirement and back into work.

4 hours ago, 7milesup said:

I am wondering if me messing around with it indicates that there may be a connection that is not secure.  I will build a new one for piece of mind.

I think that is a possibility and a sensible approach. Over the years (decades) I've seen plenty of inconsistent connections where simply "wiggling a wire" will fix it (until the next time the cable is knocked). So, I would definitely agree with remaking the cable, I'd also suggest not to tie the cable into place until after you've checked the operation of the motors (Personally I like neat cabling,but I dislike even more when having to undo it all when I realise it's all gone Pete Tong....guess that's a measure twice,cut once kinda thing).

Glad you're back on the right path. This 3d-printing lark is definitely a journey rather than a desintation so no doubt there'll be a few more pot-holes on the way but we're always here to help! Jeez, I sound like a life-coach, sorry, must be the dog snuggling into me. Making me less of a GOM

[claudermilk]

Good to hear it's working.

FYI, I have seen "Too many retries" thrown when the printer can't get within the tolerance in the QGL (or z_tilt_adjust for the Trident) section. Same effect, it yells and gives up.

[7milesup]

@mvdveer, @claudermilk or @smirk  OK.  I am ready to try a print however I have a question.  How do I get my file from Cura, which is on my desktop over to my Voron which is obviously a stand-alone.  The Voron is connected to my home network but I am having a hard time with this Debian/Linux system.  How do you guys do it?  I know I am going to derail my own thread but...

[mvdveer]

I don't have Cura but will download a copy and have a play with it. There should be an export button after you have sliced the object. It will create a "gcode" file with the instructions for the printer on how and what to print. Save this in a convenient spot and then upload through mainsail/fluid. This is the instructions for Mainsail:

There should be a section in the Dashboard that says G-Code files.

Click on this and it will open your files.

Click upload and print,

This will upload the file and open the print dialogue box

or upload, then select the file and print.

                             

[mvdveer]

Had a look a Cura.

Open Cura and choose non-networked printer:

I choose Voron Desing, then Voron 2.

Upload you file from disk.

Slice the file and choose save to disk

Save the file in a convenient location:

Take note of where it is saved:

Follow the discussion in my previous post to upload to Mainsail

 

[mvdveer]

You can also connect it as a network printer and upload this directly onto the printer from the slicer. Will have a play with it when I get home tonight.

Can tell you how it is done in Superslicer, but unfortunately have never used Cura slicer and will have to experiment

[7milesup]

@mvdveer  Hi there.  I guess I didn't do a great job of asking my question.  I had actually gone through all of the task that you suggested, but I cannot figure out how to move the file from my desktop to the printer without an SD card or USB drive.  I would have thought I could do it through my local network but I am stumped on how to do it on Linux.  I was hoping to utilized my Google Drive account but Chromium (is that different than Chrome?) will not let me sign in .  I would have liked to use Firefox on my printer because that is my go-to for all of my other computers, and a simple sign-in on Firefox would let me access everything, but installing Firefox is appears to be not as simple as download and install. 

Edited February 12, 2023 by 7milesup

[atrushing]

17 minutes ago, 7milesup said:

I am stumped on how to do it on Linux.

I may be misunderstanding what you are describing, but it sounds like you are trying to pull files onto your printer.

From your desktop in the Mainsail/Fluidd web interface you can push the file to the printer by using the 'Upload' or 'Upload and Print' buttons. Or when you are on the "G-Code Files" page, you can simply drag and drop your .gcode file from your file manager to the printer.

[mvdveer]

You can access Mainsail/Fluid from a Windows or mac computer and use Firefox.

Typical setup:

Raspi Pi running a form of raspian (Linux) software

Printer controller board

Windows, Mac or Linux PC running Fluid or Mainsail.

To connect to the printer on windows/mac, in Firefox you would connect via "printername.local" e.g "http://voron24.local"

Alternatively you can save the file to an sd card and insert it into your raspi pi. However this is difficult due to the position of the pi in the electronics bay and not recommended.

 

To clarify, can you please let my know the following

Have you enabled wifi on the pi and connected to your home network?

On what machine does your mainsail/Fluid  interface sit?

 

[mvdveer]

Quote

My desktop windows machines sits on  my desk which is connected to my LAN via hardwired ethernet.

The printer is a stand alone system.  I have the Orange Pi which is currently connected to my house WiFi but it also has Bluetooth capability.  So the printer has Orange Pi connected to the BTT 1.1 board and Orange Pi is running Mainsail.  I have a keyboard, mouse and monitor hooked to the Orange Pi so it is completely stand alone.  Mainsail is running via Chromium on the Opi.

Hi, seemed you replied in the wrong thread, I hid it there and we can continue in this thread.

Mainsail should not be run from the Orangepi, but your home computer. (Just makes life so much easier).

Use a desktop computer, open firefox and then enter your printername.local. Mainsail interface should load. You can then import the file to the orangepi this way.

[7milesup]

Ohhhhhh.  Well, that would make sense.  No wonder I was having a hard time.  

 

[mvdveer]

3 minutes ago, 7milesup said:

Ohhhhhh.  Well, that would make sense.  No wonder I was having a hard time.  

Lets get that printer going..

[7milesup]

Uggghh.  I must be dumber than a box of rocks, lol.

So reading through the Voron documentation, along with your help, this is my understanding...

I have Mainsail installed on the Orange Pi, but should not be using the Opi to access it, which is what I am doing now via the browser on the Orange Pi via Chrome.  What I should be doing is accessing the printer via my home network and my desktop.  It is my understanding that there is no "install" of Mainsail on my desktop but rather, a discovery of my Voron through the IP address.  Once that is discovered, then I can access Mainsail (which resides on the OPi) to manage the printer.  

Like usual, I was making this waaaaayyyyy to hard for myself.  I clicked the "Machine" tab on Mainsail and there was the IP address staring at me.  Over at the desktop I typed that into Firefox and up popped the Mainsail interface.  Cripes. 

Now, I need to run back out to my shop and fix my office chair, which has started acting up.  I will report back on my success or failure within a couple of hours.

[smirk]

Wow that was a rollercoaster ride - glad I was out walking the dog as I would've probably only made it worse Think we've all been there: missing the bleeding obvious and taking a 10-mile detour for something that was really just across the street (so to speak).I just spent an hour (including ordering an unnecessary connector) trying to connect headphones to the TV via bluetooth from the phone......only to realise "Ah put head phones in pairing mode, then go into bluetooth devices on the TV.

[7milesup]

So, it wants to print, but not quite there yet.  Apparently my QGL is not in the right spot in the config file and some other sequences are incorrect.  The bed heats up slowly (60 rate I believe) and when the bed reaches temp the hot end then heats up (extremely quick I might add with that Rapido hot end).  The printer then wants to a QGL but of course the nozzle is too hot, so it reduces the temp to 150C, but then as soon as that task is accomplished it errors out because of course the nozzle is too cold to print. 

printer.cfg

Edited February 12, 2023 by 7milesup

[mvdveer]

It seems your print_start macro is very basic and does not call for a QGL

#   Use PRINT_START for the slicer starting script - please customize for your slicer of choice
[gcode_macro PRINT_START]
gcode:
    G32                            ; home all axes
    G90                            ; absolute positioning
    G1 Z20 F3000                   ; move nozzle away from bed

Thius calls the G32 macro

[gcode_macro G32]
gcode:
    SAVE_GCODE_STATE NAME=STATE_G32
    G90
    G28
    QUAD_GANTRY_LEVEL
    G28
    G0 X150 Y150 Z30 F3600
    RESTORE_GCODE_STATE NAME=STATE_G32

which has the QGL in there but no reference to the temperature of the bed or the toolhead, thus the error.

To understand what the macro does:

G90 - absolute positioning

G28 - Homes all axis

QUAD_GANTRY_LEVEL - Levels the bed

G28 - Homes all axis again

G0 X150 Y150 Z30 F3600 - Moves to the middle of the bed and raises Z to 30 degree at the speed indicated (F3600)

 

Can you please post the Gcode from Cura for this print for troubleshooting purposes. (in Cura. Click settings - >Printer -> Manage Printers -> Machine Settings -> Start G-Code.

If this only has print_start in there, then we will need to adjust it to:

START_PRINT BED_TEMP=[first_layer_bed_temperature] EXTRUDER_TEMP=[first_layer_temperature]

Lets see if this fixes it

 

[mvdveer]

If that alone does not help, then change your print_start macro as follows:

#   Use PRINT_START for the slicer starting script - please customize for your slicer of choice
[gcode_macro PRINT_START]
gcode:
    #G32                            ; home all axes
    #G90                            ; absolute positioning
    #G1 Z20 F3000                   ; move nozzle away from bed
    BED_MESH_CLEAR
    G90                             ;Absolute positioning
    M117 Homing...
    G28                             ;Homes all the axis
    M117 Heating bed ......
    M140 S{params.BED_TEMP}         ;Heats the bed to the temperature obtained from the slicer
    M190 S{params.BED_TEMP}         ;Waits for the bed to reach temperature before running any other commands
    M109 S150                       ;Heats the nozzle to 150 in order to use TAP
    M117 Leveling Gantry ........
    QUAD_GANTRY_LEVEL               ;Levels the gantry
    BED_MESH_CALIBRATE              ; does a bed mesh and saves it as default for the current session
    M117 Loading Mesh ........
    BED_MESH_PROFILE Load=default   ;Loads the mesh - now has to be done explicitely, not automatically loaded anymore
    G0 X150 Y150 Z30 F3600          ;Moves to the centre of the bed
    M117 Heating Toolhead
    M104 S{params.TOOL_TEMP}        ;Heats the toolhead to the temp obtained from the slicer
    M109 S{params.TOOL_TEMP}        ;Waits for the toolhead to reach temperature before starting the print
#    M117 Prime Line ..........     ;Prints a Prime Line 
#    G92 E0.0                       ;reset extruder distance position
#    G1 X10 Y10 Z0.3 F3000          ;move to prime line position
#    G1 X60 E10.0 F1000             ;intro line 1
#    G1 X200 E30 F500               ;intro line 2
#    G92 E0.0                       ;reset extruder distance position
    G90                             ;Absolute positining
    M117 Starting Print .......

Hope I haven't confused you too much

[7milesup]

39 minutes ago, mvdveer said:

Hope I haven't confused you too much

Oooooof.  You should know me by know.   Of course I am confused.