Vinyl Cutter
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
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.
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
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
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.
PyCAM
- importar modelo
- File -> Open model...
- configuração de ferramenta
- adicionar uma ferramenta (aba tools) com d=0.1 (blue plunger tip na maquininha)
- exportar gcode