Input Shaping

[Pierre52]

Finally got to the point with my LDO 2.4 build where it was running sweetly and producing excellent prints.  Time to add some extra bits like the Nevermore Filter and the Nozzle scrubber.  Both done, completed and working as advertised.

 

Next up add the LDO input shaper - got to the RPi mods and worked through the following from the Klipper site:

 

Software installation¶

Note that resonance measurements and shaper auto-calibration require additional software dependencies not installed by default. First, run on your Raspberry Pi the following commands:

sudo apt update
sudo apt install python3-numpy python3-matplotlib libatlas-base-dev

Next, in order to install NumPy in the Klipper environment, run the command:

~/klippy-env/bin/pip install -v numpy

Note that, depending on the performance of the CPU, it may take a lot of time, up to 10-20 minutes. Be patient and wait for the completion of the installation. On some occasions, if the board has too little RAM the installation may fail and you will need to enable swap.

Afterwards, check and follow the instructions in the RPi Microcontroller document to setup the "linux mcu" on the Raspberry Pi.

Configure ADXL345 With RPi¶

Make sure the Linux SPI driver is enabled by running sudo raspi-config and enabling SPI under the "Interfacing options" menu.

Add the following to the printer.cfg file:

[mcu rpi]
serial: /tmp/klipper_host_mcu

[adxl345]
cs_pin: rpi:None

[resonance_tester]
accel_chip: adxl345
probe_points:
    100, 100, 20  # an example

It is advised to start with 1 probe point, in the middle of the print bed, slightly above it.

Did all of that then exited the WIN SCP session.

Turned the printer off .

 

Now when I turn the printer back on she dead lah. ... nothing nil zip nada.

How do I recover from that???

 

[smirk]

You've followed the instructions that I followed and to be honest I don't think there is anything in those instructions (even enabling SPI) that would be so drastic as to bork the PI.

 

These sorts of issues are never fun as the PI is buried at the bottom of the printer, but I guess as a first diagnostic are there any LEDs illuminated on the PI? You should get the power LED and a drive-activity LED (hopefully blinking as it boots).

One of the issues I have on occassions (which I think is nothing to do with my PIs and more to do with a hooky access point) is they drop off the network. This has the same effect as making the PI appear "dead", as all of a sudden I cannot access it. This issue is probably unique to me and appears related to mDNS resolution. Anyway, this is a kind of rambly way of saying "next step, check the network" (assuming you connect to the PI via network). See if you can "ping" the PI (using IP address rather than name) or (wholly dependent on your network kit) see if the network can see your PI as a connected client. This is step is easier said than done as it is utterly dependent on what network kit you have, if it does not give you any client information then you  have no easy way of figuring out the PIs IP address.
 

Next step, requires a spare SD card (or make a backup of your existing PI SD card). Basically burn a new SD-card with something like MainSail OS, that elminates any of the changes you've made (well eliminates all the software), and see if the printer boots up then. If it does boot then the issue is possibly related to the recent (ADXL) changes made.

Last step, is remove the PI from the printer and hook it up to a keyboard and monitor and get a look-see and see what it's saying as it boots (if it is at all).

 

 

[smirk]

I appreciate some (all?) of that post glosses over a lot of detail but if anything is unclear just ask. The key points are probably the first and last points in determing "how dead is dead" but  I'm hoping, with the middle points, we can get you through without the need to rip the PI out of the printer to diagnose.

[claudermilk]

Pretty much what @smirk said. First, how dead is dead? Is it completely dead or only mostly dead? (couldn't resist the reference). Can you SSH in? Can you ping the Pi IP address? Then get intos the more drastic, deep troubleshooting as outlined above.

I also went through those instructions a long while ago and no ill effects. None of that should bork a Pi.

[Pierre52]

Thanks for the quick response guys and apologies for the slow reply but twas sleepies time here in NZ.  My initial post was my standard knee jerk reaction to this type of event.  Pretty quickly I settled back to the more contemplative me working through all the troubleshooting steps you have both suggested.  I will start that process this morning and report back.  My biggest concern at the moment is that I  may have corrupted the SD card and all the various .cfg files that I have been so laboriously tuning for the last month or so.

My next concern is my lack of Linux knowledge. For me it's a bit like trying to write a novel in azebaijani with a dummies guide being my only resource.  Anyway let me get through the initial steps and I will report back a bit later today. When I get it back running, I will probably take the opportunity to do the full stealthburner upgrade as I have all the parts assembled and ready to install.

[Pierre52]

Lazarus is back from the dead.

Troubleshooting process was as follows:

1. Power on printer with visual access to boards - Both Octopus and PI lit up.

2. Run advanced IP scanner to confirm WIFI is up

3. Ping IP address with positive result.

4. Connect to PI with WINSCP

5.  Backup all files on PI to  PC.  Note to self -- Should have done this weeks ago and will now backup  every time I make a change to the Voron

6.  Power printer off and back on still no response from LCD or LEDs

7. Opened Printer.cfg on Pi using WINSCP  and commented out the last added lines - these ones from the Klipper Input shaping site

## added for input shaping - my comment
#[mcu rpi]
#serial: /tmp/klipper_host_mcu

#[adxl345]
#cs_pin: rpi:None

#[resonance_tester]
#accel_chip: adxl345
#probe_points:
#   100, 100, 20  # an example

8.  Power on and we are back in business

Given my poor familiarity with the programming language (Python?) it would seem to me that there should be an Include statement with the two lines in red. 

 

Edited April 16, 2023 by Pierre52

[smirk]

4 hours ago, Pierre52 said:

My biggest concern at the moment is that I  may have corrupted the SD card and all the various .cfg files that I have been so laboriously tuning for the last month or so.

Glad it's back, we all have those "omigod it's broken! What did I do?" moments. Personally, I keep a track of changes in a separate maintenance log so I know what I changed and when. Even with backups of all the CFG files it can sometimes become challenging trying to remember which copy is the "good" copy. Bit like spare printed parts, you can never have too many backups....but always best to have an index

[Pierre52]

So after chasing down yet another version of the PI upgrades, I finally succeeded in getting everything working.  The printer config script now works and Accelerometer_Query returns the desired results.  I suspect the big problem first time round was failing to get the PI to act as a secondary MCU.

 

So now it is time to poke sticks at tigers and have a crack at getting stealthburner installed.

 

What can possibly go wrong

[mvdveer]

2 hours ago, Pierre52 said:

What can possibly go wrong

Nothing..... or Everything...... 

Just take your time, be careful with installing the LED's in the nozzle. Take your time installing the fans - don't force anything - it will lead to breaks. (I know - been there, done that) Read the manual before starting, read it again, then start the build, carefully following the manual. Shout out if you need advice or uncertain about anything.

[Pierre52]

Have already been using the Stealthburner face on the Afterburner body so fans and LEDs are all installed.  I had to wait for the pancake stepper motor to arrive.  I am also going with the extra PCB behind the Part fan and a different PCB on the body.   The mechanical parts of building these things aint the problem.  It's the software and code that gets me - particularly Linux.

 

[mvdveer]

23 minutes ago, Pierre52 said:

It's the software and code that gets me - particularly Linux

No Linux code involved. Just some settings in Klipper [extruder] section to do with gear ratio and rotation distance. This will depend on the Extruder you are using. If you are building it with CW2, then the setup is pretty straight forward. Shout out when you get to that part

[claudermilk]

Good to read that things are working. I also get that knee-jerk "oh crap! I've bricked it! What did I do? WHY did I do that?" response. After stepping away and calming down I can troubleshoot and fix it.

Stealthburner & CW2 is almost entirely a hardware change, no config changes aside from the gear ratio. Possibly checking rotation distance calibration. Also if you want to mess with the LEDs, that can become a rabbit hole, but not critical to the printer functioning.

[Pierre52]

yes the colour settings of the Print Head LEDs is a tad annoying.  At the moment they are red when printing. It would be nice to have white so I can see what is happening.  I have successfully changed the background colour of the Display LEDs - just another task on the to do list.

[claudermilk]

I use the led-effects library. My config is backed up on GitHub--look at the led.cfg file. I have my print_start to turn the nozzle LEDs to white. One of the really noticeable benefits of the Stealthburner toolhead.

[Pierre52]

After a day of shall we say "interesting" reconfiguration including some fun times with PCBs and connectors the Stealthburner is installed, working and calibrated.  Now on on to what started all this - Input Shaping.

I will report results later.  In the meantime, many thanks to Claudermilk for the led-effects library.  That will be next on the upgrade list. 

[Pierre52]

Well this is fun.

Ran Shaper_Calibrate

Got the results

Ran Save_Config

Turned off the printer and now we are back to square one with the Pi not talking to the MCU

I can Win SCP into the Pi and all the lights are on downstairs on both the PI and the Octopus but upstairs no bueno.

Mainsail reports the following:

 

Option 'serial' in section 'mcu' 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 have checked the printer.cfg file against n earlier  known working version and there appears to be no difference.  I have copied the cfg file below.

If anyone can shed any light on this latest glitch in the Voron murder mystery I will be most grateful

 

printer.cfg

[mvdveer]

You can get this error if you still have the Input shaper attached to the pi and the mcu commented out in the config file. (as you have)

## added for input shaping
#[mcu rpi]
#serial: /tmp/klipper_host_mcu

 

[Pierre52]

Sorry should have made it clear.  I had physically removed the Shaper PCBs before the failed re-start.   After the re-start failure I tried commenting out those lines as that had been part of the previous problem.

Just for S&Gs I tried refitting the PCBs and uncommenting those lines again.  Still no bueno

[Pierre52]

Latest Problem Solved

The Printer.cfg file on the PI was there but had zero conent.

Loaded the most recent backup and we are back in action.  

 

Tell me how that happened?

 

[mvdveer]

Glad you figured it out. Cannot explain how the cfg file disappeared. When you turn off the pi and restart - is the file still there or does it again vanish? 

[mvdveer]

Another thought - if you edit the printer.cfg, do you do it through mainsail or 3rd party app? I tend to always edit mine in the mainsail browser

[Pierre52]

I am going to call this problem/s resolved and just blame Murphy for the at times random results.