Capa gerada no ChatGPT

Minha Voron 2.4 ficou parada por meses.

Quando uma impressora desse tipo fica muito tempo sem uso, voltar a imprimir não é simplesmente ligar e mandar um arquivo. Antes disso, vem o ritual que muita gente conhece: atualizar Klipper, Moonraker, Mainsail, plugins, firmwares, dependências e tentar lembrar tudo que foi instalado, testado e alterado no passado.

Foi nesse processo que o problema apareceu.

Depois dos updates, o Klipper parou de iniciar com o erro:

Internal error during connect: __init__() missing 1 required positional argument: 'param_helper'

A partir daí, usei IA como copiloto técnico, conectada via SSH na Raspberry Pi da impressora, para diagnosticar, corrigir, limpar e reorganizar todo o ambiente.

A impressora é uma Voron 2.4 com Klipper, Moonraker, Mainsail, Octopus em USB-CAN bridge, EBB via CAN e StealthChanger/KTC-Easy.

O ambiente antes da limpeza

O erro do Klipper foi só o sintoma.

O ambiente carregava histórico. Durante a montagem, testes e tentativas de melhoria, várias coisas tinham sido instaladas: câmera, timelapse, plugins de velocidade, módulos experimentais, configurações antigas e referências que já não faziam parte do uso atual da impressora.

O caso mais importante era o toolchanger.

Minha impressora usa StealthChanger/KTC-Easy, mas ainda havia bastante herança antiga de TapChanger. Na época da montagem, o StealthChanger usava o TapChanger como referência em alguns pontos. Depois os projetos evoluíram, mas ficaram arquivos, repositórios, referências e configurações antigas no ambiente.

Também havia restos de:

  • TapChanger antigo
  • auto_speed
  • sonar
  • crowsnest
  • timelapse
  • câmera antiga
  • configs de toolheads não usados
  • módulos externos em klippy/extras
  • serviços systemd que já não faziam sentido

Esse tipo de acúmulo é comum em projetos DIY avançados. A impressora pode até funcionar por um tempo, mas o ambiente fica frágil. Um update pode quebrar algo que ninguém lembrava que ainda estava instalado.

O diagnóstico

Em vez de sair apagando arquivos ou tentando soluções aleatórias, a IA começou pelo básico correto: logs.

Foram analisados:

  • klippy.log
  • moonraker.log
  • configs incluídas pelo printer.cfg
  • módulos em klippy/extras
  • repositórios instalados em /home/pi
  • serviços systemd
  • Update Manager do Moonraker
  • symlinks quebrados
  • plugins externos
  • status CAN
  • estado dos firmwares

A causa principal era incompatibilidade de módulos externos depois das atualizações. O ambiente ainda tinha resíduos e referências de plugins antigos, principalmente ligados à fase anterior do toolchanger.

A correção foi feita de forma conservadora: backup antes de editar, nada destrutivo, mudanças pequenas e validação após cada etapa.

Firmware e CAN

Também aproveitei para atualizar e documentar o firmware das placas.

A impressora usa:

  • Octopus via USB-CAN bridge
  • EBB via CAN

Os firmwares foram atualizados, os builds ficaram salvos em:

/home/pi/printer_data/firmware_builds

Também foi criado um README documentando:

  • UUID CAN da Octopus
  • UUID CAN do EBB
  • versão Klipper usada
  • arquivos .config
  • binários gerados
  • comandos de flash
  • procedimento seguro para repetir o flash
  • alertas de rollback

Depois disso, a saúde CAN foi verificada. Os contadores estavam limpos:

rx_error=0
tx_error=0
tx_retries=0

Ou seja, sem indício de problema físico, elétrico ou de comunicação no barramento CAN.

Organização das configurações

Um dos maiores ganhos foi reorganizar a estrutura dos arquivos de configuração.

Antes havia muita coisa espalhada, configs antigas, arquivos ativos e inativos misturados. O padrão mais simples seria deixar tudo dentro do printer.cfg, mas isso não escala bem. Depois de meses sem mexer, fica difícil lembrar onde está cada coisa.

A nova estrutura ficou modular:

printer.cfg              # índice principal
core/                    # MCU e parâmetros gerais
hardware/                # fans e pins
motion/                  # steppers, probe, input shaper, path planning
thermal/                 # bed e segurança do extruder
toolchanger/             # StealthChanger/KTC-Easy
toolheads/               # toolhead T0
features/                # KAMP
macros/                  # macros separadas por finalidade
ui/                      # LEDs e display
docs/                    # documentação operacional
.theme/                  # customização do Mainsail

O printer.cfg virou praticamente um índice de includes.

Config files

Isso torna a manutenção muito mais simples. Se quero mexer em fans, vou em hardware/fans.cfg. Se quero revisar macros de filamento, vou em macros/filament.cfg. Se quero olhar toolchanger, vou em toolchanger/.

Essa organização reduz o risco de quebrar algo sem perceber.

Versionamento com Git

Outro ponto importante foi colocar as configurações ativas sob controle de versão com Git.

Foi criado um .gitignore para evitar commitar:

  • senhas
  • tokens
  • backups grandes
  • arquivos gerados
  • configs antigas
  • lixo técnico

Agora cada mudança relevante vira commit local. Isso dá histórico, diff e rollback.

Para uma impressora Klipper, isso muda muito o nível de segurança. Uma alteração feita pelo Mainsail, terminal ou editor deixa de ser uma mudança invisível.

Mainsail mais operacional

Também reorganizamos a interface do Mainsail.

Foram adicionados links customizados para:

  • Moonraker
  • Spoolman
  • checklist pós-update

As macros foram separadas em grupos:

  • Print workflow
  • Filamento
  • Manutenção
  • Risco manual

Macros perigosas, como subir ou descer a cama sem homing, ficaram isoladas em um grupo explícito. Antes, tudo ficava misturado e visualmente poluído.

Também removemos confusões da interface. Um exemplo foi o botão Z-TILT. Em uma Voron 2.4, a mesa é fixa e o correto é usar QGL. O Z-TILT era legado e foi removido da configuração ativa.

LEDs como estado da máquina

A parte de LED também foi revisada.

Antes havia muitos efeitos manuais disponíveis no dashboard. Isso poluía a interface e não ajudava muito no uso real.

A decisão foi manter o plugin led_effect, mas esconder o painel manual do dashboard. Os LEDs passaram a ser usados como estado da impressora:

  • aquecendo
  • limpando
  • homing
  • nivelando
  • meshing
  • imprimindo
  • resfriando
  • peça pronta
  • standby
  • erro crítico

Também encontramos problemas reais em macros:

  • uma macro chamava PURGE_FILLAMENT, que não existia
  • outra chamava SIREN, que também não existia

Esses são bugs que poderiam ficar escondidos por meses até alguém usar exatamente aquela macro.

Spoolman

Instalamos o Spoolman, integrado ao Moonraker.

Ele não precisa de hardware. Ele funciona como controle dos rolos de filamento. Você cadastra o rolo, seleciona qual está ativo e o Moonraker informa o consumo durante a impressão. O Spoolman desconta o uso estimado do rolo selecionado.

Isso ajuda a controlar:

  • peso restante
  • material
  • cor
  • marca
  • histórico de uso
  • risco de iniciar impressão sem filamento suficiente

O Spoolman foi escolhido porque traz ganho prático e baixo risco.

Também avaliamos outras possibilidades, mas deixamos para outro momento:

  • Shake&Tune, para diagnóstico de ressonância e tuning mecânico
  • Obico, para monitoramento remoto e câmera
  • Mobileraker, para acompanhamento pelo celular
  • reativação de webcam, quando fizer sentido

A decisão foi importante: não instalar plugin por instalar. Parte da dívida técnica vinha justamente de coisas que foram instaladas, testadas e esquecidas.

Documentação criada

Além das correções, foram criados documentos operacionais:

  • README do firmware atual
  • checklist pós-update
  • auditoria de plugins e módulos externos
  • documentação da nova estrutura
  • instruções de flash e rollback

Isso transforma manutenção futura em procedimento, não tentativa e erro.

O ganho real da IA

Sem IA, esse trabalho provavelmente levaria dias.

Na prática, eu provavelmente levaria pelo menos um mês para chegar no mesmo resultado sem IA. Não por falta de capacidade técnica, mas porque esse tipo de manutenção exige várias sessões espaçadas: investigar logs em um dia, entender plugins antigos em outro, corrigir firmware depois, reorganizar configs com calma, testar, documentar e só então voltar para os ajustes finos. Com IA, essas etapas ficaram concentradas em um fluxo contínuo, com diagnóstico, execução, validação e documentação acontecendo quase em sequência.

Não porque cada comando é difícil isoladamente, mas porque o conjunto exige contexto e disciplina:

  • ler logs
  • entender dependências
  • descobrir plugins incompatíveis
  • identificar restos antigos
  • separar o que é ativo do que é legado
  • criar backups
  • editar configs
  • validar includes
  • reiniciar o serviço certo
  • conferir printer/info
  • revisar systemd
  • checar CAN
  • atualizar firmware
  • documentar
  • versionar
  • repetir tudo sem quebrar a impressora

Mais importante: muita coisa provavelmente nem seria feita.

Quase ninguém revisa logs preventivamente. Quase ninguém limpa plugin antigo se a impressora “parece funcionar”. Quase ninguém documenta firmware depois que o flash dá certo. Quase ninguém separa macros, LEDs, toolchanger, KAMP, fans e motion em uma estrutura realmente fácil de manter.

A IA ajudou justamente nesse ponto. Ela não só corrigiu o erro inicial. Ela puxou fios soltos, encontrou dívida técnica, validou hipóteses e ajudou a transformar um ambiente envelhecido em algo mais limpo, versionado e documentado.

Próximos passos físicos

A parte de software ficou muito mais limpa, mas ainda existe uma etapa que a IA não consegue fazer por mim: a manutenção física da máquina. Antes de voltar a imprimir com confiança, ainda preciso revisar correias, reapertar parafusos estruturais, conferir conectores, lubrificar guias/eixos conforme necessário, limpar trilhos, verificar fans, checar o caminho do filamento, inspecionar o hotend, conferir o aperto do bico, validar o alinhamento mecânico do toolchanger e fazer uma nova rodada de calibrações. A IA ajudou muito no diagnóstico, configuração e documentação, mas a qualidade final da impressão ainda depende da parte mecânica estar tão bem cuidada quanto o software.

Conclusão

O resultado final foi uma impressora mais estável, mais limpa e mais fácil de manter.

O Klipper voltou a iniciar corretamente. Os firmwares foram atualizados e documentados. O ambiente foi versionado com Git. A estrutura dos arquivos foi reorganizada. O Mainsail ficou mais operacional. Os LEDs passaram a representar o estado real da máquina. O Spoolman foi integrado. E a dívida técnica acumulada foi reduzida.

Para mim, esse é um bom exemplo de uso prático de IA em manutenção técnica real.

Dashboard

Não foi “perguntar para o chat como resolver um erro”. Foi usar IA como um engenheiro de apoio conectado ao ambiente, lendo logs, acessando via SSH, fazendo alterações pequenas, validando resultado e documentando cada etapa.

Em um projeto como uma Voron, onde software, firmware, eletrônica, mecânica e configuração se misturam, esse tipo de assistência muda completamente a velocidade e a qualidade da manutenção.