Projecto Freza CNC - Arduino

[c3dr1c]

Ganda porcaria... La terei de desencatar o meu amd athlon la do sotao e ver se funca...

Mas andei a pesquisar e encontrei umas boards baseadas num microcontrolador que permitem usar o mach3 por usb... Tem depois de se instalar um plugin no mach3..

Tipo isto:


Se calhar com um atmega tambem daria, nao deve é ser facil de programar...

[senso]

Um atmega nunca, quanto muito um AtXmega para ter usb nativo, mas não me parece..
O grande problema do USB é que não te garante tempo de entrega dos dados, enquanto que paralelo sim, o que tu não queres é perder dados e ter tempos variaveis num sistema sincrono..
Esse AT91SAM é um cortex m3 se não estou em erro, possivelmente a implementar uma ponte usb-paralelo, com um cpld a tratar de gerar o timing sincrono para controlar os sinais de set/dir e mais umas coisas para bater tudo certinho.

[StarRider]

Boas,

É possível garantir/reservar uma determina largura de banda nas comunicações USB usando transferências Isócronas e
configurando os endpoints para tal durante o processo de enumeração.

Teoricamente (e na pratica) é possível controlar um device externo com timings críticos da mesma forma que o é possível
com uma porta LPT.  Alias, no Windows é mesmo mais fiável usar o payload de um endpoints Isócrono para enviar dados
em intervalos de tempo garantidos do que a implementação LPT deste SO, por isso é que programas que necessitam
de uso exclusivo da porta LPT (como o Mach) necessitam de um driver especifico para a porta paralela.

Existem interpretadores de G-code que comunicam "nativamente" com os driver dos motores por USB, o problema do
Mach é que é nativo para portas paralelas, e os adaptadores USB->LPT usam transferências (e endpoints) BULK na sua
implementação USB, e estes não são de forma alguma adequados para operações em que os timings são paramount.

Abraços,
PA

[jm_araujo]

Já deram uma vista de olhos ao GRBL?
É um interpretador de gcode para arduino/atmega open-source, e é utilizado em alguns projetos como por exemplo o shapeoko.
Estou a acabar uma espécie de pico-"CNC" de brincar feita com drives DVD velhos e outros restos, experimentei o GRBL e tem funcionado bem. Quando a acabar mostro no forum.

Peço desculpa, não estive a ler as 25 páginas do tópico, pelo que peço desculpa se já foi descartada esta possibilidade

[c3dr1c]

Isto é uma grande limitação para computadores mais recentes. Tambem comprar uma placa das que postei é muito caro.

Esse GRBL é rapido? O problema do meu "software" programado em Labview é que fica muito lento (10ms entre cada passo de stepper), mas nao consigo fazer melhor. Alem disso sei perfeitamente que tem algumas limitações e necessitava de mais programação em cima...

O Mach 3 é muito bom que tem bastantes definições possiveis de configurar, mas pronto a nao ser que utilize um pc mais velho, acho que nao vou usar... Não me apetece andar com um CRT atrás de mim nem investir um LCD.

Ja não é a primeira vez que questiono sobre o USB e MAch 3 e parece que nao dá mesmo, desisto... Vou-me virar para os freeware

Obrigado mais uma vez pela vossa ajuda.

[senso]

Placa PCI com porta-paralela, sem problema algum.
Ou uma board mini pc da intel, por 100€ têm um computador completo em formato mini-itx com processador core 2 duo ou i3, com 2Gb ou mais de RAM, com sata, usb, vga, som, serial, DB25 e mais, pode parecer um pouco caro, mas é um pc a sério, e não um brinquedo tipo RPi, ou qualquer outra placa arm da cena..

[jm_araujo]

Esse GRBL é rapido?

Sim. Segundo os programadores, consegue um step rate superior a 30khz.
No projeto que estou a fazer, tive de limitar as acelerações para que os motores não perdessem passos.  No meu caso a velocidade máxima não chega a ser problema pelas reduzidas dimensões.

[c3dr1c]

Então mas como raio um software em ambiente windows consegue velocidades tão altas? Eu no labview so consigo utilizar periodos de 1ms, no minimo... Em outros softwares será que da para utilizar us? Ou existe outra maneira de fazer as coisas?

[senso]

Fast, cheap or good, pick two....
Queres que o labview seja mais facil de programar que brincar com legos e ao mesmo tempo mais rápido que código compilado e optimizado.

[CBX]

o grbl está escrito em C e está optimizado, o PC simplesmente manda o GCODE para a ram do microcontrolador, o firmware é que faz a magia

podes confiar no grbl, é a base de alguns dos melhores firmwares de impressoras 3d

[c3dr1c]

Ah nao tinha percebido que teria de usar um microcontrolador. Mas claro que tem, tem de descodificar os dados vindo por USB, que burrice da minha parte 

Pois o labview é muito simples, mas é porreiro. Mas no laview tambem poderia programar algo que mandasse o numero de passos, a direcção e a frequencia de cada motor para um micro e depois o micro informava o labview que ja tinha chegado ao destino.

[Willianme]

Estava lendo o seu tópico e gostei bastante do seu projeto, parabéns pela trajetória.

[c3dr1c]

Obrigado.

Bem, mais um passo dado. Montagem dos motores, varões roscados e blocos roscados...

E problemas para começar a resolver O varão roscado custa tanto a rodar manualmente, nem deve rodar com o motor. Tenho de eliminar atritos entre o varão e o bloco de nylon.

[dropes]

Devia estar solto o varão roscado, não entendo muito de nylon se calhar devias usar teflon, tem menor atrito é resistente e não derrete com o calor.
Para acompanhar: http://www.decathlon.pt/pesquisar/5182709-lubrificantes-teflon-aerossol-1.html

[c3dr1c]

Sem o bloco o varão roda bem. O problema é mesmo o bloco, mas nada que mais umas passagens com um macho M10 não resolva. Amanha já trato disso.

Teflon é muito caro