Calibration not possible about enragedrabbitproject HOT 10 CLOSED

Hi! Thanks for all the details, makes it easy to help :)

First, encoder :

• your values aren't perfect, but still in the somehow usable range
• to improve that, make sure the gears are clean (the part seen by the ir sensor as well as the filament 'teeth')
• if it's still the same, try another bmg idler. Some users have reported some 'off specs sized' idler causing issues like yours

Second, 'unable to save variable' error message :

• make sure the path in the [save_variables] section in the ercf_software.cfg links to the ercf_vars.cfg. it seems not to be the case for you right now

Third, the timeout issue. This is purely an octoprint issue, not an ercf one. Octoprint is expecting the mcu to report regularly some heartbeat signal, even during lengthy
commands. Apart from switching away from Octoprint (I personally strongly encourage you to at least try mainsail and/or fluidd), look here https://community.octoprint.org/t/timeout-configuration/13130/2.

Also note that Octoprint will likely override stuff like the T0, T1 etc commands and the Pause and Resume ones.... so you'll have to make sure that the macros from the ercf repo are not skipped.

from enragedrabbitproject.

Thanks for the help!

The following has happened so far:

• I've relocated the ercf_vars.cfg to the proper folder to be used in Octoprint - Fluidd / Mainsail, which the Manual relies on, apparently have a different Folder structure.
• I've replaced the Sensor BMG that came with the ERCF Set with an entirely different one from a complete BMG Extruder Set I had intended for use in another Extruder. I also shaved down a little more of the IR Sensor supporting plastic to get it closer to said BMG - They now make eeeeeever so slight contact without binding resulting in fairly different numbers:
  
  The Load/Unload numbers are now more in line with each at the cost of the stdev now having gotten worse for Load but improved for Unload - 3.6 Röntgen, I guess?
• Those changes so far allowed me to do a full ERCF_Calibration - Changing the Single Toolhead to a 6xShared one in Octoprint allowed me to test the Tn Command successfully to load but unloading would again take so long it would cause a Timeout and with me not knowing which commands to add in the Link you provided I decided to move on...
• So, I decided to give Fluidd a shot using a 2nd SD Card.
  Lots of problems... Most of which I could fix by adapting some logic from the process of building the Voron itself like Fluidd now complaining about there be missing rotation_distance, gear_ratio values, and the microsteps ones being under the wrong section ( Drivers instead of Steppers ) - Is this a Fluidd quirk it being so picky or is this perhaps a new Klipper Version issue that came with the Fluiddpi Installation on the new SD Card? Octoprint sure wasn't complaining about this.

Yeaaa... As I'm writing this, I noticed that only your non ERCF Easy-Brd ercf_hardware.cfg is providing those missing/proper settings. Probably something to look into? 😉

• Aanyway... I'm now stuck with this error Message:
  
  Already having seeked for help in the Fluidd Discord it appears that I'm required to recompile the MCU Firmwares?
  The BTT Octopus V1.1 has already received a Firmware onto its SC Card from the klipper/out folder that came with Fluiddpi I installed today - Shouldn't that provide the most recent version? Same for the ERCF Easy-Brd one that wasn't even 2 days old! If not, where am I supposed to get current firmes from? 🤔

from enragedrabbitproject.

Some progress and some not...

Puh... I figured out how to deal with the above mentioned Firmware Problem - Hella Task to get a new Firmware onto that BTT Octopus V1.1 Board using a special Bootloader - Updating the ERCF Easy-Brd was less of an issue once you know that you know you can identify it using ls -l /dev/serial/by-id/* and just use sudo /usr/local/bin/bossac -i -d -p /dev/ttyX -e -w -v -R --offset=0x2000 out/klipper.bin instead of the half a kilometer long /dev/somethingsomethingetc... variant.

Fluidd though is still not happy and is as undescriptive as ever:

All I could figure out is the error disappearing once I exclude [include ./ercf_software.cfg] from the printer.cfg but obviously this isn't an option with that file being kinda important? Taking a peek into printer.cfg for ercf revealed 359 results - meh?! 😑

I obviously had some edits to mine already made ( like changing the Encoder Pin to encoder_pin: ^ercf:PA6 instead of encoder_pin: ^P1.0 ) but even using a "clean" ercf_software.cfg from your GitHub had the error appear.

from enragedrabbitproject.

that means that you missed copying the ercf.py file to the klippy/extras folder.

from enragedrabbitproject.

Argh... The darn changing Folder Structure between Octoprint and Fluidd... I need to stop working on unfamiliar stuff until early/tired into the mornings 😑

Thanks for the help!

from enragedrabbitproject.

I have returned 😅

Just for everyone's sanity - Is there a way to communicate with other ERCF Builders that have already built and successfully used the system to get the load off Etty providing support? 😉

Anyway... I've now "successfully" printed my first ERCF Part...

...but that took a lot of pampering from my side and some sacrifices along the way...

1. Like predicted in the Manual on Page 124 - My Purge Line is part of my PRINT_START G-Code Macro which is now obviously broken as there'll be no Filament at the time of the Purge:
   
   Being the simpleton that I am I tried to just split the code in two like how it is shown in the Manual Example with BRUSH_TOOL_PURGE LENGTH=80.0 PARKMOVE=0 with the Purge being a new one separate from the original to have it executed after the Filament would have been loaded using PRINT_START2 in the Slicer:
   
   but Fluidd disagreed with that:
   
   Can you maybe also provide your entire PRINT_START G-Code Macro ( with the BRUSH_TOOL_PURGE LENGTH=80.0 portion ) as a reference?

2. As can be seen on the next picture:
   
   My Purge Tower has a significant buildup in the area the Toolhead comes to a stop - I assume I'm loading the Filament too far during the Loading sequence? I'm pretty sure I can also hear some skips in the toolhead from the overpressure.

Using F360 - I Frankensteined a Mosquito HF / Poor man's SmartWatch Toolhead 3D Model together ( PTFE Tube doesn't enter that deep into the Extruder housing ) to get the proper measurements described on Page 126/127:
ercf_software.cfg
variable_end_of_bowden_to_sensor: 44.0
variable_sensor_to_nozzle: 60.0
SuperSlicer
Cooling tube position: 38
Cooling tube length: 20
Filament Parking position: 58
Extra loading distance: -57.8
I assume I'd ideally want for the Extruder to purge thin air during the first moves and gradually start ramping up as actual filament enters the nozzle but like described above there's already heaps of extra filament on the purge block once the loading has finished - My Mosquito is kinda leaky so it may already be an issue while unloading? 🤔 IDK...

3. Babysitting...
   I noticed unused Filament T1 ( or any other unused T2-5 ) also getting ever so slightly unloaded even further withing their Filament Blocks during the unloading of the currently used Filament T0 causing it to leave the area where the BMG Gear could reach it once it's being requested - Any suggestions for that issue? Creating a Kink in the PTFE Tube ( or using thinner ID ones ) that feed into the Filament Blocks to increase friction in hopes for that friction overpowering unwanted unloading of any Filament not engaged by the ERCF_SERVO_DOWN pressing onto its Filament Top?

from enragedrabbitproject.

For the blobs of plastic after a load : you need to tune the sensor_to_nozzle variable. Reduce it to reduce the blobs, until they are no more :)

from enragedrabbitproject.

Being the simpleton that I am I tried to just split the code in two like how it is shown in the Manual Example with BRUSH_TOOL_PURGE LENGTH=80.0 PARKMOVE=0 with the Purge being a new one separate from the original to have it executed after the Filament would have been loaded using PRINT_START2 in the Slicer:

but Fluidd disagreed with that:

Your PRINT_START2 macro is missing the "gcode:" line.

from enragedrabbitproject.

Can I close this issue or is there something left you need help with?

from enragedrabbitproject.

I'm good, thanks =)

from enragedrabbitproject.