Slic3r: Detectar arcos e gerar G2/G3

Ainda existem algumas falhas na detecção ou no centro do arco.

Algumas notas de @bkubicek aqui: http://bernhardkubicek.soup.io/post/191097625/If-you-have-a-path-of-segments

Além disso, parece que o raio nem sempre está correto.

http://www.thingiverse.com/thing :13976

Fatiar este modelo com --gcode-arcs resulta neste erro em torno de 70% do caminho do modelo:

Não é possível chamar o método "distance_to" em um valor indefinido em /home/sparr/src/slic3r/git/Slic3r/lib/Slic3r/ExtrusionPath.pm linha 168.

Eu suspeito que isso é porque ray_intersection não está retornando um ponto.

Por favor, adicione uma caixa de seleção na guia avançada para ativar/desativar o suporte ao corte de arco.

Eu gosto da sugestão do @jgeerds .
Eu adoraria ver Arcs trabalhando no Slic3r.

Ficarei muito feliz também se o suporte a arco puder ser usado, resultando em melhor precisão de objetos impressos e evitando algum problema de extrusão com segmentos muito curtos de pequenos arcos.

@furynick , você pode fornecer mais detalhes sobre problemas de extrusão com segmentos muito curtos de pequenos arcos? Mesmo com G2 e G3 o firmware subdividirá a curva em muitos segmentos pequenos.

não é um problema do Slic3r, mas um problema físico, eu comprei uma extrusora all in one onde o stepper é "plugado" diretamente no filamento, então o comprimento mínimo de extrusão para 1 step (driver RAMPS configurado com 1/16 microsteps) é de cerca de 0,02 mm (49 passos por mm).
O gcode da balsa por exemplo contém após cada linha de preenchimento uma extrusão muito pequena de 0,0031mm por ex (eu uso um bico de 0,2mm). Arcs contém também pequenos segmentos precisando de menos de 0,02mm de filamento e acredito que devam ser extrudados corretamente com comandos G2/G3 (preciso fazer alguns testes para verificar essa hipótese).
Em todos os casos pretendo imprimir peças mecânicas de precisão e quase todas as peças podem ter faces arredondadas que serão melhor impressas com comandos G2/G3.
Estou planejando adicionar um Worm como redutor para multiplicar a quantidade necessária de passos para avançar 1 mm de filamento e evitar esse problema, pois o valor mínimo de passos/mm não deve ser inferior a 1000 em minha mente.

Os comandos arc são suportados na GUI? Eu gostaria de gerar gcode com comandos arc para que haja menos código quando estou imprimindo objetos cilíndricos.

Eu tenho uma máquina rodando smoothieware e adoraria testar esse recurso para possivelmente incluí-lo em uma versão futura.
Parece estar desabilitado - Como faço para habilitá-lo novamente?

@qharley , esse código não é mantido e provavelmente nem funciona, a menos que algum trabalho seja feito nele

Entendo. Eu poderia fazer algum trabalho nele. Parece ser um daqueles recursos que todo mundo fica animado e depois desiste...

Talvez torná-lo dependente do sabor do gcode e suportar apenas o firmware que realmente o suporta adequadamente.

+1 neste

Oi

Eu tenho trabalhado em um detector de curva gcode para implementar arcos de código G2 e G3 por um tempo, e parece estar indo bem e para completamente de gaguejar por USB.

Um exemplo da mudança que pode fazer:

G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.84105
G1 X117.874 Y63.038 E5.94500
G1 X118.846 Y63.205 E6.05141
G1 X119.789 Y63.405 E6.15536
G1 X120.745 Y63.645 E6.26177
G1 X121.670 Y63.915 E6.36572
G1 X122.606 Y64.226 E6.47213
G1 X123.508 Y64.565 E6.57608
G1 X124.417 Y64.947 E6.68248
G1 X125.290 Y65.353 E6.78644
G1 X126.168 Y65.803 E6.89284
G1 X127.009 Y66.274 E6.99679
G1 X127.850 Y66.788 E7.10320
G1 X128.652 Y67.322 E7.20716
G1 X129.452 Y67.898 E7.31356
G1 X130.212 Y68.491 E7.41751
G1 X130.966 Y69.126 E7.52392
G1 X131.679 Y69.775 E7.62787
G1 X132.383 Y70.465 E7.73428
G1 X133.044 Y71.166 E7.83823
G1 X133.507 Y71.694 E7.91402
G1 X134.301 Y72.656 E8.04857
G1 X134.892 Y73.445 E8.15498
G1 X135.441 Y74.237 E8.25893
G1 X135.971 Y75.068 E8.36534
G1 X136.458 Y75.900 E8.46929
G1 X136.924 Y76.769 E8.57570
G1 X137.347 Y77.635 E8.67964
G1 X137.746 Y78.537 E8.78605
G1 X138.102 Y79.432 E8.89001
G1 X138.431 Y80.361 E8.99641
G1 X138.718 Y81.281 E9.10036
G1 X138.977 Y82.233 E9.20677
G1 X139.194 Y83.171 E9.31072
G1 X139.379 Y84.140 E9.41713
G1 X139.524 Y85.092 E9.52108
G1 X139.636 Y86.072 E9.62749
G1 X139.709 Y87.033 E9.73144
G1 X139.746 Y88.018 E9.83784
G1 X139.746 Y88.982 E9.94180
G1 X139.709 Y89.967 E10.04821
G1 X139.636 Y90.928 E10.15215
G1 X139.524 Y91.908 E10.25856
G1 X139.379 Y92.860 E10.36252
G1 X139.194 Y93.829 E10.46892
G1 X138.977 Y94.767 E10.57287
G1 X138.718 Y95.719 E10.67928
G1 X138.431 Y96.639 E10.78323
G1 X138.102 Y97.568 E10.88964
G1 X137.746 Y98.463 E10.99359
G1 X137.347 Y99.365 E11.10000
G1 X136.924 Y100.231 E11.20395
G1 X136.458 Y101.100 E11.31036
G1 X135.971 Y101.932 E11.41431
G1 X135.441 Y102.763 E11.52072
G1 X134.892 Y103.555 E11.62466
G1 X134.301 Y104.344 E11.73107
G1 X133.694 Y105.092 E11.83503
G1 X133.044 Y105.834 E11.94143
G1 X132.383 Y106.535 E12.04538
G1 X131.679 Y107.225 E12.15179
G1 X130.966 Y107.874 E12.25574
G1 X130.212 Y108.509 E12.36215
G1 X129.452 Y109.102 E12.46610
G1 X128.652 Y109.678 E12.57250
G1 X127.850 Y110.212 E12.67646
G1 X127.009 Y110.726 E12.78287
G1 X126.168 Y111.197 E12.88682
G1 X125.290 Y111.647 E12.99322
G1 X124.417 Y112.053 E13.09718
G1 X123.508 Y112.435 E13.20358
G1 X122.606 Y112.774 E13.30754
G1 X121.670 Y113.085 E13.41394
G1 X120.745 Y113.355 E13.51789
G1 X119.789 Y113.595 E13.62430
G1 X118.846 Y113.795 E13.72825
G1 X117.874 Y113.962 E13.83466
G1 X116.919 Y114.089 E13.93861
G1 X115.938 Y114.182 E14.04502
G1 X114.976 Y114.237 E14.14897
G1 X113.990 Y114.255 E14.25538
G1 X113.026 Y114.237 E14.35933
G1 X112.042 Y114.181 E14.46573
G1 X111.083 Y114.090 E14.56969
G1 X110.105 Y113.960 E14.67609
G1 X109.156 Y113.797 E14.78004
G1 X108.191 Y113.593 E14.88645
G1 X107.256 Y113.358 E14.99040
G1 X106.310 Y113.082 E15.09681
G1 X105.396 Y112.777 E15.20076
G1 X104.738 Y112.530 E15.27655
G1 X103.584 Y112.057 E15.41110
G1 X102.690 Y111.642 E15.51751
G1 X101.832 Y111.203 E15.62146
G1 X100.972 Y110.720 E15.72787
G1 X100.150 Y110.218 E15.83182
G1 X99.329 Y109.672 E15.93822
G1 X98.547 Y109.108 E16.04218
G1 X97.770 Y108.502 E16.14859
G1 X97.033 Y107.881 E16.25254
G1 X96.304 Y107.218 E16.35895
G1 X95.616 Y106.543 E16.46289
G1 X95.134 Y106.032 E16.53868
G1 X94.304 Y105.101 E16.67324
G1 X93.683 Y104.335 E16.77964
G1 X93.105 Y103.564 E16.88359
G1 X92.543 Y102.754 E16.99000
G1 X92.025 Y101.941 E17.09395
G1 X91.670 Y101.335 E17.16974
G1 X91.072 Y100.241 E17.30430
G1 X90.639 Y99.355 E17.41070
G1 X90.249 Y98.474 E17.51465
G1 X89.885 Y97.558 E17.62106
G1 X89.563 Y96.649 E17.72501
G1 X89.269 Y95.708 E17.83142
G1 X89.017 Y94.778 E17.93537
G1 X88.795 Y93.818 E18.04178
G1 X88.614 Y92.871 E18.14573
G1 X88.465 Y91.896 E18.25214
G1 X88.356 Y90.939 E18.35609
G1 X88.281 Y89.956 E18.46250
G1 X88.245 Y88.993 E18.56645
G1 X88.245 Y88.007 E18.67285
G1 X88.281 Y87.044 E18.77680
G1 X88.356 Y86.061 E18.88322
G1 X88.465 Y85.104 E18.98716
G1 X88.571 Y84.409 E19.06295
G1 X88.795 Y83.183 E19.19750
G1 X89.017 Y82.222 E19.30392
G1 X89.269 Y81.292 E19.40786
G1 X89.563 Y80.351 E19.51427
G1 X89.885 Y79.442 E19.61822
G1 X90.249 Y78.526 E19.72463
G1 X90.639 Y77.645 E19.82858
G1 X91.072 Y76.759 E19.93499
G1 X91.527 Y75.910 E20.03894
G1 X92.025 Y75.059 E20.14535
G1 X92.543 Y74.246 E20.24930
G1 X93.105 Y73.436 E20.35570
G1 X93.651 Y72.707 E20.45399
G1 E17.45399 F12000.00000

torna-se:

G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.841
G3 X93.651 Y72.707 I-2.924 J25.589 E20.454
G1 E17.45399 F12000.00000

Se você estiver interessado no código, posso fazer o upload para o GitHub se você quiser (embora seja bastante _raw_ no momento, parece fazer o trabalho).

sim, por favor, compartilhe seu código, estou muito interessado.

Ok, aqui vai:

https://github.com/manticorp/GCodeArcOptimiser

Todo o código de trabalho principal está em:

https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php

Está escrito em PHP (desculpe!), mas deve ser facilmente traduzível para Perl/C++.

Um problema que estou tendo é testá-lo - é difícil saber onde está dando errado, nunca consegui uma impressão totalmente funcional, mas muitos dos movimentos parecem certos - é claro que muitas pequenas coisas podem fazer uma falha de impressão, no entanto ...

PHP não é uma má escolha :)
Vou dar uma olhada e tentar, obrigado pelo seu trabalho.

Tudo bem - atualizarei o README em um momento com uma visão geral básica de como ele funciona - eu sei o quão enigmático pode ser ler o código hacky de outra pessoa ...

@qharley há um sabor de gcode Smoothieware agora, para que você possa trabalhar em arcos para ele, se desejar.

Eu ficaria mais feliz se isso vivesse no slic3r e não como um pós-processador gcode :)

Eu também gostaria de ver isso dentro do slic3r, e é por isso que estou trabalhando para que o algoritmo já implementado volte a funcionar.

Link para a filial: https://github.com/Salandra/Slic3r/tree/arcFix
Progresso até agora:

• Arcos são detectados
• Os pontos centrais do arco são calculados corretamente
• Gcode é substituído por G2, G3
• ainda alguns pequenos bugs como:
  
  
  
  • raio na camada superior um pouco grande demais. (Verificado visualmente através do Repetier Host)
  
  
  • uma linha de aparência estranha no primeiro objeto (tentei com 3 vezes o mesmo objeto, que basicamente é um hexágono com um pequeno e um grande buraco)
  
  

@Salandra alguma novidade sobre sua filial? Percebi que seu repositório parece não ter novas atualizações desde 3 meses atrás. Você acha que estaria pronto para mesclar ao slic3r regular?

Não, não está pronto, eu queria portar isso para C++, mas não tinha ideia de por onde começar.
Na verdade eu consertei alguns bugs no script de pós-processamento que já estava incluso mas ainda tem bugs abertos, como cálculo de valor E errado com eu acho que foi movimento E relativo.

E, na verdade, quase não tenho tempo para dar uma olhada nisso novamente.
Nem tenho certeza se o branch arcFix era real ou se eu removi a última alteração antes de enviá-los :-/

Estou prestes a iniciar a implementação de um modelo matemático para isso. Algum suporte do desenvolvedor? Porque vai supor muito trabalho e simulação xD. Eu tenho uma convergência matematicamente demonstrada, então é uma detecção de arco segura.

Faça perguntas, as pessoas que podem ajudar e querem participar. Não posso
garantir qualquer coisa específica em termos de suporte, porém, eu tenho um monte de
coisas acontecendo.

Em 5 de dezembro de 2017 às 10h12, "PurpleSensation" [email protected] escreveu:

Estou prestes a iniciar a implementação de um modelo matemático para isso.
Algum suporte do desenvolvedor? Porque vai supor muito trabalho
e simulação xD. Eu tenho uma convergência matematicamente demonstrada, então
é uma detecção de arco segura.

—
Você está recebendo isso porque você foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-349353693 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AAB8CsVQiOxmu_4hQbcmUS1RsZr6p5dNks5s9WtogaJpZM4CPczH
.

Ok, está feito. Agora eu tenho que verificar se o algoritmo é sólido, mas tenho certeza que é. Provavelmente vou publicar um artigo com isso, mas não sei como implementar isso no GitHub, fiz isso no MatLab.

Ele precisaria ser implementado em C++ para ser útil ao projeto Slic3r.

Em 9 de dezembro de 2017 09:12, "PurpleSensation" [email protected] escreveu:

Ok, está feito. Agora eu tenho que verificar se o algoritmo é sólido, mas estou
bastante certeza que sim. Provavelmente vou publicar um artigo com isso, mas
absoluty não sei como implementar isso no GitHub, eu fiz isso no MatLab.

—
Você está recebendo isso porque você foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350477368 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AAB8CilKXqig1mWQQ4k9y66IUGp-vUImks5s-qNUgaJpZM4CPczH
.

Muito interessado por este projeto e gostaria de ajudar, tenho algum conhecimento em C++ mas quase nenhuma habilidade com matlab.

Estou esperando para registrar a ideia para um artigo científico (preciso de algum currículo para um mestrado) e depois compartilho. Também tenho que verificar métodos para garantir a suavidade da curva nos pontos entre arcos e linhas e etc... Mas o código está perfeitamente sólido agora e sempre converge e retorna para você uma polilinha/arco com um determinado erro colinear.

As linhas verdes são arcos, os nós são os nós da polilinha original e a linha vermelha são linhas retas. Você pode me enviar polilinhas fechadas (dadas no formato de uma matriz de posições xy ordenadas) para testar o algoritmo.

Eu entendo perfeitamente querer escrever e publicar (eu já fui graduado
aluno eu mesmo). Como é a complexidade de tempo/espaço?

Em 10 de dezembro de 2017 10h53, "PurpleSensation" [email protected]
escrevi:

Estou esperando para registrar a ideia para um artigo científico (preciso de alguns
currículo para um programa de mestrado) e depois compartilho. Também tenho que verificar
métodos para garantir a suavidade da curva nos pontos entre arcos e
linhas e etc... Mas o código está perfeitamente sólido agora e sempre
converge e retorna para você uma polilinha/arco com um determinado erro colinear.

[imagem: imagem]
https://user-images.githubusercontent.com/23365990/33807172-d194e86c-ddd2-11e7-9bd5-9f8c5cc5fa46.png
As linhas verdes são arcos, os nós são os nós da polilinha original e
a linha vermelha são linhas retas. Você pode me enviar polilinhas fechadas (dadas em
formato de uma matriz de posições xy ordenadas) para testar o algoritmo.

—
Você está recebendo isso porque você foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350561807 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AAB8Ch6ym1LE2VxV4hYYlpIGg-W2qSRNks5s_AyMgaJpZM4CPczH
.

O Slic3r já pode gerar um conjunto de slices em SVG. Você poderia então verificar
contra muitos modelos interessantes (o que provavelmente seria útil para
referências para o seu papel).

Em 10 de dezembro de 2017 às 11h45, "Joe Lenox" [email protected] escreveu:

Eu entendo perfeitamente querer escrever e publicar (eu já fui graduado
aluno eu mesmo). Como é a complexidade de tempo/espaço?

Em 10 de dezembro de 2017 10h53, "PurpleSensation" [email protected]
escrevi:

Estou esperando para registrar a ideia para um artigo científico (preciso de alguns
currículo para um programa de mestrado) e depois compartilho. Também tenho que verificar
métodos para garantir a suavidade da curva nos pontos entre arcos e
linhas e etc... Mas o código está perfeitamente sólido agora e sempre
converge e retorna para você uma polilinha/arco com um determinado erro colinear.

[imagem: imagem]
https://user-images.githubusercontent.com/23365990/33807172-d194e86c-ddd2-11e7-9bd5-9f8c5cc5fa46.png
As linhas verdes são arcos, os nós são os nós da polilinha original e
a linha vermelha são linhas retas. Você pode me enviar polilinhas fechadas (dadas em
formato de uma matriz de posições xy ordenadas) para testar o algoritmo.

—
Você está recebendo isso porque você foi designado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350561807 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AAB8Ch6ym1LE2VxV4hYYlpIGg-W2qSRNks5s_AyMgaJpZM4CPczH
.

A complexidade do espaço pode ser linearmente proporcional ao número de nós que você introduz, mas depende de você. Você pode realmente usar mais memória para otimizar a complexidade do tempo.
A complexidade do tempo pode escalar exponencialmente com o número de nós (mais ou menos, não sou estudante de engenharia da computação, sou apenas um estudante multidisciplinar de física/industrial). Mas isso só acontece com curvas ruidosas, se você inserir um desenho mecânico de alta precisão, a parametrização é resolvida instantaneamente porque os arcos são detectados imediatamente após a primeira análise.

@PurpleSensation como um trabalho para informação de @platsch também foi submetido a um artigo.

Obrigado, estou pedindo ajuda aos professores, e generalizei o algoritmo para caminhos não fechados, aqui alguns resultados:

Parece um pouco estranho começar com STL que é interpolado linear e depois tentar trabalhar de volta aos círculos. Existe um benefício convincente para fazer isso?

Para quaisquer dois segmentos de linha conectados, é muito fácil encontrar o centro do círculo que inclui seus pontos finais (desde que não sejam degenerados). - Algo como 10 multiplicações, 14 adições e 2 divisões.

Portanto, para qualquer caminho de extrusão, você pode apenas gerar uma série de centros e, em seguida, agrupar segmentos se os centros consecutivos estiverem próximos o suficiente um do outro e os segmentos forem curtos o suficiente em relação ao raio. Suponho que também haja uma verificação para garantir que não esteja dando mais do que um círculo completo e que a quiralidade seja consistente.

Este é o problema do STL: você não pode ter um círculo.
Impressoras modernas suportam G2/G3, arcos não sofrem mais com nenhum padrão (arcos linearizados) e podem ser mais rápidos de fazer. gcode também é mais leve (apenas 1 linha para fazer um arco, não dezenas).

Para NateTG:

A coisa de fazer um algoritmo para isso é bem mais difícil do que fazer o que você diz. Não é muito mais difícil, mas você deve ser capaz de demonstrar matematicamente que o algoritmo encontra SEMPRE uma solução, que é ótimo ou semi-ótimo e lida bem com arcos colindantes ou múltiplos arcos radioativos (o que não é trivial, mas realmente resolvido). Além disso, você deve verificar se um certo erro colinear é correspondido.

A coisa de encontrar arcos e usar uma bandeja paramétrica em vez de uma polilinear é uma vantagem porque você precisa de menos movimentos de memória no processador e consegue manter uma melhor precisão e sincronização dos motores. Nas impressoras delta é comum encontrar pequenas bolhas nas impressões devido ao microstopping da extrusora. A velocidade de impressão também é limitada pelo número de operações por segundo. (quanto mais rápido você se move, menos densidade de polilinhas sua trajetória tem).

Só vou deixar isso aqui:

https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php

É um script escrito em php que:

1. percorre continuamente os comandos do gcode, empurrando-os para um buffer
2. verifica se os pontos no buffer se parecem com um círculo dentro de uma tolerância
3. se os pontos não parecerem mais com um círculo, esvazie o buffer e transforme [buffer - 1] em um arco gcode
4. vá para o passo 1

Ele faz isso por:

1. encontrar o círculo que descreve os pontos no buffer usando os mínimos quadrados (consulte https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php#L311)
2. calculando a distância total do erro entre cada linha e o círculo (consulte https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php#L359)
3. Se o erro for menor que um valor predefinido, crie um arco gcode do círculo, somando as extrusões ao longo dos comprimentos da linha.

Eu não sei se isso vai ajudar alguém na esperança de escrever um algoritmo para fazer isso, mas lá vai! Funcionou muito bem e consegui algumas impressões bem-sucedidas - era um pouco lento em php!

... estava um pouco lento no php!

Parece que muito desse "lento" tem a ver com uma implementação ineficiente. Você está fazendo algo que deveria ser O(N) em O(N^2) (ou O(N^4) para o algoritmo que você não está usando) duplicando o esforço.

Essas implementações funcionam bem em polilinhas bem comportadas. Mas garanto a você (estou pesquisando isso para um artigo) que polilinhas barulhentas introduzem muitas situações estranhas, como encontrar pequenos arcos que na verdade fazem parte de maiores se você procurar outra combinação paramétrica. Se você usar apenas um algoritmo de antecipação, perderá soluções ótimas em redes ruidosas

Bem, se há uma maneira melhor de distinguir um círculo de uma série de linhas retas do que um algoritmo de ajuste, eu adoraria ouvi-lo.

Eu não conseguia pensar em uma maneira melhor do que percorrer os dados e comparar com os círculos adequados. Ele tem limites embutidos que o tornam muito mais rápido, por exemplo, o buffer fica cheio em 100 pontos porque uma economia de 1/100 nas instruções é suficiente para a maioria dos usos.

Ele lida bem com linhas ruidosas, pois usa um ajuste de mínimos quadrados para refinar o círculo e, desde que continue encontrando círculos que se ajustem ao buffer dentro de uma tolerância, ele aproximará esses pontos de um círculo.

Se eles não estiverem dentro de uma tolerância a um círculo, eles devem ser substituídos por um arco de código G.

Bem, se há uma maneira melhor de distinguir um círculo de uma série de linhas retas do que um algoritmo de ajuste, eu adoraria ouvi-lo.

Da forma como é implementado no script, se houver um arco com N segmentos, ele executa getCircleCenterLeastSquares em um buffer de 1 e depois em um buffer de 2 ... até que seja um buffer de N + 1, para iterar aproximadamente N^2 /2 segmentos.

Isso é ainda pior com a função getCircleCenter porque ela executa cerca de N^3/6 etapas, então um arco de segmento N leva cerca de N^4/24 iterações.

Se, em vez disso, o algoritmo adicionar segmentos incrementalmente a um arco sem recalcular tudo para cada novo segmento, isso pode acontecer em N etapas. Não tenho certeza se há uma maneira fácil de fazer isso com a abordagem de 'mínimos quadrados' que você está usando.

Mesmo assim, desde que os arcos tendam a vir em grupos de segmentos, uma abordagem de busca binária é mais rápida que a incremental. A verificação de buffers de 1, 2, 4, 8, 16, 32, 64, 127, 96, 112, 104, 100, 102 e 101 percorre o loop em getCircleCenterLeastSquares cerca de 869 vezes, enquanto percorre 1,2,3 ...100 passa por esse loop 5050 vezes.

Você realmente pesquisa por papéis de interpolação paramétrica G0 e encontra outras maneiras de fazer isso. A questão é: você pode primeiro atribuir um índice para cada ponto descrevendo quanto tempo é o arco no qual está incluído e depois iniciar a atribuição a partir do índice máximo, ou tentar fazer as duas coisas ao mesmo tempo. A questão é: você perde soluções ótimas se fizer a atribuição antes de ter todas as informações?

A ideia de busca binária é boa, pois as curvas geralmente têm muitos pontos gerados pelo software de modelagem.

Se um buffer de 4 ou 5 for encontrado, ele poderá pular direto para números mais altos.

Isso é tendo em mente que muitos modelos não têm muitos arcos. Um cubo, por exemplo, passaria pelo algoritmo atual bem rápido, pois o buffer nunca passará de 3 pontos.

Eu acho que se resume à economia de tempo versus maré que você deseja. Você poderia ter um buffer máximo de 20 e ainda reduzir as linhas de código G em 20 vezes na melhor das hipóteses.

Minha motivação era permitir que minha impressora 3D funcionasse via octoprint com arcos suaves, pois a taxa de transmissão do raspberry pi significava que minha impressora gaguejava muito nos arcos - se eu passasse um minuto executando o código G através do algoritmo th8s, era melhor do que uma impressão falhando após 10 horas

Atualização: trabalho em andamento. O algoritmo é rápido e sujo, estou prestes a começar a escrever o artigo a ser publicado. O processo é feito por vários métodos, incluindo o incremental (o mais rápido, mas com as piores soluções).

Figura a) -> 0,1mm de erro colinear, 20% do peso original.
Figura b) -> 0,05mm de erro colinear, 26% do peso original.
Figura c) -> 0,01mm de erro colinear, 40% do peso original.
Figura d) -> 0,005mm de erro colinear, 51% do peso original.

A figura a) se aproxima da solução incremental de várias maneiras (como você pode ver, arcos sobrepostos não se resolvem mantendo a simetria).

300 deles levam cerca de 25 segundos para serem processados. Esse número pode ficar menor com implementação de paralelismo, gpu, etc...

Atualização: o método é perfeitamente implementável agora:

Uma parte completa de 500 camadas como a última mostrada é processada em cerca de 10 segundos sem qualquer heurística e sendo executada no MATLAB.

@PurpleSensation então quando devo reservar um tempo para revisar uma solicitação de pull;)

Não faço ideia mano xD. Isso já é implementável, mas provavelmente eu deveria esperar até a submissão do artigo. Também não tenho a menor idéia sobre a implementação de c++, isso é totalmente implementado no MatLab e tenho certeza que não seria um bom engenheiro de software. Vou tentar obter uma compilação modular plug and play c++.

Uma opção seria ter alguém olhando para ele sob um NDA ou similar para ver quanto trabalho seria converter do Matlab para C++.... Você está confiando muito nas bibliotecas do Matlab por conveniência ou velocidade? Ou é tudo matemática básica em código normal?

O AFAIK Matlab tem pelo menos um compilador para convertê-lo em código C autônomo (eu só li isso porque nunca usei o Matlab). Eu não tenho idéia se isso deve ser adquirido separadamente ou se está contido na licença padrão. Isso seria pelo menos muito mais próximo do C++.

Se você está falando sobre a solução com a qual estou familiarizado, ela não funcionará, pois essa abordagem incorporará o script em uma biblioteca que contém (parte do) mecanismo Matlab, além de um stub C que pode ser usado para vincular a biblioteca . Será grande, não portátil e afaik não distribuível.

Eu só tenho informações de segunda mão, mas pelo menos queria tê-las documentadas aqui - mesmo apenas por ter sido rejeitada. :-)

@purplesensation se você quiser, você pode me enviar em particular uma cópia antecipada do artigo e do script básico e eu posso esboçar o algoritmo em C++.

Estou muito familiarizado com o processo de publicação acadêmica. :)

Obviamente, o quão confortável você está com isso é um fator.

Este software parece muito bom em fazer arcos e quero experimentá-lo o mais rápido possível!

É possível criar um executável a partir do arquivo MATLAB que pode levar um
GCODE gerado pelo Slicer, e processe o GCODE para alterar as linhas para
arcos? Isso seria um software separado, mas pelo menos permitiria que mais
as pessoas testam e experimentam.

Se você compilar como um executável, não precisa se preocupar com o código
sendo copiado/roubado e outros podem tentar enquanto isso....

Em quinta-feira, 14 de junho de 2018 às 8h06, Manuel [email protected] escreveu:

Eu só tenho informações de segunda mão, mas pelo menos queria tê-las
documentado aqui - mesmo apenas por ser rejeitado. :-)

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/slic3r/Slic3r/issues/23#issuecomment-397288841 ou silenciar
o segmento
https://github.com/notifications/unsubscribe-auth/AJ2tvqINaxvNnhhnfj0e4bK0XPDTzwwYks5t8l_IgaJpZM4CPczH
.

Enquanto o algoritmo não for publicado, eu não o empacotaria usando o Matlab, tenho certeza de que muito pode ser extraído da biblioteca C. O que não significa que eu não gostaria de vê-lo acabar em uma ferramenta como o Slic3r em breve, mas apenas como um aviso justo :)

@lordofhyphens Ok, verifique seu e-mail.

@PurpleSensation É permitido que eu compartilhe este artigo com um aluno do GSoC (com o entendimento de que ele não seria compartilhado além disso).

Sim, apenas me dê algumas horas. Neste momento estou aplicando algumas correções importantes que o tornam muito mais compreensível (o inglês e a matemática). Vou reenviar para seu e-mail.

@PurpleSensation Obrigado.

@TheThirdOne está implementando a heurística do artigo escrito por @PurpleSensation nas últimas semanas do GSoC 2018.

@manticorp , agradeceria sua disponibilidade para testar a impressão assim que for mesclado;)

@lordofhyphens com certeza não se preocupe!

@lordofhyphens Não hesite em entrar em contato comigo para qualquer conversa direta sobre o assunto.

@manticorp Indique que o firmware da impressora deve ter implementado o comando G3 arcs.

@PurpleSensation Eu disse isso para @TheThirdOne.

@PurpleSensation Acho que o meu faz - fiz isso nos meus testes, a parte difícil foi obter as quantidades de extrusão exatamente logo após corresponder à curva

Algumas partes do método podem levar muito tempo para serem implementadas. Eles podem ser substituídos por aproximações simplistas (e perfeitamente funcionais). por exemplo, o pós-processamento do arco pode ser realizado apenas por um ajuste de arco de três pontos.
Provavelmente, a melhor ideia é começar apenas a aplicar o método aos perímetros devido à sua forma orgânica habitual. Deve funcionar perfeitamente sendo aplicado em todas as trajetórias, mas não sei.

Fiz um bom progresso para implementar isso conforme guiado pelo artigo de @PurpleSensation . Atualmente, a detecção de possíveis intervalos em que as linhas podem ser substituídas por um arco está funcionando. Eu tenho um algoritmo ganancioso temporário para escolher qual dos intervalos escolher. Atualmente, estou trabalhando para tornar a saída contínua e realmente produzir arcos.

@TheThirdOne Estou prestes a enviar uma versão definitiva do artigo, mudou muito e agora é muito mais compreensível. se você quiser eu posso enviar para você, eu só preciso de uma direção por e-mail. Além disso, se você precisar de algum bate-papo para esclarecer coisas de papel, eu não teria problema.

@PurpleSensation Deixe-nos saber quando se tornar público e como podemos comprá-lo/obtê-lo.

@PurpleSensation, mais importante, adicionarei a citação aos comentários quando for publicado.

Você pode enviar para mim e eu posso encaminhá-lo para @thethirdone também.

@mamoit scholar.google.com mostraria o título do artigo e onde ele foi publicado.

Não acredito que haja apoio financeiro para @PurpleSensation comprando uma cópia da edição ou artigo da revista em que ela chega.

Também provavelmente levará meses antes de ser publicado.

@purplesensation uma coisa que ajudaria, eu acho, é verificar se os testes escritos por @thethirdone estão corretos (ou seja, dado A, B é a saída)

Vou submeter ao ArXiv, então se for aceito não deve demorar muito. Meu único problema agora é minha falta de afiliação com qualquer Instituição (o que é comumente solicitado). O ArXiv fornece uma versão temporária do documento para que esteja acessível em poucos dias. @lordofhyphens não há problema com a verificação, até espero compartilhar o código MATLAB no mathworks

@TheThirdOne fyi https://en.wikipedia.org/wiki/G-code#I quando você chegar à geração de gcode.

O centro ao usar I/J/K é um deslocamento relativo da posição atual.

Eu tentei implementar a geração GCode para isso como um filtro. A implementação perl dá uma boa ideia sobre como deve ser, mas se aplica a tudo em uma camada. Parece que o encaixe do arco provavelmente não faz sentido com suporte e só faz sentido com preenchimento especificamente projetado.

Eu ia perguntar se havia uma boa maneira de detectar se uma linha era de preenchimento ou perímetro, mas percebi ao escrever isso que posso filtrar mais cedo por perímetro.

Eu também fiz algumas pesquisas para não analisar e regenerar o gcode. Como esperado, é necessário tocar em várias classes diferentes para adicionar suporte ao arco. Não parece uma solução limpa, particularmente com a percepção acima.

Aqui está o artigo: Parametrização de trajetórias NC definidas por polilinha.

Estou prestes a fazer o upload da implementação do código no MatLab, deve ajudar.
@TheThirdOne O preenchimento pode ser um pouco filtrado usando os parâmetros de controle do método. Forçar cada par de pontos consecutivos dentro de qualquer arco a ter uma distância máxima entre eles pode evitar a geração de arcos em preenchimentos de linha e outras coisas. Provavelmente 0,5 mm é um bom requisito.

Não há nenhum estágio no processo de fatiamento em que você tenha uma descrição do nó bruto do processo de impressão? Começar a partir disso pode ser mais fácil do que desconstruir o GCode.

@purplesensation melhor que temos são as Polylines que compõem as superfícies em PrintGcode.cpp.

@thethirdone envie suas atualizações para o seu fork e eu posso dar uma olhada mais de perto.

@PurpleSensation , tenho uma pergunta sobre o papel. Como é garantido o 4a? 3.1 parece apenas garantir que nenhum intervalo seja um subconjunto de outro.

@TheThirdOne Você está certo. A condição de não trabalhar com intervalos incluídos na união de dois outros intervalos é levada em consideração na busca de interseções. Vou tentar explicar melhor:
Veja a Listagem 2 em 3.3. Quando você analisa um intervalo (chame-o de A) para encontrar interseções à sua direita, você basicamente procura outros intervalos começando de dentro de A e mantém aquele que alcança mais distância em seu final (chame para este intervalo B selecionado). Com este comportamento você está descartando todos os intervalos contidos na união de A e B.

Esse é um ponto complicado de descrever. Eu estava esperando a pergunta.

Aqui está o código
Aproximação de polilinhas com arcos e segmentos.

Eu tenho uma implementação completa além da configuração e apenas com um simples manipulador de interseção ganancioso. É possível que haja alguns problemas importantes com a interface do GCode, pois isso ainda não foi testado.

@TheThirdOne figuras? Quer me enviar uma polilinha para comparação?

Aqui você tem uma cápsula de código publicada. Com uma conta, você pode executar, editar e visualizar o código. Há uma interface para ajuste de parâmetros.

https://codeocean.com/2018/09/07/polyline-approximation-with-arcs-and-segments/code

Estou trabalhando em um verdadeiro plotter de arco eficiente no firmware da minha impressora 3D. Este é um bom momento. :+1:

@phord Isso é muito legal, continuo trabalhando no reconhecimento. Quer algumas amostras para experimentar o seu trabalho? Eu poderia fornecer gcodes de 1 camada para tentar. @TheThirdOne Como está indo?

@PurpleSensation Claro. Você pode me enviar versões arc e não arc do mesmo arquivo? Dessa forma, posso comparar para garantir que estamos interpretando as coisas da mesma maneira.

Sobre isso, você emite arcos com centro I,J ou com raio R? Estou planejando dar suporte a ambos, mas me pergunto o quão útil R é, realmente.

@phord Eu teria que começar a trabalhar em um script de geração de gcode primitivo, é um trabalho fácil. Eu posso implementar ambos, trabalho fácil. Você vai usar uma caneta para a impressão monocamada ou quer que eu adicione extrusão? Eu não sei a matemática sobre inércia de extrusão e outras coisas.

Não há necessidade de extrusão; Vou começar simulando. Eu pensei que você estava trabalhando em alguma conversão do código G existente para adicionar arcos, certo? Então eu pensei que você teria ambos em seus testes. Você quer que eu lhe envie algum código G linear com muitos arcos para converter? Eu tenho alguns. :-D

https://gist.githubusercontent.com/phord/02c87e5c60c744f3998c7ee3cde0a419/raw/6611c6e7eaef8f803467f82e744bf1c1373babd7/Pure2-lego.gcode

Este código G tem muitos arcos, mas eles são cortados com pequenas facetas. Outros podem usar menos facetas e também podem ser bons casos de teste.

Oh, eu vejo. Foi @TheThirdOne que está trabalhando nas conversões de código g. Desculpe por confundir vocês dois.

@PurpleSensation , estive ocupado com outras coisas por um tempo. Eu queria fazer algum tempo para pegar isso de volta.

@phord dê uma olhada na cápsula de código https://codeocean.com/2018/09/07/polyline-approximation-with-arcs-and-segments/code.

Com pouquíssimos ajustes, você pode modificar o script de formatação (dentro do script FitPolyline) para escrever instruções de gcode. Eu vou fazer isso eventualmente, mas agora estou ocupado com o curso inicial.

tudo isso parece interessante e eu estava procurando por g2 g3 em um slicer. Também descobri que é fundamental detectar arcos em um ambiente de polilinha (stl) antes de ser confirmado neste post. eu pensaria em uma maneira de dizer se 3 linhas consecutivas compartilham um raio tangencial comum e têm aproximadamente o mesmo comprimento, poderia ser um arco? mas como isso poderia ser calculado?

Eu também sugeriria que caminhos ou segmentos de caminho (linhas) possam ser selecionados e "marcados como arco" para que o slicer tenha mais informações sobre onde g2/g3.

@leozolt há uma ramificação no fork do @TheThirdOne GitHub onde o trabalho estava sendo feito para colocá-lo no Slic3r.

existe um formato de arquivo que pode ser usado pelo slic3r para comunicar 3d com arcos? stl é linhas apenas se me lembro bem.

@leozolt não, e é por isso que o trabalho de @PurpleSensation foi solicitado.

Se alguém quiser construir um substituto para TriangleMesh e o código baseado em polígono relacionado para poder usar STEP ou algo relacionado.

Não tenho tempo para codificar a coisa no slic3r, mas conheço alguém que pode ser. Eu vou dizer a ele. O que devo explicar a ele? Não conheço a estrutura do slic3r. Isso seria um script de pós-processamento?

@PurpleSensation seria uma extensão de https://github.com/slic3r/Slic3r/blob/master/xs/src/libslic3r/PrintGCode.cpp muito provavelmente.

https://github.com/TheThirdOne/Slic3r/tree/arc-fitting é provavelmente uma boa linha de base inicial (dê uma olhada nestes arquivos tocados nesse branch), e eu esperaria que os autotestes fossem escritos de acordo com as expectativas de como o ajustador de arco funcionaria para algumas geometrias de exemplo.

Oi
Eu tenho trabalhado em um detector de curva gcode para implementar arcos de código G2 e G3 por um tempo, e parece estar indo bem e para completamente de gaguejar por USB.
Um exemplo da mudança que pode fazer:
G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.84105
G1 X117.874 Y63.038 E5.94500
G1 X118.846 Y63.205 E6.05141
G1 X119.789 Y63.405 E6.15536
G1 X120.745 Y63.645 E6.26177
G1 X121.670 Y63.915 E6.36572
G1 X122.606 Y64.226 E6.47213
G1 X123.508 Y64.565 E6.57608
G1 X124.417 Y64.947 E6.68248
G1 X125.290 Y65.353 E6.78644
G1 X126.168 Y65.803 E6.89284
G1 X127.009 Y66.274 E6.99679
G1 X127.850 Y66.788 E7.10320
G1 X128.652 Y67.322 E7.20716
G1 X129.452 Y67.898 E7.31356
G1 X130.212 Y68.491 E7.41751
G1 X130.966 Y69.126 E7.52392
G1 X131.679 Y69.775 E7.62787
G1 X132.383 Y70.465 E7.73428
G1 X133.044 Y71.166 E7.83823
G1 X133.507 Y71.694 E7.91402
G1 X134.301 Y72.656 E8.04857
G1 X134.892 Y73.445 E8.15498
G1 X135.441 Y74.237 E8.25893
G1 X135.971 Y75.068 E8.36534
G1 X136.458 Y75.900 E8.46929
G1 X136.924 Y76.769 E8.57570
G1 X137.347 Y77.635 E8.67964
G1 X137.746 Y78.537 E8.78605
G1 X138.102 Y79.432 E8.89001
G1 X138.431 Y80.361 E8.99641
G1 X138.718 Y81.281 E9.10036
G1 X138.977 Y82.233 E9.20677
G1 X139.194 Y83.171 E9.31072
G1 X139.379 Y84.140 E9.41713
G1 X139.524 Y85.092 E9.52108
G1 X139.636 Y86.072 E9.62749
G1 X139.709 Y87.033 E9.73144
G1 X139.746 Y88.018 E9.83784
G1 X139.746 Y88.982 E9.94180
G1 X139.709 Y89.967 E10.04821
G1 X139.636 Y90.928 E10.15215
G1 X139.524 Y91.908 E10.25856
G1 X139.379 Y92.860 E10.36252
G1 X139.194 Y93.829 E10.46892
G1 X138.977 Y94.767 E10.57287
G1 X138.718 Y95.719 E10.67928
G1 X138.431 Y96.639 E10.78323
G1 X138.102 Y97.568 E10.88964
G1 X137.746 Y98.463 E10.99359
G1 X137.347 Y99.365 E11.10000
G1 X136.924 Y100.231 E11.20395
G1 X136.458 Y101.100 E11.31036
G1 X135.971 Y101.932 E11.41431
G1 X135.441 Y102.763 E11.52072
G1 X134.892 Y103.555 E11.62466
G1 X134.301 Y104.344 E11.73107
G1 X133.694 Y105.092 E11.83503
G1 X133.044 Y105.834 E11.94143
G1 X132.383 Y106.535 E12.04538
G1 X131.679 Y107.225 E12.15179
G1 X130.966 Y107.874 E12.25574
G1 X130.212 Y108.509 E12.36215
G1 X129.452 Y109.102 E12.46610
G1 X128.652 Y109.678 E12.57250
G1 X127.850 Y110.212 E12.67646
G1 X127.009 Y110.726 E12.78287
G1 X126.168 Y111.197 E12.88682
G1 X125.290 Y111.647 E12.99322
G1 X124.417 Y112.053 E13.09718
G1 X123.508 Y112.435 E13.20358
G1 X122.606 Y112.774 E13.30754
G1 X121.670 Y113.085 E13.41394
G1 X120.745 Y113.355 E13.51789
G1 X119.789 Y113.595 E13.62430
G1 X118.846 Y113.795 E13.72825
G1 X117.874 Y113.962 E13.83466
G1 X116.919 Y114.089 E13.93861
G1 X115.938 Y114.182 E14.04502
G1 X114.976 Y114.237 E14.14897
G1 X113.990 Y114.255 E14.25538
G1 X113.026 Y114.237 E14.35933
G1 X112.042 Y114.181 E14.46573
G1 X111.083 Y114.090 E14.56969
G1 X110.105 Y113.960 E14.67609
G1 X109.156 Y113.797 E14.78004
G1 X108.191 Y113.593 E14.88645
G1 X107.256 Y113.358 E14.99040
G1 X106.310 Y113.082 E15.09681
G1 X105.396 Y112.777 E15.20076
G1 X104.738 Y112.530 E15.27655
G1 X103.584 Y112.057 E15.41110
G1 X102.690 Y111.642 E15.51751
G1 X101.832 Y111.203 E15.62146
G1 X100.972 Y110.720 E15.72787
G1 X100.150 Y110.218 E15.83182
G1 X99.329 Y109.672 E15.93822
G1 X98.547 Y109.108 E16.04218
G1 X97.770 Y108.502 E16.14859
G1 X97.033 Y107.881 E16.25254
G1 X96.304 Y107.218 E16.35895
G1 X95.616 Y106.543 E16.46289
G1 X95.134 Y106.032 E16.53868
G1 X94.304 Y105.101 E16.67324
G1 X93.683 Y104.335 E16.77964
G1 X93.105 Y103.564 E16.88359
G1 X92.543 Y102.754 E16.99000
G1 X92.025 Y101.941 E17.09395
G1 X91.670 Y101.335 E17.16974
G1 X91.072 Y100.241 E17.30430
G1 X90.639 Y99.355 E17.41070
G1 X90.249 Y98.474 E17.51465
G1 X89.885 Y97.558 E17.62106
G1 X89.563 Y96.649 E17.72501
G1 X89.269 Y95.708 E17.83142
G1 X89.017 Y94.778 E17.93537
G1 X88.795 Y93.818 E18.04178
G1 X88.614 Y92.871 E18.14573
G1 X88.465 Y91.896 E18.25214
G1 X88.356 Y90.939 E18.35609
G1 X88.281 Y89.956 E18.46250
G1 X88.245 Y88.993 E18.56645
G1 X88.245 Y88.007 E18.67285
G1 X88.281 Y87.044 E18.77680
G1 X88.356 Y86.061 E18.88322
G1 X88.465 Y85.104 E18.98716
G1 X88.571 Y84.409 E19.06295
G1 X88.795 Y83.183 E19.19750
G1 X89.017 Y82.222 E19.30392
G1 X89.269 Y81.292 E19.40786
G1 X89.563 Y80.351 E19.51427
G1 X89.885 Y79.442 E19.61822
G1 X90.249 Y78.526 E19.72463
G1 X90.639 Y77.645 E19.82858
G1 X91.072 Y76.759 E19.93499
G1 X91.527 Y75.910 E20.03894
G1 X92.025 Y75.059 E20.14535
G1 X92.543 Y74.246 E20.24930
G1 X93.105 Y73.436 E20.35570
G1 X93.651 Y72.707 E20.45399
G1 E17.45399 F12000.00000

torna-se:
G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.841
G3 X93.651 Y72.707 I-2.924 J25.589 E20.454
G1 E17.45399 F12000.00000

Se você estiver interessado no código, posso fazer o upload para o GitHub, se quiser (embora seja bastante bruto no momento, parece fazer o trabalho).

Olá,

Estou muito interessado no seu conversor G1 para G2/G3. Infelizmente não posso executá-lo.

Minha maneira de executar o software está correta?
Eu pego o index.php e arrasto e solto no Firefox.

Agora eu tenho uma página que me pede para procurar um arquivo .gcode.
Eu seleciono meu GCODE no HDD e clico em Enviar.

Agora ele me pede novamente para procurar um arquivo GCODE.

O que estou fazendo de errado? Eu não recebo um arquivo convertido.

Saudades da Alemanha

Alguma sorte até agora recebendo suporte ARC adequado 9 anos depois? Concordo que melhoraria muito as impressões.

Eu acho que o suporte de arco precisa de uma aceleração de curva s adequada para ter bons resultados que devem resultar em cavacos mais fortes. Eu sei que está fora do tópico, mas o suporte a arco em combinação com movimentos de impressão 3D não plana deve ser o próximo nível em alguns anos para impressoras fdm.
Eu gostaria de ter mais alguns pensamentos sobre isso, vamos começar uma discussão.
No entanto, qual mecanismo de um slicer existente seria a melhor base para iniciar tal implementação? Há um tópico no projeto cura onde um dos desenvolvedores disse que teria que redesenhar todo o motor; ele foi projetado para trabalhar camada por camada.

Oi, eu tenho trabalhado no tema há vários anos profissionalmente. A segmentação 3D já existe, só precisamos de alguém fazendo uma implementação. Infelizmente, não posso assumir essa tarefa por estar muito ocupado, mas posso ajudar com os algoritmos.

Revivendo

A questão é: Como tal recurso seria implementado (no núcleo principal ou como programa externo/biblioteca/plugin/....) e quais são os ingredientes? Uma coisa é, claro, a detecção de arco da perspectiva matemática/algorítmica. A segunda coisa é como conectar as coisas no Slic3r. Alguém implementando isso pode usar o suporte da equipe de desenvolvimento principal (como como integrar no resto do sistema)?

@PurpleSensation O que teria que ser implementado? Se as coisas forem um pouco confidenciais, você pode encontrar um endereço de e-mail no meu perfil do Github. Eu gostaria de dar uma olhada rápida nas coisas se eu puder ajudar aqui um pouco.

Mmmmmm, definitivamente não sou um engenheiro de software e tenho pouca ideia de como integrar isso ao núcleo principal. O ideal seria codificar os métodos em um nível baixo e não como uma coisa de pós-processamento, mas isso é uma possibilidade. Alguém entrando em experimentação é tudo o que precisamos. Posso fornecer os algoritmos codificados em python/MATLAB. A primeira abordagem seria aplicar apenas em perímetros.

Eu sou capaz tanto de Mathlab quanto de C++. Então, meu pensamento pessoal é que talvez seja melhor seguir este caminho: Reimplemente o algoritmo proposto como uma "biblioteca" em C++. Isso permite testes e todas as coisas extravagantes. Como os arquivos STL são apenas poliedros/politopos. Portanto, as informações do arco já foram perdidas durante a conversão de CAD para STL. Portanto, pode ser melhor trabalhar em cada camada independentemente para detectar quaisquer arcos.
Um segundo passo seria implementar isso na GUI e fazer com que a funcionalidade fosse usada pelo Slic3r.

Para minha própria referência veja aqui .

Eu entendo o seu ponto. No próximo ano, talvez eu tenha algum tempo extra para trabalhar nisso (também, preciso de uma nova impressora porque meu delta auto-fabricado está em péssimas condições). Se alguém (como você) quiser minha assistência direta e o código original, estou mais do que satisfeito. Além disso, como estou trabalhando com C++ agora para meu doutorado, talvez eu mesmo construa essa biblioteca. Espero que esta questão seja empurrada para a frente.

@christianlupus o trabalho feito por @PurpleSensation envolveu um algoritmo para ajuste de curva em 2d.

Veja GCode.cpp em libslic3r. O Slic3r tem todos os polígonos já presentes em cada camada (e cada camada é feita em paralelo) conforme lido do modelo 3d como ExtrusionEntities.

Quando eu olhei para ele pela última vez, era mais trabalho do que eu estava disposto a colocar nele (especialmente porque eu quero testes reproduzíveis), e ainda há algumas suposições envolvidas com a cláusula de rescisão.

Meus pensamentos sobre o assunto eram implementá-lo em GCodeWriter (uso imediato) ou detectar os arcos de polígonos incorporados ExtrusionEntities e estender Polyline, etc. para armazenar as informações do arco para renderização posterior com GCodeWriter.

A saída SVG é provavelmente um bom lugar para começar, para ser honesto, pois lhe dará uma representação mais clara de como o Slic3r a vê (e esse código tem menos coisas acontecendo).

Qualquer teste que você escrever pode testá-lo em libslic3r, sem necessidade de reinventar seus primitivos.

@FormerLurker está trabalhando em https://github.com/FormerLurker/ArcWelderPlugin , um plugin Octoprint que pós-processa arquivos carregados para gerar arcos; acho que o algoritmo principal já está em C, então portar o código pode ser viável?

@floppy , a versão do console já pode ser usada como pós-processador, fyi.

@Floppy , também, você pode querer ver ArcWelderLib , que contém o aplicativo de console e vários scripts CMake (não verificados em todos os sistemas operacionais). Tenho alguns commits para manter o caso e a formatação consistentes, que farei nos próximos dias.