OrcaSlicer 2.4.1 e 2.4.2 corrigem bug que derruba peça

Se depois do OrcaSlicer 2.4.0 o bico do fatiador passou a raspar peça já pronta ou derrubou impressão da mesa durante a impressão sequencial, você não fez nada errado. É um bug conhecido, documentado em issues no GitHub, e os patches 2.4.1 e 2.4.2 já corrigem.

Entenda o que é impressão sequencial e onde o 2.4.0 quebrou

O OrcaSlicer imprime de duas formas. No modo padrão, "por camada", todas as peças da mesa crescem juntas: o fatiador termina a camada 1 de todas elas, depois a camada 2, e assim sucessivamente. No modo sequencial, "por objeto", cada peça é impressa por completo, com todas as camadas, antes de o bico seguir pra próxima.

Quem usa o modo por objeto costuma estar imprimindo várias peças pequenas na mesma mesa e quer evitar fiapos entre elas: no modo por camada, o bico viaja entre peças separadas a cada camada, e mesmo com retração bem calibrada sobra fio grudado de peça em peça. O por objeto elimina essa viagem repetida, mas cobra um preço físico: o conjunto do bico precisa ter folga suficiente pra passar por cima das peças já prontas sem tocar nelas ao seguir pra próxima. É essa folga que funciona como trava de segurança do modo.

Foi exatamente essa trava que o 2.4.0 comprometeu. A versão reescreveu o gerador de skirt, a linha de purga que o fatiador desenha ao redor da peça antes de imprimir, e com o skirt ligado no modo por objeto o programa passou a reimprimir esse contorno antes de cada peça seguinte, em vez de desenhá-lo uma única vez no início. Isso jogava o bico de volta pra perto da mesa, junto de peças que já estavam prontas e, se altas o bastante, no caminho dele. A ordem de impressão configurada pelo usuário também deixou de ser respeitada, o que podia colocar uma peça alta exatamente onde a lógica de segurança não esperava.

Foi essa mesma versão, o OrcaSlicer 2.4.0, já coberta aqui quando trouxe ganho de velocidade no Klipper, que abriu a brecha sem querer. O changelog oficial do 2.4.1 confirma o problema nesses termos, na página de release no GitHub: o skirt "podia ser reimpresso antes de cada objeto, passando o bico de volta sobre ele, ou até derrubando peças já impressas da mesa". Vale a ressalva de precisão: o bug só aparece com skirt ligado, no modo por objeto. Quem imprime peça única ou usa o modo por camada padrão nunca viu isso.

Pelo menos dois usuários relataram o defeito em issues abertas no repositório oficial, com impressoras e sistemas diferentes. drbetelgeuse abriu a issue #14319 em 20 de junho de 2026, numa Qidi Q1 Pro com Windows 11: a peça se soltou da mesa durante a impressão real, e a capa plástica do próprio bico saiu do lugar no impacto. O mantenedor kisslorand não conseguiu reproduzir de início, pediu mais detalhes e só depois de assistir a uma gravação enviada pelo usuário conseguiu replicar o defeito. Um terceiro usuário confirmou no mesmo tópico que o problema não existia nas versões beta e alfa do 2.4.0, só na final, e apontou um contorno temporário: trocar o tipo de skirt pra "por objeto" evitava a colisão até a correção sair. psyst8 abriu a issue #14366 três dias depois, numa Prusa MK3.5S+ com Klipper e macOS: "depois de cada objeto ele refaz o skirt e derruba as peças da mesa, e também não segue a ordem configurada", escreveu, confirmando que o mesmo arquivo imprimia sem problema no 2.4.0 Alpha e na versão anterior, a 2.3.2.

Veja como o 2.4.1 corrigiu o bug, lançado em 28/06/2026

A OrcaSlicer v2.4.1 foi publicada oficialmente em 28 de junho de 2026, conforme a própria API do GitHub, sem marca de rascunho nem de pré-lançamento. O colaborador kisslorand reescreveu skirt e brim num fluxo único: cada skirt passou a ser contado por grupo de peças e por altura de impressão, então ele sai só uma vez, não a cada objeto. No modo por camada com skirt por objeto, a ordem de impressão virou skirt, depois brim, depois a peça, pra cada uma delas. Configurações inseguras, que exigiriam um skirt ou escudo de corrente de ar (draft shield) compartilhado entre alturas diferentes num plano por objeto, passaram a ser recusadas com um erro claro no momento de fatiar, em vez de imprimirem silenciosamente do jeito errado. O reparo fechou as duas issues citadas acima, puxado por um voluntário como tantos outros que mantêm o projeto de pé, o mesmo tipo de trabalho que fundos como o que a Snapmaker anunciou pro Klipper e o OrcaSlicer tentam reforçar.

O 2.4.1 também trouxe duas mudanças menores, mas úteis. A primeira é um build nativo pra Windows ARM64, mirando notebooks com chip Snapdragon X Elite: antes rodava só emulado sobre x64, agora roda nativo, com paridade total de recursos. A segunda é um campo de temperatura mínima de câmara, separado do valor alvo: quem tem impressora com câmara aquecida pode configurar uma macro de início que dispara a impressão assim que a câmara passa, por exemplo, dos 50°C, mesmo que o alvo real seja 60°C, sem precisar esperar a temperatura final.

Confira o que o 2.4.2 resolveu 9 dias depois, em 07/07/2026

A v2.4.2 saiu em 7 de julho de 2026, também confirmada como release oficial na API do GitHub. O foco mudou de fatiamento pra estabilidade geral: três travamentos reproduzíveis, cada um com passo a passo conhecido, foram corrigidos. Girar a prime tower (a torre de purga entre trocas de filamento) selecionada com PageUp ou PageDown derrubava o programa; usar a ferramenta de medição depois de escolher uma aresta reta e, na sequência, um segundo ponto também travava; e calibrar Pressure Advance com a largura de linha da primeira camada em 0, valor que deveria simplesmente cair pro padrão automático, quebrava o cálculo.

O 2.4.2 também mexeu na sincronização de perfil pelo Orca Cloud, o sistema que o blog cobriu quando ainda era novidade em versão alfa. Um usuário identificado como TheMasterOfTech relatou, na issue #13943, que desligar a opção "Retract Before Wipe" num perfil de filamento não sobrevivia à sincronização: assim que o Orca Cloud sincronizava de novo, a opção voltava ligada e em 100%, porque o valor "desligado" simplesmente não era salvo no perfil enviado pra nuvem. O changelog do 2.4.2 lista essa issue como corrigida, e é verdade pro gatilho original. Mas vale o registro honesto: a própria pessoa que abriu o relato voltou ao tópico em 8 de julho, um dia depois do lançamento, confirmando que a reativação por sincronização parou, só que apontando uma variação nova: a opção volta a ligar sozinha ao reabrir o programa do zero, mesmo sem sincronizar de novo. A issue seguia aberta no GitHub na checagem mais recente, em agosto de 2026, quase três semanas depois da versão 2.4.2, sem fechamento nem comentário novo desde 08/07/2026. Quem depende muito dessa opção desligada faz bem em reconferir o estado dela depois de reabrir o programa, não só depois de sincronizar.

Outras correções do 2.4.2: presets que apontavam pra impressora ou filamento renomeado ou removido voltaram a carregar sem o aviso de "preset ausente"; reinstalar o plugin de rede da Bambu parou de entrar num loop pedindo reinstalação a cada abertura do programa; e rodar duas cópias do OrcaSlicer logadas na mesma conta parou de derrubar a sessão uma da outra.

Compare as três versões numa tabela

De longe a mudança mais visível pro dia a dia é a do skirt, mas as três versões resolvem problemas de naturezas bem diferentes.

Versão	Lançamento confirmado	Tipo de atualização	Principal risco resolvido
2.4.0	anterior a 28/06/2026 (já coberto no blog)	grandes recursos	nesta versão surgiu a regressão do skirt
2.4.1	28/06/2026	correção de regressão	skirt reimpresso podia derrubar peça na impressão sequencial
2.4.2	07/07/2026	estabilidade	3 travamentos reproduzíveis e reativação de override na nuvem

Atualize sem perder perfil nem configuração

As duas atualizações são gratuitas e instalam por cima da versão atual, seja pelo aviso automático dentro do programa, seja baixando o instalador direto da página de releases no GitHub, que também linka a versão na Microsoft Store pra Windows e no Flathub pra Linux. Perfis salvos localmente continuam no lugar; o próprio 2.4.1 adicionou um aviso único explicando a mudança no comportamento de sincronização que o 2.4.0 introduziu, pra ninguém ser pego de surpresa.

Se sua impressora tem pouca folga entre o bico e o topo da peça, caso comum em cartesianas com carro baixo, como a Kobra X, vale reconferir a calibração depois de qualquer atualização de fatiador. O blog tem um guia de ajustes finos no OrcaSlicer pra tirar a velocidade real da Kobra X que serve de base pra essa checagem, mesmo sendo focado em velocidade e não em skirt.

Saiba se vale atualizar mesmo sem usar impressão sequencial

Vale. O bug do skirt é o gancho mais dramático, mas as correções de estabilidade do 2.4.2 valem pra qualquer fluxo de trabalho: quem gira a prime tower pra reposicionar, quem usa a ferramenta de medição, quem calibra Pressure Advance, e quem sincroniza perfil entre mais de uma máquina pelo Orca Cloud. O build nativo ARM64 do 2.4.1 só interessa a quem roda Windows num notebook com Snapdragon X Elite, e o campo de temperatura mínima de câmara só importa a quem tem câmara aquecida com macro de início personalizada. Fora esses dois recortes, o pacote inteiro é ganho, sem perda de recurso.

Perguntas frequentes

O que é impressão sequencial no OrcaSlicer?

É o modo "por objeto": cada peça da mesa é impressa por completo, camada a camada, antes de o bico seguir pra próxima, ao contrário do modo padrão "por camada", em que todas as peças crescem juntas. Reduz fiapos entre peças separadas, mas exige folga suficiente pro bico não bater em peças já prontas.

O bug de skirt do 2.4.0 afeta quem imprime no modo por camada?

Não. O bug só aparecia no modo por objeto com skirt ligado. Impressão de peça única ou no modo por camada padrão nunca foi afetada.

Preciso reinstalar o OrcaSlicer do zero pra atualizar pro 2.4.2?

Não. A atualização roda por cima da instalação atual, pelo aviso automático dentro do programa ou pelo instalador mais novo baixado da página de releases. Perfis salvos localmente continuam no lugar.

O 2.4.1 e o 2.4.2 são gratuitos?

Sim. O OrcaSlicer é gratuito e de código aberto, mantido por voluntários e financiado por doação. Nenhuma das duas atualizações cobra nada.

Minha impressora ou filamento configurado pode sumir depois da atualização?

O risco vai no sentido contrário: o 2.4.2 corrige presets que ficavam órfãos quando um perfil de impressora ou filamento era renomeado ou removido, reduzindo justamente o aviso de "preset ausente" depois de atualizar.

Onde baixo o OrcaSlicer 2.4.2 oficialmente?

Na página de releases do repositório oficial no GitHub, que também linka o instalador na Microsoft Store pra Windows e no Flathub pra Linux.

Que tipo de impressão corre mais risco do bug do skirt?

Quem imprime várias peças pequenas de uma vez no modo por objeto com skirt ligado, principalmente em impressoras com pouca folga entre o bico e peças mais altas.

Já perdi uma peça por causa desse bug antes de atualizar. O que faço agora?

Atualizar pro 2.4.1 ou mais novo resolve o defeito de origem, sem precisar refazer perfil nem reinstalar do zero. Vale só reconferir a ordem de impressão e a opção de skirt antes do próximo lote de peças.

Atualize antes do próximo lote de peças

Quem já usa impressão sequencial pra ganhar tempo com várias peças pequenas na mesma mesa ganha mais com essa dupla de patches: o 2.4.1 fecha a falha que derrubava peça, e o 2.4.2 tira três travamentos do caminho. O download oficial fica sempre na página de releases do GitHub, e se notar qualquer comportamento estranho depois de atualizar, abrir uma issue no repositório é exatamente como esses dois patches nasceram: alguém reportou, alguém reproduziu, alguém corrigiu.