Vinyl Cutter

De Garoa Hacker Clube
Revisão de 09h24min de 27 de setembro de 2013 por Ceci (discussão | contribs) (→‎Workshops)
Ir para navegação Ir para pesquisar

Workshops

Liste seu nome abaixo caso você tenha interesse em participar de um workshop de operação da máquina de corte de adesivos.

  • Vitor Fernandes
  • Rafael M. Lopes
  • William Lima
  • Alexandre Vecchio
  • Tiago Anjo Santana
  • Alexandre Souza
  • Ceci

Vinyl cutter voltando a dar sinais de vida

Galera!

Troquei a placa mãe da máquina de corte de vinil por uma placa Sanguinololu (que era de uma Metamáquina 3D, mas que bixou: estourou o capacitor do driver de motor de passo do extrusor). Como a placa tem 4 drivers de motor de passo (para X, Y, Z e E=extrusor) mas a máquina de corte de adesivos precisa apenas de 2 (X e Y), rola usar essa placa bichada mesmo.

Botei o Sprinter (um firmware livre de impressora 3D) nela e liguei na maquininha e consegui controlar a vinylcutter usando o Pronterface (um painel de controle livre usado em impressoras 3D). Agora estou levantando as características da polia e da correia do X pra fazer o cálculo adequado de steps_per_mm pra configurar o firmware direitinho com a calibração pra nossa máquina. Depois terei que estudar e/ou desenvolver algum gerador de gcode a partir de SVG. Outro desafio será interfacear com o solenóide da faca e com o fim-de-curso. O problema é que eles eram ligados na placa original por meio de circuito flexível e é um inferno interfacear com isso. E depois tem também os botões do painél e o display LCD pra serem explorados. Mas por enquanto meu foco é fazer essa máquina cortar um adesivo usando apenas software livre! :-D

happy hacking,

Felipe "Juca" Sanches

03/Maio/2013

detalhes técnicos

ajustes de firmware (Sprinter)

https://github.com/GaroaHC/Firmware-Vinyl-Cutter

  • Curso do eixo X = 290 cm
  • cerca de 125 passos por milímetro no eixo X (levantado empiricamente)
  • feedrate máximo de cerca de 5000 mm/min (empírico)
  • homing em direção ao endstop XMAX
  • endstop XMIN virtual

pinagem do carro X e faca

O Endstop XMAX e o solenóide da faca estão ligado em uma via de circuito flexível com 12 sinais. Segue abaixo descrição dos sinais descobertos:

00 01 02 03 04 05 06 07 08 09 10 11
X+  ?  ?  ?  ? X+  ?  A  A  B  B  ?
  • X+ = endstop XMAX
  • A/B terminais do solenóide da faca de corte

HACK! Estou usando um terminal de circuito flexível removido de um laser de CDROM e retrabalhado na dremel (fiz uns furos e soldei uns pinos aos pontos de interesse no conector), para interfacear com a Sanguinololu usando jumper-wires.

pinagem do LCD

Victor e Bruno fizeram. O papel ficou com alguém após a atividade.

status do projeto

04/Maio/2013 03h45am

Homing do eixo X já está funcionando tanto com o endstop real (microswitch XMAX) quanto com o endstop virtual (XMIN) respeitando o curso total de 290mm.

04/Maio/2013 11h32pm

Acabo de cortar um belo adesivo! :-)

A Vinyl Cutter do Garoa voltou a funcionar, e agora 100% software livre! Nas próximas semanas pretendo aprimorar o workflow para uso da máquina. Estou com algumas idéias para automatização do processo. Por enquanto, cortar adesivos só se for no modo "piloto de avião"... Mas o que importa é que agora FUNFA!!!

happy hacking,

Felipe "Juca" Sanches

05/Mai/2013 02h02am

Próximos passos:

  • fazer endstop XMAX e solenóide da faca funcionarem simultaneamente. O design da Sanguinololu e o design do cabeamento da máquina são incompatíveis. Se eu ligar as duas coisas ao mesmo tempo, o resultado será um curto-circuito. Pra resolver isso eu acho que eu teria que fazer meu próprio circuito com MOSFET levando em consideração que o solenóide e o endstop compartilham um terminal de terra.
  • usar endstop mínimo virtual apenas no eixo X. No momento o Y também está limitando movimentação para coordenadas menores que Y=0. Isso atrapalha um pouco na hora de alimentar a máquina com uma folha de adesivo.
  • arranjar uma fonte de alimentação que dê conta do recado sem superaquecer. A que estou usando fica bem quente, uma hora chegou até a subir um cheiro de plástico derretido e desliguei pra deixar ela descansar...
  • transformar toda a gambiarra em um shield de arduino bem organizadinho e que caiba dentro da máquina. Fechar a carcaça da máquina e deixar ela num estado que as pessoas possam utilizar sem ter medo de soltar fios ou dar curto.
  • gerar gcode via linha de comando. No momento eu gero pela GUI do pycam. Gerar pela linha de comando é o passo número zero para automatizar esse processo.
  • fazer o gcode gerado ser compatível com o Sprinter. No momento o gcode usa uma sintaxe de abreviação que o Sprinter não entende. Há duas soluções possíveis: 1) alterar o pycam para gerar gcode com a sintaxe que o Sprinter espera. ou 2) modificar o Sprinter pra entender a sintaxe que o pycam usa.
  • O Pronterface é um painel de controle para impressoras 3D. Estou usando ele pra controlar a vinyl cutter em jog-mode e também para visualizar o gcode gerado e enviá-lo à máquina. No pronterface, quando você abre um arquivo STL ele automaticamente invoca um fatiador (skeinforge, slic3r, etc) pra gerar gcode. Seria muito bacana adaptar o Pronterface para que ele invoque o pycam quando for aberto um arquivo vetorial 2d em DXF ou SVG.
  • fazer uma extensão para o Inkscape que gere gcode usando os scripts de linha de comando (e se bobear usar o Printrun pra já mandar a impressora cortar um adesivo diretamente de dentro do Inkscape)
  • interfacear com o display LCD e botões (esquerda, direita, OK) da máquina para exibir mensagens de status (o Sprinter já tem suporte a interface em LCD e painel de botoes)
  • fazer um jog-mode direto na máquina usando o painel de botoes e LCD
  • instalar uma extensão de cartão SD na Sanguinololu (já existem kits prontos pra isso e o firmware já suporta. É só conectar e configurar) A partir do SD dá pra carregar arquivos gcode e operar a máquina desconectado do USB. Utiliza-se o painel LCD para navegar no sistema de arquivo FAT e escolher que arquivo será executado.
  • cortar um adesivo super looooooongo, só por que agora dá! Por que agora a gente pode! :-D

Juca

geração de g-code

Estou usando o software livre pycam para gerar GCode a partir de um vetor SVG. O Gcode gerado por enquanto precisa ser pós-processado para remover comandos G que confundem o firmware Sprinter.

Configuração das abas do PyCAM

Model
nenhuma configuração adicional
File -> Open model...
Tools
adicionar uma ferramenta com d=0.1 (blue plunger tip na maquininha)
setar feedrate 5000mm/min
shape: spherical
tool diameter 0.1
Process
Selecionar process settings = Gravure
Path strategy: contour follow

Pós-processamento do Gcode

  • desnecessário: Remover todos os GCodes iniciais (que não são de coordenada) exceto o G21 e o G90
  • desnecessário:Colocar o F5000 ao final da primeira instrução G1 ou G0
  • Expressões regulares usadas no emacs: ^ X --> G1 X e ^ Y --> G1 Y

OBS.: No caso dos passos marcados como desnecessários o firmware consegue interpretar o g-code numa boa mesmo sem as alterações propostas.

TODO: decidir sobre a melhor solução para obtermos um GCode compatível com o Sprinter

  • Alterar o Sprinter
  • Alterar o PyCAM
  • Fazer um script