Guia CNC Brasil - Tudo sobre CNC, Router, Laser, Torno e 3D Print
ELETRÔNICA / ELÉTRICA => Drivers => Eletrônica Básica => HobbyCNC => Tópico iniciado por: sijoga em 27 de Dezembro de 2013, 07:52
-
Bom dia a todos do guiacnc, venho por meio deste topico solicitar ajuda com a configuração do programa mach3 ou o turbocnc, pois nos 2 programas minha cnc apresenta o mesmo problema, ela apenas funciona no modo jog no programa "RoutOut Manager V 3.5", o problema é o seguinte, quando eu entro no modo jog do mach3 ou turbocnc, e mando o comando para ir para um lado ou para outro, o carro começa a se deslocar e nao para mais, só muda de direção se eu clicar para o lado contrario do que ele esta indo, isso para o x ou y, acontece a mesma coisa para os dois, estou usando o arduino, 2 cis unl2003, 2 motores de passo unipolar de impressora, com o arduino eu consigo ler a porta paralela, com o programa parallel por do site do rogercom eu consigo ligar e desligar os pinos que eu quero q no caso são 2 e 6 para x, e 3 e 7 para y, isso primeiro numero é o passo e o segundo é a direção, com esse prog eu consigo fazer ela andar tambem sem problemas, o problema é que no mach3 e turbocnc eu dou o comando para um passo e o motor nao para mais de andar, não sei se esta configurado algo errado no programa, estou com duvida na configuraçao do motor tuning no mach3, pode ser q seja ali que eu esteja errando, os 2 motores q uso são de 12V e 1.8º o angulo de giro, mas estou usando eles com uma fonte de pc e estou alimentando os 2 com 5v para eles e nem o ci 2003 aquecerem.
Se tiver algum manual ou tutorial sobre esse tipo de configuraçao eu agradeço muito, vou postar o codigo do meu arduino, pois pode estar nele o problema que estou tendo.
desde ja agradeço pela atenção de todos.
#include <Stepper.h>
int pino14 = 14;
int pino15 = 15;
int pino16 = 16;
int pino17 = 17;
Stepper motor1(200, 4, 5, 6, 7);
Stepper motor2(200, 8, 9, 10, 11);
void setup(){
Serial.begin(9600);
pinMode(pino14, INPUT);
pinMode(pino15, INPUT);
pinMode(pino16, INPUT);
pinMode(pino17, INPUT);
digitalWrite(pino14, HIGH);
digitalWrite(pino15, HIGH);
digitalWrite(pino16, HIGH);
digitalWrite(pino17, HIGH);
}
void loop(){
int x = digitalRead(pino14);
int y = digitalRead(pino15);
int dirx = digitalRead(pino16);
int diry = digitalRead(pino17);
Serial.println(x);
Serial.println(y);
Serial.println(dirx);
Serial.println(diry);
if (x == LOW && dirx == LOW){
motor1.setSpeed(20);
motor1.step(1);
}
if (x == LOW && dirx == HIGH){
motor1.setSpeed(20);
motor1.step(-1);
}
if (y == LOW && diry == LOW){
motor2.setSpeed(40);
motor2.step(1);
}
if (y == LOW && diry == HIGH){
motor2.setSpeed(40);
motor2.step(-1);
}
}
-
Bom dia a todos do guiacnc, venho por meio deste topico solicitar ajuda com a configuração do programa mach3 ou o turbocnc, pois nos 2 programas minha cnc apresenta o mesmo problema, ela apenas funciona no modo jog no programa "RoutOut Manager V 3.5", o problema é o seguinte, quando eu entro no modo jog do mach3 ou turbocnc, e mando o comando para ir para um lado ou para outro, o carro começa a se deslocar e nao para mais, só muda de direção se eu clicar para o lado contrario do que ele esta indo, isso para o x ou y, acontece a mesma coisa para os dois, estou usando o arduino, 2 cis unl2003, 2 motores de passo unipolar de impressora, com o arduino eu consigo ler a porta paralela, com o programa parallel por do site do rogercom eu consigo ligar e desligar os pinos que eu quero q no caso são 2 e 6 para x, e 3 e 7 para y, isso primeiro numero é o passo e o segundo é a direção, com esse prog eu consigo fazer ela andar tambem sem problemas, o problema é que no mach3 e turbocnc eu dou o comando para um passo e o motor nao para mais de andar, não sei se esta configurado algo errado no programa, estou com duvida na configuraçao do motor tuning no mach3, pode ser q seja ali que eu esteja errando, os 2 motores q uso são de 12V e 1.8º o angulo de giro, mas estou usando eles com uma fonte de pc e estou alimentando os 2 com 5v para eles e nem o ci 2003 aquecerem.
Se tiver algum manual ou tutorial sobre esse tipo de configuraçao eu agradeço muito, vou postar o codigo do meu arduino, pois pode estar nele o problema que estou tendo.
desde ja agradeço pela atenção de todos.
#include <Stepper.h>
int pino14 = 14;
int pino15 = 15;
int pino16 = 16;
int pino17 = 17;
Stepper motor1(200, 4, 5, 6, 7);
Stepper motor2(200, 8, 9, 10, 11);
void setup(){
Serial.begin(9600);
pinMode(pino14, INPUT);
pinMode(pino15, INPUT);
pinMode(pino16, INPUT);
pinMode(pino17, INPUT);
digitalWrite(pino14, HIGH);
digitalWrite(pino15, HIGH);
digitalWrite(pino16, HIGH);
digitalWrite(pino17, HIGH);
}
void loop(){
int x = digitalRead(pino14);
int y = digitalRead(pino15);
int dirx = digitalRead(pino16);
int diry = digitalRead(pino17);
Serial.println(x);
Serial.println(y);
Serial.println(dirx);
Serial.println(diry);
if (x == LOW && dirx == LOW){
motor1.setSpeed(20);
motor1.step(1);
}
if (x == LOW && dirx == HIGH){
motor1.setSpeed(20);
motor1.step(-1);
}
if (y == LOW && diry == LOW){
motor2.setSpeed(40);
motor2.step(1);
}
if (y == LOW && diry == HIGH){
motor2.setSpeed(40);
motor2.step(-1);
}
}
Acho que o colega está fazendo uma "salada", o que tem a ver a porta paralela do PC, um Arduino, o Mach3, o TurboCNC e o seu programa para Arduino?
-
Bom dia amigo, obrigado por tentar me ajudar, vou tentar simplificar para que alguem possa me ajudar, estou descrevendo todos os programas que estou usando para mostrar que o problema esta na configuraçao do mach3 ou turbocnc, qualquer um resolve o meu problema, entao se alguem tiver afinidade com qualquer um dos 2 e puder me explicar ja ajuda, quando ao arduino estou usando ele pq nao tenho nenhum drive controlador de motor de passo, pelo que andei lendo esses programas mach3 e turbo cnc, manda um sinal para o passo e um sinal para direçao do motor de passo, o que eu fiz foi programar o arduino para reconhecer esse pulso e passar para o motor de passo, o problema é que a porta paralela quando manda o pulso, tipo se esta 0 ela manda 1, dai o motor anda, só que quando a porta paralela manda o 1 ela não volta para 0 e por isso o motor nao para de andar, se eu reprogramo o arduino ao contrario, se a porta paralela esta 1 e o programa manda 0 entao o mortor anda, mas a porta nao volta para 1, e por isso o motor continua andando, quero saber se é possivel fazer essa configuraçao no programa para que ele mande o pulso para a porta e a porta retorne para o estado que ela estava antes do pulso.
-
Eu acho que você errou no tópico. O certo seria:
"Problemas com meu Arduino"
Um conselho útil. Depois mando o número da minha conta bancária para você pagar por essa consulta.
Deixe de inventar coisas. Compre um Drive baratinho, talvez o TB6560 e brinque a vontade.
Edson
-
Amigo meu problema ainda não foi solucionado, seguinte, porque comprar um drive se o arduino pode ser programado da mesma forma, e a questão aqui não é o arduino, pois se eu colocar um drive vai acontecer a mesma coisa, pois o pulso da lpt1 esta ficando no mesmo estado como se o botão da direção estivesse precionado.
A questão é se é possivel controlar com alguma configuração do programa para a porta depois de enviar o comando e o botao nao estar mais precisonado para que ela volte nao posição inicial, sendo que pode ser 0 ou pode ser 1 tanto faz.
-
Sua LPT é onboard ou você instalou outra placa paralela no PC?
Edson
-
Sijoga,
Qual é o seu nome?
Se você possui um PC com porta paralela, é necessário um driver de motor de passo.
O Arduino não é um driver de motor de passo. Mas, se fosse usar um Arduino com essa finalidade, o seu programa precisa ser bastante corrigido, pois está completamente inadequado e incompleto, além disso, são necessários também transistores de potência e alguma eletrônica adicional para usar um Arduino para essa função.
Aconselho-o a adquirir um driver específico para motor de passo, sai mais barato, é mais rápido e é mais fácil para quem está iniciando no assunto.
-
Acho que antes de mais nada deveria verificar o porque está tendo problemas com o PC no momento de enviar os sinais para os drives...
Isso do movimento iniciar e não parar mais tem cara de interferência, mas pode ser também a eletrônica que está entendendo algo de errado, pois deveria parar quando o trem de pulsos pára de ser enviado...
-
O firmware deverá funcionar do jeito que está. Apenas coloque a função "Serial.printIn" dentro do "if", para minimizar o lixo na serial.
Procure por softwares que permitam setar e apagar bits da porta manualmente.
-----------------------------------------------------------------------------------------------
http://download.cnet.com/Parallel-Port-Tester/3000-2086_4-75940249.html (http://download.cnet.com/Parallel-Port-Tester/3000-2086_4-75940249.html)
-
Boa tarde, obrigado a todos pelas informações, seguinte, estou usando no meu pc, porta paralela onboar, com o mach3, e no outro pc que roda pelo boot do windows98 o turbo cnc, são 2 pcs diferentes, 2 sistemas operacionais diferentes e o mesmo problema, só estou teimando neste assunto, pois vi no youtube que um cara fez esse mesmo projeto com o arduino e deu certo, só que ele nao deixou o codigo fonte do programa dele.
como o outro amigo falou, pra usar outro programa, eu tenho o programa do rogercom que me deixa ligar pino por pino da porta paralela, e assim funciona, exemplo, se eu ligo o pino 2 o x vai somando passos, se ligo o 2 e o 6 o x vai subtraindo passos, o mesmo no y, pino 3 soma no y, pino 3 e 7 subtrai no y.
Quanto ao drive eu olhei meio por cima na internet e vejo q os valores são um tanto salgado para quem esta só curioso neste assunto, se vcs tiverem algum fornecedor de drives baratos eu agradeço.
-
Consegue postar o esquema de ligação?
-
Obrigado por ajudar amigo, vamos la, seguinte vou resumir o problema, se eu nao ligar a porta paralela no arduino, digamos que eu ligo 4 botoes, um em cada pino q é entrada do arduino, dai no outro pino do botao eu ligo no 5volts, em todos os botoes, se eu aperto o botao q faz o x andar pra +, o motor fica andando pro lado +, se eu solto esse botao o x para de andar, se eu aperto esse mesmo botao e mais o outro botao que faz o x andar pra -, o motor anda pro lado -, se eu solto os botoes o motor para de andar. até aqui nao tem problema, o problema ta no programa q manda um sinal para a paralela pro x andar pra qualquer lado, quando eu solto o botao do jog, o motor continua andando e nao para nunca mais, se eu aperto o jogo do x pro outro lado, o motor imediatamente para de andar para aquele lado e inverte a rotaçao para o outro lado, o mesmo com o eixo y.
-
agora vamos ao esquema de ligaçao, porta paralela, pino 2 liga o x, pino 3 liga o y, pino 6 inverte o movimento de x, pino 7 inverte o movimento de y, no arduino eles estao ligados na porta 14, 15, 16 e 17, respequitivamente, quando ao motor de passo esta ligado num unl2003 e esse ligado nas saidas do arduino, como esse unl2003 só tem 7 saidas eu to usando 2, um pro x e outro pro y, estou usando o passo completo, não o meio passo, quanto a ver uma foto do mesa, eu vou postar mas ta muito cheia de fios e quem ja viu gambiarra vai ficar traumatizado com essa cena, porque a cena é forte.
-
Deu para entender amigo. Porém, desconheço configuração que faça o TurboCNC ou o Mach3 continuar gerando pulsos após soltar o JOG. Como não sou especialista nesses programas, prefiro começar pelo outro lado.
Qual o comprimento do cabo entre a paralela e o Arduino?
Ligou todos os GNDs da porta?
Verificou se o pinos não estão ligados invertidos?
Você marcou "Dir LowActive" e "Step LowActive" no Mach3?
-
Opa amigo, certo vamos la, o cabo é fio de telefone de cobre coisa fina, cerca de 1,5metros de comprimento, quanto ao terra, esta ligado em um pino terra apenas, sera q pode ser isso?
Quanto aos pinos estar invertido isso nao esta pq ja testei.
-
Amigo, não é os pinos terra não, acabei de soldar todos e continua o mesmo problema, e eu me esqueci de falar, com o programa de controle da paralela, aquele q vc escolhe qual pino vc liga e desliga a mesa funciona, e quando desliga o pino a mesa para, só com esse programa q a mesa funciona "RoutOut Manager V 3.5", aqui vc clica pra ir para um lado o motor gira e para, vc clica dinovo e gira e para, é só no mach3 e turbocnc q nao funciona, o q eu penso q poderia ser, imagino uma configuração errada do comando do motor por parte de soft, e q um pulso para o motor andar não esta correto, tipo eu mando ele andar no programa 1 mm, e talves o prog manda o motor andar 100 metros, algo assim, pq o motor nao para de andar e ja logo acaba o curso da mesa, mas tipo, se minha teoria estiver certa, se eu desligar a fonte da mesa, entao o programa nao sabe e ele continua mandar o pulso at[e atingir um valor q faço o pulso terminar, só q eu ja fiz isso e o motor nao para nunca mais, cheguei a deixar meia hora e ligar a fonte novamente e o motor nao tinha parado de girar.
-
Sijoga,
Vou comentar de novo (pela última vez), o Arduino não vai funcionar como você esta planejando:
(1) Os programas que você citou (TurboCNC, Mach3) usam a porta paralela para a geração de pulsos em tempo real. O Arduino precisaria ler esses pulsos pela porta paralela e não pela porta serial, que aliás, não é veloz o suficiente para esta aplicação. A menos que espere operar os motores lentamente.
(2) Os sinais dos programas citados são de passo e direção com acionamento direto da porta (hardware) e não servem para enviar por uma porta serial, a menos que use um driver de porta serial no Mach3 ou no TurboCNC (desconheço a sua existência). Reforço a lentidão de uma porta serial.
(2) O seu programa não terá a velocidade suficiente, pois é feito em C e há várias coisas a serem feitas, que exigem conhecimento e experiência.
Pense bem..... , se quiser resolver seu problema use um driver de motor de passo.
-
Sijoga,
Vou comentar de novo (pela última vez), o Arduino não vai funcionar como você esta planejando:
(1) Os programas que você citou (TurboCNC, Mach3) usam a porta paralela para a geração de pulsos em tempo real. O Arduino precisaria ler esses pulsos pela porta paralela e não pela porta serial, que aliás, não é veloz o suficiente para esta aplicação. A menos que espere operar os motores lentamente.
(2) Os sinais dos programas citados são de passo e direção com acionamento direto da porta (hardware) e não servem para enviar por uma porta serial, a menos que use um driver de porta serial no Mach3 ou no TurboCNC (desconheço a sua existência). Reforço a lentidão de uma porta serial.
Professor, em nenhum momento ele falou que está fazendo isso pela serial.
(2) O seu programa não terá a velocidade suficiente, pois é feito em C e há várias coisas a serem feitas, que exigem conhecimento e experiência.
Pense bem..... , se quiser resolver seu problema use um driver de motor de passo.
Na verdade C não tem nada a ver com isso! E é errada a afirmação de que um programa é lento, pois foi escrito em C. Tadinha da Apple!
Realmente será lento. Muito lento... E o código possui um erro grave que o forçará ser mais lento ainda.
Mas irá funcionar e, de repente poderá ser o suficiente para a aplicação dele.
-----------
Veja isso como um aprendizado. Afinal, é fazendo merda que adubamos a vida.
-
Porque você não usa o turbo cnc direto no ULN2003 em Phase drive vai funcionar também ...
Não conheço nada de nada de arduino , mas pelo que entendi é ele que esta gerando os pulsos para o motor de acordo com o que recebe do mach correto?
Será que não é porque quando o mach muda o pulso de baixo para alto ele deu um passo , e só vai abaixar o pulso de novo quando receber outro comando de passo ?
-
Cláudio,
Professor, em nenhum momento ele falou que está fazendo isso pela serial.
Não sei se você já programou no Arduino, se você ler o programa apresentado (para Arduino) verá comandos de inicialização e de acionamento (escrita) da porta serial. Que podem ser para um esperado acionamento ou simplesmente monitoração, mas que, de qualquer modo, tornam um programa desse tipo mais lento e talvez, inadequado para acionar um motor em alta velocidade.
Na verdade C não tem nada a ver com isso! E é errada a afirmação de que um programa é lento, pois foi escrito em C. Tadinha da Apple!
Realmente será lento. Muito lento... E o código possui um erro grave que o forçará ser mais lento ainda.
Mas irá funcionar e, de repente poderá ser o suficiente para a aplicação dele.
-----------
Veja isso como um aprendizado. Afinal, é fazendo merda que adubamos a vida.
Sim, em nenhum momento excluo o aprendizado, mas me ative a pergunta de como acionar o motor de passo, da maneira e com a solução mais rápida, eficaz e mais adequada para um iniciante. Não exatamente a lingagem C, mas a biblioteca (em C) de motores de passo do Arduino é boa para iniciantes, porém acho-a lenta para um CNC, mesmo para amadores. Mas não deixa de ser uma fonte de aprendizado.
Eu uso muito C e é rápida o suficiente para muitas aplicações de automação (CNC, robótica, controle de processos, ....) se o compilador ajudar. Mas, você deve saber que a "rapidez da linguagem C" depende de várias coisas: o compilador utilizado, a competência do programador, as bibliotecas utilizadas, a velocidade do processador, ....
Finalmente, após analisados os avisos e conselhos, cada um escolhe o caminho a percorrer (mais longo, mais curto, errado, ...). Tudo é um aprendizado....
-
Me ocorreu que pode ser um problema simples de eletronica - pode ser que falte um resistor pull up ou pull down conforme o tipo de sinais que estiver usando...
-
Eu não ia fazer isso, mas aí vão algumas observações:
É importante entender como funciona a geração de pulsos pelo Mach3 o TurboCNC e o que o programa do Arduino consegue fazer.
Num programa CNC, ao gerar pulsos para mover o motor, o programa faz o sinal de STEP ser igual a 0 durante alguns poucos microssegundos e depois volta a valer 1 (+5V) durante dezenas ou até milhares de microssegundos, isso se repete uma certa quantidade de passos esperados no motor. Por outro lado, o programa postado, fica testando alguns bits de entrada do Arduino, um deles é o sinail de STEP. Ou seja:
(1) Se o programa coincidir de ler um pulso igual a zero no exato momento em que isso acontecer e não pode demorar muito para isso (apenas alguns microssegundos). Ou seja, jogue na loteria que talvez seja mais provável acertar!! Um programa desse tipo deveria utilizar ao menos interrupções do processador. Isso é beeeeeeem diferente de um L-297, por exemplo, que usa apenas circuitos lógicos discretos (="hardware puro", do tipo "bem burrinho") para gerar a movimentação e não precisa ficar testando bit nenhum. Assim, o referido programa pode até mover o motor uma vez ou outra, mas vai perder muuuuuuuuitos passos gerados pelo software. Isso é inaceitável num CNC.
(2) Um programa desse tipo deveria controlar a corrente, num arranjo chopper, medindo e controlando a corrente nas fases do motor. Isso é possível de ser feito, pois o Arduíno possui entradas analógicas, mas falta um programa adequado e veloz o suficiente. Tenho desconfiança que um Arduino dos mais simples consiga fazer isso com as bibliotecas padrão e o compilador C usual.
(3) Não usar a porta serial, a menos para a fase de testes, pois isso atrasa o programa e torna a movimentação lenta.
(4) Não foi mencionado como o motor está sendo efetivamente acionado. Ou seja, estão sendo usados transistores? Como estão ligados? Qual é a alimentação? Sem ligações corretas, "a mágica" não funciona, o motor não gira ....
São apenas alguns comentários e observações.
-
Amigo, não é os pinos terra não, acabei de soldar todos e continua o mesmo problema, e eu me esqueci de falar, com o programa de controle da paralela, aquele q vc escolhe qual pino vc liga e desliga a mesa funciona, e quando desliga o pino a mesa para, só com esse programa q a mesa funciona "RoutOut Manager V 3.5", aqui vc clica pra ir para um lado o motor gira e para, vc clica dinovo e gira e para, é só no mach3 e turbocnc q nao funciona, o q eu penso q poderia ser, imagino uma configuração errada do comando do motor por parte de soft, e q um pulso para o motor andar não esta correto, tipo eu mando ele andar no programa 1 mm, e talves o prog manda o motor andar 100 metros, algo assim, pq o motor nao para de andar e ja logo acaba o curso da mesa, mas tipo, se minha teoria estiver certa, se eu desligar a fonte da mesa, entao o programa nao sabe e ele continua mandar o pulso at[e atingir um valor q faço o pulso terminar, só q eu ja fiz isso e o motor nao para nunca mais, cheguei a deixar meia hora e ligar a fonte novamente e o motor nao tinha parado de girar.
Você está falando de situações diferentes.
Movimentando pelo JOG, mesmo que as configurações estejam erradas, ele não deveria movimentar, ou, continuar o movimento, sem estar pressionando alguma tecla.
Já movimentando por código G, pode ser que o campo "passos p/ mm" esteja com configuração errada. Experimente colocar 200.
Se não for problema usar o TurboCNC, acho que deveria seguir a solução do Eneias. Vá para phase drive. Terá melhor resultado.
-
Cláudio,
Professor, em nenhum momento ele falou que está fazendo isso pela serial.
Não sei se você já programou no Arduino, se você ler o programa apresentado (para Arduino) verá comandos de inicialização e de acionamento (escrita) da porta serial. Que podem ser para um esperado acionamento ou simplesmente monitoração, mas que, de qualquer modo, tornam um programa desse tipo mais lento e talvez, inadequado para acionar um motor em alta velocidade.
Você é quem está fazendo uma salada!
Referente a serial, se está escrevendo, então não tem como ser acionamento.
Gil, mais uma vez: esquece "alta velocidade". Tira isso da sua cabeça. Esse não é o foco.
E sim! É possível debugar pela serial, como ele está fazendo, sem perder o rendimento.
Na verdade C não tem nada a ver com isso! E é errada a afirmação de que um programa é lento, pois foi escrito em C. Tadinha da Apple!
Realmente será lento. Muito lento... E o código possui um erro grave que o forçará ser mais lento ainda.
Mas irá funcionar e, de repente poderá ser o suficiente para a aplicação dele.
-----------
Veja isso como um aprendizado. Afinal, é fazendo merda que adubamos a vida.
Sim, em nenhum momento excluo o aprendizado, mas me ative a pergunta de como acionar o motor de passo, da maneira e com a solução mais rápida, eficaz e mais adequada para um iniciante. Não exatamente a lingagem C, mas a biblioteca (em C) de motores de passo do Arduino é boa para iniciantes, porém acho-a lenta para um CNC, mesmo para amadores. Mas não deixa de ser uma fonte de aprendizado.
Ele não pediu nada disso. Ele quer fazer funcionar. Se vai dar certo, ele saberá testando.
Outra vez, você está se equivocando em suas afirmações. Programando em C e, utilizando essa mesma biblioteca, é possível fazer um driver que trabalhe em algumas centenas de kHz. Sei que exitem soluções mais eficientes, mas não vem ao caso.
Eu uso muito C e é rápida o suficiente para muitas aplicações de automação (CNC, robótica, controle de processos, ....) se o compilador ajudar. Mas, você deve saber que a "rapidez da linguagem C" depende de várias coisas: o compilador utilizado, a competência do programador, as bibliotecas utilizadas, a velocidade do processador, ....
Quanto a otimização, isso se aplica em qualquer linguagem de programação. Um programador em C meia boca, pode gera um executável mais eficiente que um programador em Assembly meia-boca.
Agora, "rapidez da linguagem C" soou esquisito! Processadores recebem instruções. Eles não são interpretadores.
Finalmente, após analisados os avisos e conselhos, cada um escolhe o caminho a percorrer (mais longo, mais curto, errado, ...). Tudo é um aprendizado....
Concordo! Porém tudo tem seu equilíbrio.
Errado? Pode apostar que não é!
-
Eu não ia fazer isso, mas aí vão algumas observações:
É importante entender como funciona a geração de pulsos pelo Mach3 o TurboCNC e o que o programa do Arduino consegue fazer.
Num programa CNC, ao gerar pulsos para mover o motor, o programa faz o sinal de STEP ser igual a 0 durante alguns poucos microssegundos e depois volta a valer 1 (+5V) durante dezenas ou até milhares de microssegundos, isso se repete uma certa quantidade de passos esperados no motor. Por outro lado, o programa postado, fica testando alguns bits de entrada do Arduino, um deles é o sinail de STEP. Ou seja:
(1) Se o programa coincidir de ler um pulso igual a zero no exato momento em que isso acontecer e não pode demorar muito para isso (apenas alguns microssegundos). Ou seja, jogue na loteria que talvez seja mais provável acertar!! Um programa desse tipo deveria utilizar ao menos interrupções do processador. Isso é beeeeeeem diferente de um L-297, por exemplo, que usa apenas circuitos lógicos discretos (="hardware puro", do tipo "bem burrinho") para gerar a movimentação e não precisa ficar testando bit nenhum. Assim, o referido programa pode até mover o motor uma vez ou outra, mas vai perder muuuuuuuuitos passos gerados pelo software. Isso é inaceitável num CNC.
Estamos falando de um microcontrolador trabalhando a 16 MIPS (Máximo de 20 MIPS). Podendo executar 240 instruções durante um pulso de 15uS. Acredite: é bastante coisa!
Na velocidade correta, funcionará perfeitamente.
(2) Um programa desse tipo deveria controlar a corrente, num arranjo chopper, medindo e controlando a corrente nas fases do motor. Isso é possível de ser feito, pois o Arduíno possui entradas analógicas, mas falta um programa adequado e veloz o suficiente. Tenho desconfiança que um Arduino dos mais simples consiga fazer isso com as bibliotecas padrão e o compilador C usual.
(3) Não usar a porta serial, a menos para a fase de testes, pois isso atrasa o programa e torna a movimentação lenta.
(4) Não foi mencionado como o motor está sendo efetivamente acionado. Ou seja, estão sendo usados transistores? Como estão ligados? Qual é a alimentação? Sem ligações corretas, "a mágica" não funciona, o motor não gira ....
São apenas alguns comentários e observações.
Ele esta usando UL2003 como driver.
-
Cláudio,
Eu não ia fazer isso, mas aí vão algumas observações:
É importante entender como funciona a geração de pulsos pelo Mach3 o TurboCNC e o que o programa do Arduino consegue fazer.
Num programa CNC, ao gerar pulsos para mover o motor, o programa faz o sinal de STEP ser igual a 0 durante alguns poucos microssegundos e depois volta a valer 1 (+5V) durante dezenas ou até milhares de microssegundos, isso se repete uma certa quantidade de passos esperados no motor. Por outro lado, o programa postado, fica testando alguns bits de entrada do Arduino, um deles é o sinail de STEP. Ou seja:
(1) Se o programa coincidir de ler um pulso igual a zero no exato momento em que isso acontecer e não pode demorar muito para isso (apenas alguns microssegundos). Ou seja, jogue na loteria que talvez seja mais provável acertar!! Um programa desse tipo deveria utilizar ao menos interrupções do processador. Isso é beeeeeeem diferente de um L-297, por exemplo, que usa apenas circuitos lógicos discretos (="hardware puro", do tipo "bem burrinho") para gerar a movimentação e não precisa ficar testando bit nenhum. Assim, o referido programa pode até mover o motor uma vez ou outra, mas vai perder muuuuuuuuitos passos gerados pelo software. Isso é inaceitável num CNC.
Estamos falando de um microcontrolador trabalhando a 16 MIPS (Máximo de 20 MIPS). Podendo executar 240 instruções durante um pulso de 15uS. Acredite: é bastante coisa!
Sim, eu acredito em você....
Mas, não sei se você já programou em Arduino, eu já programei em vários modelos, inclusive usando interrupção, que acho você não entendeu a finalidade para que serviria nesse caso.
Também já fiz vários experimentos da velocidade máxima em trens de pulsos via programa, usando um oscilosópio, não chega a algumas dezenas de KHz em linguagem C.
Mas, não vou ficar me estendendo para não "poluir" e suscitar mal entendidos e mais distorções do que eu realmente disse. Já estou me excedendo no que eu me dispunha a postar neste tópico.
-
Pois bem, testei um Arduino Mega-SDK (processador ATmega2560 @ 16MHz) com um programa bem simples:
int p13 = 13;
void setup() {
pinMode(p13, OUTPUT);
}
void loop() {
digitalWrite(p13, HIGH);
digitalWrite(p13, LOW);
}
Sem nenhuma biblioteca adicional, para não perder mais tempo de execução.
A frequência obtida no pino 13 foi de aproximadamente 70 KHz. Para acionar um motor de passo, assumindo que não haja perda de torque devido a velocidade (o ULN2003 não possibilita isso), a velocidade máxima (rotação do motor) em half-step com muita boa vontade, será de:
60*70000 / (2*400) = 5250 RPM
Essa é a velocidade máxima teórica com apenas duas instruções conforme acima, usando o compilador padrão do Arduino e o programa bem simples acima.
Se o programa gerar a sequência de passos de acionamento das fases do motor, ficar testando bits de entrada e acionar mais de um eixo motriz, a velocidade será bem menor. Não foi levada em conta a perda de torque, que ocorrerá, pois o circuito não controla a corrente do motor, o que limitará ainda mais a velocidade útil do motor.
Concluindo, o Arduino é capaz de acionar um motor de passo. A questão é, a que velocidade de acionamento do motor e se é possível o sincronismo do movimento com o Mach3 ou TurboCNC sem perder nenhum passo, sem jitter no acionamento do motor e com todos os eixos do CNC sincronizados. Aí, a coisa fica bem complicada se for usar um Arduino e seu ambiente padrão de programação (compilador, bibliotecas, ...) apenas....
-
Boa tarde pessoal, obrigado por tantas respostas, seguinte não estou usando comunicação serial pra acionar os motores, eu uso a serial para ler se esta acionando ou nao os pinos da porta paralela, quanto ao funcionamento do programa mach3 e turbocnc, eu nao sei se tem como regular o tempo do pulso dele, pois se for como o amigo falou que sao varios pulsos e micro segundos, e a porta volta a ficar no estado q ela estava entao pode ser isso o problema, esse phaser driver é esse do link "http://www.google.com.br/imgres?safe=off&sa=X&biw=1366&bih=642&tbm=isch&tbnid=RYkcbOVoIvmfdM:&imgrefurl=http://bildr.org/2011/06/easydriver/&docid=XN4ZBSuwbWcCDM&imgurl=http://bildr.org/blog/wp-content/uploads/2011/05/EasyDriver-Stepper-Motor-Driver2.png&w=433&h=782&ei=7ei-Up7xIdLekQfd84DgAw&zoom=1&ved=1t:3588,r:30,s:0,i:178&iact=rc&page=2&tbnh=190&tbnw=105&start=17&ndsp=23&tx=54&ty=84"
a plaquinha vermelha?
Se for isso essa peça é bem baratinha e com isso eu elimino o arduino completamente certo?
-
KKKK Voce ta querendo complicar as coisas kkkk...
Voce liga a porta paralela direto no ULN2003 como no anexo que peguei no site rogercom , dai configura o turbo cnc para phase drive.
-
Mas, não sei se você já programou em Arduino, eu já programei em vários modelos, inclusive usando interrupção, que acho você não entendeu a finalidade para que serviria nesse caso.
Nunca utilizei a IDE do arduino, porém conheço o hardware, pois utilizei a linha AVR durante alguns anos. Com WinAVR e posteriormente Atmel Studio.
Não sei de onde você tirou essa afirmação sobre interrupção. Mas de qualquer maneira, neste caso, a interrupção tornaria o programa mais lento.
Também já fiz vários experimentos da velocidade máxima em trens de pulsos via programa, usando um oscilosópio, não chega a algumas dezenas de KHz em linguagem C.
Você precisa saber separar as coisas.
O compilador vai transformar o seu código em linguagem de máquina. Não existe um interpretador dentro do processador para executar o programa. O que acontece com o JAVA.
O que define a velocidade é a experiência do programador.
Um exemplo:
while(1)
{
PORTB |= (1 << PINB7);
asm("nop");
PORTB &= ~(1 << PINB7);
}
Compilando:
sbi 0x05, 7 ; 2 Clocks
nop ; 1 Clock
cbi 0x05, 7 ; 2 Clocks
rjmp .-8 ; 2 Clocks
Teu pino ficará balançando a 2 MHz.
Vamos espremer um pouco mais:
while(1)
{
PORTB ^= (1 << PINB7);
}
Resultado:
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
rjmp .-8 ; 2 Clocks
Teu pino ficará balançando a 3 MHz. Como pode ser mais rápido que isso?
Se não for o suficiente, ainda temos o TIMER1 que é capaz de fazer esse pino balançar a 8MHz e de lambuja a CPU fica livre pra você.
Mas, não vou ficar me estendendo para não "poluir" e suscitar mal entendidos e mais distorções do que eu realmente disse. Já estou me excedendo no que eu me dispunha a postar neste tópico.
Em momento algum tentei distorcer o que você diz. Rebati, pois não concordei em alguns pontos com você. E no final das contas, saímos todos ganhando.
Pois bem, testei um Arduino Mega-SDK (processador ATmega2560 @ 16MHz) com um programa bem simples:
int p13 = 13;
void setup() {
pinMode(p13, OUTPUT);
}
void loop() {
digitalWrite(p13, HIGH);
digitalWrite(p13, LOW);
}
Sem nenhuma biblioteca adicional, para não perder mais tempo de execução.
A frequência obtida no pino 13 foi de aproximadamente 70 KHz. Para acionar um motor de passo, assumindo que não haja perda de torque devido a velocidade (o ULN2003 não possibilita isso), a velocidade máxima (rotação do motor) em half-step com muita boa vontade, será de:
60*70000 / (2*400) = 5250 RPM
Essa é a velocidade máxima teórica com apenas duas instruções conforme acima, usando o compilador padrão do Arduino e o programa bem simples acima.
Se o programa gerar a sequência de passos de acionamento das fases do motor, ficar testando bits de entrada e acionar mais de um eixo motriz, a velocidade será bem menor. Não foi levada em conta a perda de torque, que ocorrerá, pois o circuito não controla a corrente do motor, o que limitará ainda mais a velocidade útil do motor.
Concluindo, o Arduino é capaz de acionar um motor de passo. A questão é, a que velocidade de acionamento do motor e se é possível o sincronismo do movimento com o Mach3 ou TurboCNC sem perder nenhum passo, sem jitter no acionamento do motor e com todos os eixos do CNC sincronizados. Aí, a coisa fica bem complicada se for usar um Arduino e seu ambiente padrão de programação (compilador, bibliotecas, ...) apenas....
Não coloque a culpa no C (no caso do arduino: C++). Provavelmente essas funções executam muitas instruções.
E mesmo assim funcionará para do criador do tópico.
Ao menos você já mudou o seu discurso. Agora o arduino é capaz...
-
KKKK Voce ta querendo complicar as coisas kkkk...
Voce liga a porta paralela direto no ULN2003 como no anexo que peguei no site rogercom , dai configura o turbo cnc para phase drive.
Acredito ser a melhor solução para o caso. Economiza o arduino e terá melhor desempenho.
Tome cuidado com a tensão e corrente da fonte.
-
Faltou um exemplo:
while(1)
{
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
PORTB ^= (1 << PINB7);
}
Compilando:
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
in r24, 0x05 ; 1 Clock
subi r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
rjmp .-62 ; 2 Clocks
Resultado: 5 MHz
Manipulando:
in r24, 0x05 ; 1 Clock
cbr r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
sbr r24, r25 ; 1 Clock
out 0x05, r24 ; 1 Clock
cbr r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
sbr r24, r25 ; 1 Clock
out 0x05, r24 ; 1 Clock
cbr r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
sbr r24, r25 ; 1 Clock
out 0x05, r24 ; 1 Clock
cbr r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
sbr r24, r25 ; 1 Clock
out 0x05, r24 ; 1 Clock
cbr r24, 0x80 ; 1 Clock
out 0x05, r24 ; 1 Clock
sbr r24, r25 ; 1 Clock
out 0x05, r24 ; 1 Clock
rjmp .-42 ; 2 Clocks
Ou:
cbi 0x05, 7 ; 2 Clocks
sbi 0x05, 7 ; 2 Clocks
cbi 0x05, 7 ; 2 Clocks
sbi 0x05, 7 ; 2 Clocks
cbi 0x05, 7 ; 2 Clocks
sbi 0x05, 7 ; 2 Clocks
cbi 0x05, 7 ; 2 Clocks
sbi 0x05, 7 ; 2 Clocks
cbi 0x05, 7 ; 2 Clocks
sbi 0x05, 7 ; 2 Clocks
rjmp .-22 ; 2 Clocks
Resultado: 7 MHz
-
Ok, agora faça um Arduino gerar os sinais para o motor a partir dos sinais Step e Dir...
-
De novo? Está no primeiro post deste tópico.
Quer otimizado?
-
De novo? Está no primeiro post deste tópico.
Quer otimizado?
O que está no início do tópico já deu para perceber que não funciona...
Faça um que funciona, otimizado ou não, mas o motor não deve girar apenas a algumas dezenas ou centenas de RPM, o programa não deve perder pulsos gerados pelo Mach3 ou TurboCNC e não deve haver jitter no acionamento do motor em relação ao sinal gerado pelo Mach3 ou TurboCNC. Como você mesmo disse, com o "sinal para o motor balançando" a várias centenas de KHz.
-
Cláudio,
Se quiser uma mãozinha, segue a rotina que o Arduino usa (em assembly) apenas para escrever 1 bit numa saída do Arduino (digitalWrite).
void digitalWrite(uint8_t pin, uint8_t val)
{
3be: ff 92 push r15
3c0: 0f 93 push r16
3c2: 1f 93 push r17
3c4: f6 2e mov r15, r22
uint8_t timer = digitalPinToTimer(pin);
3c6: 48 2f mov r20, r24
3c8: 50 e0 ldi r21, 0x00 ; 0
3ca: ca 01 movw r24, r20
3cc: 82 54 subi r24, 0x42 ; 66
3ce: 9e 4f sbci r25, 0xFE ; 254
3d0: fc 01 movw r30, r24
3d2: 24 91 lpm r18, Z+
uint8_t bit = digitalPinToBitMask(pin);
3d4: ca 01 movw r24, r20
3d6: 88 58 subi r24, 0x88 ; 136
3d8: 9e 4f sbci r25, 0xFE ; 254
3da: fc 01 movw r30, r24
3dc: 14 91 lpm r17, Z+
uint8_t port = digitalPinToPort(pin);
3de: 4e 5c subi r20, 0xCE ; 206
3e0: 5e 4f sbci r21, 0xFE ; 254
3e2: fa 01 movw r30, r20
3e4: 04 91 lpm r16, Z+
volatile uint8_t *out;
if (port == NOT_A_PIN) return;
3e6: 00 23 and r16, r16
3e8: c1 f0 breq .+48 ; 0x41a <digitalWrite+0x5c>
// If the pin that support PWM output, we need to turn it off
// before doing a digital write.
if (timer != NOT_ON_TIMER) turnOffPWM(timer);
3ea: 22 23 and r18, r18
3ec: 11 f0 breq .+4 ; 0x3f2 <digitalWrite+0x34>
3ee: 82 2f mov r24, r18
3f0: 72 df rcall .-284 ; 0x2d6 <turnOffPWM>
out = portOutputRegister(port);
3f2: e0 2f mov r30, r16
3f4: f0 e0 ldi r31, 0x00 ; 0
3f6: ee 0f add r30, r30
3f8: ff 1f adc r31, r31
3fa: e2 50 subi r30, 0x02 ; 2
3fc: ff 4f sbci r31, 0xFF ; 255
3fe: a5 91 lpm r26, Z+
400: b4 91 lpm r27, Z+
uint8_t oldSREG = SREG;
402: 9f b7 in r25, 0x3f ; 63
cli();
404: f8 94 cli
if (val == LOW) {
406: ff 20 and r15, r15
408: 21 f4 brne .+8 ; 0x412 <digitalWrite+0x54>
*out &= ~bit;
40a: 8c 91 ld r24, X
40c: 10 95 com r17
40e: 81 23 and r24, r17
410: 02 c0 rjmp .+4 ; 0x416 <digitalWrite+0x58>
} else {
*out |= bit;
412: 8c 91 ld r24, X
414: 81 2b or r24, r17
416: 8c 93 st X, r24
}
SREG = oldSREG;
418: 9f bf out 0x3f, r25 ; 63
}
41a: 1f 91 pop r17
41c: 0f 91 pop r16
41e: ff 90 pop r15
420: 08 95 ret
-
O que está no início do tópico já deu para perceber que não funciona...
Segundo o colega está funcionando sim, mas em outro software.
-
Fique a vontade para testar.
Step pulse width: 3 uS
PINB7 = STEP; Deverá ser configurado em modo invertido no mach3.
PINB6 = DIR;
PINB3~0 = OUT; Motores de passo
#include <avr/io.h>
#define CURRENT_STEP GPIOR0
//const unsigned char steps[5] = { 0b10, 0b11, 0b01, 0b00, 0 }; // sequence of control signals for 2 control wires
const unsigned char steps[5] = { 0b0101, 0b0110, 0b1010, 0b1001, 0 }; // sequence of control signals for 4 control wires
int main(void)
{
PORTB = 0xFF;
DDRB = (1 << PINB3) | (1 << PINB2) | (1 << PINB1) | (1 << PINB0);
while(1)
{
while( PINB & (1 << PINB7) );
if( PINB & (1 << PINB6) )
{
if(CURRENT_STEP) --CURRENT_STEP; else CURRENT_STEP = 3;
}
else
{
if(CURRENT_STEP < 3) ++CURRENT_STEP; else CURRENT_STEP = 0;
}
PORTB = 0xF0 | steps[CURRENT_STEP];
while( (PINB & (1 << PINB7)) == 0 );
}
}
-
.lss:
00000096 <main>:
96: 8f ef ldi r24, 0xFF ; 255
98: 85 b9 out 0x05, r24 ; 5
9a: 8f e0 ldi r24, 0x0F ; 15
9c: 84 b9 out 0x04, r24 ; 4
while(1):
9e: 93 e0 ldi r25, 0x03 ; 1 Clock
a0: 1f 99 sbic 0x03, 7 ; 2 Clocks
a2: fe cf rjmp .-4 ; 2 Clocks
a4: 1e 9b sbis 0x03, 6 ; 2 Clocks
a6: 08 c0 rjmp .+16 ; 2 Clocks
a8: 8e b3 in r24, 0x1e ; 1 Clock
aa: 88 23 and r24, r24 ; 1 Clock
ac: 19 f0 breq .+6 ; 2 Clocks
ae: 8e b3 in r24, 0x1e ; 1 Clock
b0: 81 50 subi r24, 0x01 ; 1 Clock
b2: 07 c0 rjmp .+14 ; 2 Clocks
b4: 9e bb out 0x1e, r25 ; 1 Clock
b6: 08 c0 rjmp .+16 ; 2 Clocks
b8: 8e b3 in r24, 0x1e ; 1 Clocks
ba: 83 30 cpi r24, 0x03 ; 1 Clocks
bc: 20 f4 brcc .+8 ; 2 Clocks
be: 8e b3 in r24, 0x1e ; 1 Clock
c0: 8f 5f subi r24, 0xFF ; 1 Clock
c2: 8e bb out 0x1e, r24 ; 1 Clock
c4: 01 c0 rjmp .+2 ; 2 Clocks
c6: 1e ba out 0x1e, r1 ; 1 Clock
c8: ee b3 in r30, 0x1e ; 1 Clock
ca: f0 e0 ldi r31, 0x00 ; 1 Clock
cc: e0 50 subi r30, 0x00 ; 1 Clock
ce: ff 4f sbci r31, 0xFF ; 1 Clock
d0: 80 81 ld r24, Z ; 2 Clocks
d2: 80 6f ori r24, 0xF0 ; 1 Clock
d4: 85 b9 out 0x05, r24 ; 1 Clock
d6: 1f 9b sbis 0x03, 7 ; 2 Clocks
d8: fe cf rjmp .-4 ; 2 Clocks
da: e2 cf rjmp .-60 ; 2 Clocks
-
Fique a vontade para testar.
Step pulse width: 3 uS
PINB7 = STEP; Deverá ser configurado em modo invertido no mach3.
PINB6 = DIR;
PINB3~0 = OUT; Motores de passo
#include <avr/io.h>
#define CURRENT_STEP GPIOR0
//const unsigned char steps[5] = { 0b10, 0b11, 0b01, 0b00, 0 }; // sequence of control signals for 2 control wires
const unsigned char steps[5] = { 0b0101, 0b0110, 0b1010, 0b1001, 0 }; // sequence of control signals for 4 control wires
int main(void)
{
PORTB = 0xFF;
DDRB = (1 << PINB3) | (1 << PINB2) | (1 << PINB1) | (1 << PINB0);
while(1)
{
while( PINB & (1 << PINB7) );
if( PINB & (1 << PINB6) )
{
if(CURRENT_STEP) --CURRENT_STEP; else CURRENT_STEP = 3;
}
else
{
if(CURRENT_STEP < 3) ++CURRENT_STEP; else CURRENT_STEP = 0;
}
PORTB = 0xF0 | steps[CURRENT_STEP];
while( (PINB & (1 << PINB7)) == 0 );
}
}
Mas eu quero testar no Arduino e não num PC...
-
Como assim PC?
"#include<avr/io.h>" não deu uma pista?
-
Gil,
Mach3 vai até 100 kHz correto?
Acionando 3 eixos, 150 kHz e largura mínima do pulso de 3 uS; Borda de subida;
Código para o Arduino Mega2560.
/* Pinout
*
* PC0 (p37) = CH1.STEP
* PC1 (p36) = CH1.DIR
* PC2 (p35) = CH2.STEP
* PC3 (p34) = CH2.DIR
* PC4 (p33) = CH3.STEP
* PC5 (p32) = CH3.DIR
*
* PA0 (p22) = SM1.C0
* PA1 (p23) = SM1.C1
* PA2 (p24) = SM1.C2
* PA3 (p25) = SM1.C3
*
* PA4 (p26) = SM2.C0
* PA5 (p27) = SM2.C1
* PA6 (p28) = SM2.C2
* PA7 (p29) = SM2.C3
*
* PB0 (p53) = SM3.C0
* PB1 (p52) = SM3.C1
* PB2 (p51) = SM3.C2
* PB3 (p50) = SM3.C3
*
*/
//#define STEPS 0b00011110
#define STEPS 0b1001101001100101
#define MAX_STEPS 4
#define CH1_CURRENT_STEP GPIOR0
#define CH2_CURRENT_STEP GPIOR1
#define CH3_CURRENT_STEP GPIOR2
void setup(){
PORTC = 0xFF;
PORTB = 0xFF;
PORTA = 0xFF;
DDRB = (1 << PINB3) | (1 << PINB2) | (1 << PINB1) | (1 << PINB0);
DDRA = (1 << PINA7) | (1 << PINA6) | (1 << PINA5) | (1 << PINA4) | (1 << PINA3) | (1 << PINA2) | (1 << PINA1) | (1 << PINA0);
}
void loop(){
while( (PINC & ((1 << PINC4) | (1 << PINC2) | (1 << PINC0))) == 0);
if(PINC & (1 << PINC0)){
if(PINC & (1 << PINC1)) ++CH1_CURRENT_STEP; else --CH1_CURRENT_STEP;
}
if(PINC & (1 << PINC2)){
if(PINC & (1 << PINC3)) ++CH2_CURRENT_STEP; else --CH2_CURRENT_STEP;
}
if(PINC & (1 << PINC4)){
if(PINC & (1 << PINC5)) ++CH3_CURRENT_STEP; else --CH3_CURRENT_STEP;
}
PORTA = (STEPS >> ((CH2_CURRENT_STEP % MAX_STEPS) * MAX_STEPS)) | (STEPS >> ((CH1_CURRENT_STEP % MAX_STEPS) * MAX_STEPS));
PORTB = 0xF0 | (STEPS >> ((CH3_CURRENT_STEP % MAX_STEPS) * MAX_STEPS));
while( (PINC & ((1 << PINC5) | (1 << PINC3) | (1 << PINC0))) );
}
-
Bom dia pessoal, obrigado pela força, consegui fazer funcionar a mesa com o phase drive e o turbo cnc, com os unl 2003 ligados direto na porta paralela, como meu objetivo era fazer essa mesa andar, entao ta tudo certo, agora sei que o arduino tb não é recomendado para fazer esse tipo de trabalho e vou partir para algo maior.
Pode trancar o topico, pois o problema foi resolvido.
Agradeço a todos pela ajuda!
-
Enquanto redigia o textículo abaixo chegou a msg do João comunicando a adoção de oura solução, de qualquer modo acho que o comentário ainda pode ser de alguma utilidade, então aí vai:
Interessante discussão, será ainda mais se mantivermos os egos murchos e preservarmos o contexto ... ;D
Cláudio, o que o Gil fala está absolutamente correto, até pq ele, diferentemente de vc, se mantém no contexto, fala de Arduino, que vc já declarou não conhecer, consequentemente o que vc fala pode estar correto em outro contexto, não neste. Para o benefício de todos sugiro que procure familiarizar-se com o Arduino e então coloque suas sugestões.
João, desconheço suas prioridades, não está claro para mim se quer explorar o potencial do Arduino ou se o que quer no final das contas é uma máquina que funcione adequadamente ... de qualquer modo seu arranjo atual está bastante inadequado e se quiser, apesar de todos os conselhos em contrário, usar o Arduino na interface com o Mach3 ou o TurboCNC, terá que fazer algumas modificações, começando por tratar os sinais de passo e direção via interrupções, enfaizo que esta é a única maneira prática de abordar o prob, a menos que se conforme com uma carroça soluçante ;D
Sugiro que trate de testar seu sketch manualmente a princípio, garantindo que funciona como esperado, antes de tentar comandar os motores via TurboCNC, que sugiro que use inicialmente para descobrir os limites para o desempenho. Imagino que este limite será determinado pelo hardware, muito pobre e ainda não pelas idiossincrasias arduinianas ...
-
Sim Jorge!
O Gil está correto em partes.
Discordo apenas quando ele afirma que o problema de velocidade está na linguagem C.
Jorge, você deve prestar mais atenção ao que lê. Disse nunca ter utilizado a IDE Arduino.
Um observação: No caso, interrupção iria atrasar o programa.
-
Pode ser que eu tenha algum déficit de atenção, então vou me redimir:
Durante toda a discussão, acredite ser: "fazer funcionar utilizando o arduino". Se minhas colocações foram contrárias a isso, peço desculpas.
-
O Gil está correto em partes.
Não Cláudio, o Gil está plenamente correto.
Discordo apenas quando ele afirma que o problema de velocidade está na linguagem C.
Não foi isso que ele disse ... o Gil referia-se a peculiaridades do Arduino ...
Jorge, você deve prestar mais atenção ao que lê. Disse nunca ter utilizado a IDE Arduino.
É exatamente disto que se trata ... ;D
a IDE do Arduino É essencialmente o Arduino ... a utilização de outra coisa conduz a outros resultados e não estaremos mais falando exatamente do Arduino ... é a IDE que faz do Arduino o que ele é, incluindo idiossincrasias importantes como o Gil enfatizou ... sem IDE Arduino o que temos é uma breakout board como qualquer outra ...
Um observação: No caso, interrupção iria atrasar o programa.
He, he, he ... e polling, faz o que ? ;D ;D ;D
Interrupções são temidas por muitos, mas não pq atrasam alguma coisa, mas sim pq são eventos assíncronos e são extremamente úteis exatamente para o tratamento desse tipo de eventos ;D
Interrupção é a ÚNICA maneira decente de lidar com a coisa ... é, ao contrário do que vc diz, um tratamento muito rápido e que proporciona o absolutamente necessário sincronismo com os pulsos de passo / direção ... polling só funciona em condições muito específicas e impõe severas restrições, não é solução adequada para o prob que discutimos ou pelo menos não é a solução mais genérica, de maior abrangência.
-
Não Cláudio, o Gil está plenamente correto.
Você acaba de assinar embaixo das seguintes colocações:
"O seu programa não terá a velocidade suficiente, pois é feito em C e há várias coisas a serem feitas, que exigem conhecimento e experiência."
Repito: Deixa o C em paz! Ele desempenha o papel dele muito bem.
"Não exatamente a lingagem C, mas a biblioteca (em C) de motores de passo do Arduino é boa para iniciantes, porém acho-a lenta para um CNC, mesmo para amadores"
Isso é muito relativo. E como não sabemos em qual placa ele está desenvolvendo, faça o teste em um Arduino Due. Imagine rodando na Tre.
"Se o programa coincidir de ler um pulso igual a zero no exato momento em que isso acontecer e não pode demorar muito para isso (apenas alguns microssegundos). Ou seja, jogue na loteria que talvez seja mais provável acertar!!"
O problema no código dele está após identificar o pulso. E do jeito que foi apresentado, seria capaz de identificar um pulso de 1 uS sem problemas.
"Também já fiz vários experimentos da velocidade máxima em trens de pulsos via programa, usando um oscilosópio, não chega a algumas dezenas de KHz em linguagem C"
Outra colocação errada!
Não foi isso que ele disse ... o Gil referia-se a peculiaridades do Arduino ...
Concorco com você, mas ele deveria ter feito melhores colocações.
É exatamente disto que se trata ... ;D
a IDE do Arduino É essencialmente o Arduino ... a utilização de outra coisa conduz a outros resultados e não estaremos mais falando exatamente do Arduino ... é a IDE que faz do Arduino o que ele é, incluindo idiossincrasias importantes como o Gil enfatizou ... sem IDE Arduino o que temos é uma breakout board como qualquer outra ...
Apesar de não tem usado a IDE arduino, tenho conhecimento o suficiente para afirmar que funcionará e que será bastante lento.
E não é que a lógica funcionou?
Postei um código - para ser compilado na IDE arduino - há alguns posts atrás, apesar de não ter testado, deve funcionar perfeitamente.
He, he, he ... e polling, faz o que ? ;D ;D ;D
Interrupções são temidas por muitos, mas não pq atrasam alguma coisa, mas sim pq são eventos assíncronos e são extremamente úteis exatamente para o tratamento desse tipo de eventos ;D
Interrupção é a ÚNICA maneira decente de lidar com a coisa ... é, ao contrário do que vc diz, um tratamento muito rápido e que proporciona o absolutamente necessário sincronismo com os pulsos de passo / direção ... polling só funciona em condições muito específicas e impõe severas restrições, não é solução adequada para o prob que discutimos ou pelo menos não é a solução mais genérica, de maior abrangência.
Aqui você foi bastante infeliz. Sugiro que você estude antes de palpitar.
Existem mais coisas acontecendo do que você consegue observar na IDE do arduino.
Vou te dar uma força. Vou montar alguns exemplos pra vc entender os motivos da minha afirmação.
-
Você acaba de assinar embaixo ...
Isso mesmo, assino embaixo de tudo o que o Gil disse. Vou convidar mais uma vez: mantenha-se no contexto ... procure entender o que foi dito dentro do contexto em que foi dito. Mais importante do que estar certo é que possamos nos entender, né ?
Concordo com você, mas ele deveria ter feito melhores colocações.
Claro, é sempre possível melhorar nossas colocações, vc tb pode se esforçar um pouquinho nesse sentido, né ? ;D
Aquela "... interrupção iria atrasar o programa" foi de doer ;D ;D ;D
Apesar de não tem usado a IDE arduino, tenho conhecimento o suficiente para afirmar que funcionará e que será bastante lento.
Cláudio, pontificar sobre o que não se conhece não é muito saudável ... não vai custar a vc muito tempo nem muito esforço pra conhecer a IDE e então falar com conhecimento de causa, como tem feito o Gil ...
A manipulação direta dos registradores para operações I/O permite uma execução pelo menos dez vezes mais rápida que as funções arduinianas, mas eu não diria que é "bastante lento", o que eu diria é que pode não ser suficientemente rápido pra uma dada aplicação ... neste contexto eu certamente preferiria fazer a coisa de maneira semelhante ao seu exemplo.
Postei um código - para ser compilado na IDE arduino - há alguns posts atrás, apesar de não ter testado, deve funcionar perfeitamente.
Claro, dá pra contornar inteiramente o "jeitinho Arduino" de fazer as coisas, afinal o que temos embrulhado ali é o bom e velho avr-gcc, né ? ... mas de novo estaríamos nos colocando fora do contexto ...
Aqui você foi bastante infeliz. Sugiro que você estude antes de palpitar.
Posso devolver a bola ? ;D
Aqui você foi bastante infeliz. Sugiro que você estude antes de palpitar. ;D ;D ;D
Existem mais coisas acontecendo do que você consegue observar na IDE do arduino.
Pois é, isto e o que temos dito ... ;D
Mas isto nada tem a ver com interrupções vs polling ...
Vou te dar uma força. Vou montar alguns exemplos pra vc entender os motivos da minha afirmação.
Obrigado, mas não se dê ao trabalho, aproveite seu tempo pra aprender sobre interrupções, inclusive fora do contexto desta discussão, é coisa utilíssima ;D
-
Isso mesmo, assino embaixo de tudo o que o Gil disse. Vou convidar mais uma vez: mantenha-se no contexto ... procure entender o que foi dito dentro do contexto em que foi dito. Mais importante do que estar certo é que possamos nos entender, né ?
Não tente distorcer.
Gil passou a impressão de que o problema estava na linguagem e continuou insistindo mesmo após eu apontar o erro de colocação.
Qual a conclusão que se tira disso? Pode deixar o Tico dormindo, o Teco é suficiente para intender que o problema é conceitual.
Claro, é sempre possível melhorar nossas colocações, vc tb pode se esforçar um pouquinho nesse sentido, né ? ;D
Aquela "... interrupção iria atrasar o programa" foi de doer ;D ;D ;D
Confesso que sou péssimo em português. Quem sabe um dia eu consiga tempo para consertar isso.
"... atrasaria o programa." Melhorou?
Cláudio, pontificar sobre o que não se conhece não é muito saudável ... não vai custar a vc muito tempo nem muito esforço pra conhecer a IDE e então falar com conhecimento de causa, como tem feito o Gil ...
Onde eu falei besteira?
Experimente lêr os relatos do dono do tópico.
A manipulação direta dos registradores para operações I/O permite uma execução pelo menos dez vezes mais rápida que as funções arduinianas, mas eu não diria que é "bastante lento", o que eu diria é que pode não ser suficientemente rápido pra uma dada aplicação ... neste contexto eu certamente preferiria fazer a coisa de maneira semelhante ao seu exemplo.
Claro, dá pra contornar inteiramente o "jeitinho Arduino" de fazer as coisas, afinal o que temos embrulhado ali é o bom e velho avr-gcc, né ? ... mas de novo estaríamos nos colocando fora do contexto ...
Qual o seu conceito de Arduino? Você acha que se resume a meia duzia de bibliotecas?
Não estou apelando para magia negra para fazer funcionar e assim ter razão. Isto está ao alcance de todos. Basta "estudar".
"See the libraries page for interfacing with particular types of hardware. Try the list of community-contributed code. The Arduino language is based on C/C++. It links against AVR Libc and allows the use of any of its functions; see its user manual for details."
Fonte: http://arduino.cc/en/Reference/HomePage (http://arduino.cc/en/Reference/HomePage)
Obrigado, mas não se dê ao trabalho, aproveite seu tempo pra aprender sobre interrupções, inclusive fora do contexto desta discussão, é coisa utilíssima ;D
Contra fatos não há argumentos. Concorda?
Irei postar sim. Se você não tiver condições de debater sobre, poderá servir de referência para alguém.
Respeito bastante a bagagem e conhecimento de vocês. Frequento este fórum a anos e aprendi muito. Obrigado por isso!
Estou aqui tentando somar. E acredito que todos aprendemos aqui. Em nenhum momento tentei ser pejorativo ou fazer inflar meu ego.
-
Para a aplicação, apenas interrupções por borda são rápidas o suficiente. Ou seja, PCINT não serve.
Utilizando ATmega2560 e tomando o seguinte código como exemplo:
#include <avr/io.h>
#include <avr/interrupt.h>
ISR(INT0_vect){
GPIOR0 = PIND & (1 << PIND0);
}
int main(void){
EICRA = (1 << ISC01) | (1 << ISC00);
EIMSK = (1 << INT0);
sei();
while(1){
while((PIND & (1 << PIND0)) == 0);
GPIOR0 = PIND0;
while((PIND & (1 << PIND0)));
}
}
Parte do arquivo .lss:
00000000 <__vectors>:
0: 71 c0 rjmp .+226 ; 0xe4 <__ctors_end>
2: 00 00 nop
4: 7a c0 rjmp .+244 ; 0xfa <__vector_1>
6: 00 00 nop
000000fa <__vector_1>:
fa: 1f 92 push r1 ; 2 clocks
fc: 0f 92 push r0 ; 2 clocks
fe: 0f b6 in r0, 0x3f ; 1 clock
100: 0f 92 push r0 ; 2 clocks
102: 11 24 eor r1, r1 ; 1 clock
104: 8f 93 push r24 ; 2 clocks
106: 89 b1 in r24, 0x09 ; 1 clock
108: 81 70 andi r24, 0x01 ; 1 clock
10a: 8e bb out 0x1e, r24 ; 1 clock
10c: 8f 91 pop r24 ; 2 clocks
10e: 0f 90 pop r0 ; 2 clocks
110: 0f be out 0x3f, r0 ; 1 clock
112: 0f 90 pop r0 ; 2 clocks
114: 1f 90 pop r1 ; 2 clocks
116: 18 95 reti ; 5 clocks
00000148 <main>:
154: 48 9b sbis 0x09, 0 ; 2 clocks
156: fe cf rjmp .-4 ; 2 clocks
158: 1e ba out 0x1e, r1 ; 1 clock
15a: 48 99 sbic 0x09, 0 ; 2 clocks
15c: fe cf rjmp .-4 ; 2 clocks
15e: fa cf rjmp .-12 ; 2 clocks
Já temos um problema: Durante uma interpolação as três interrupções serão chamadas no mesmo instante.
Como isso não é permitido, será executada uma interrupção por vez respeitando ordem de prioridade.
Mas estamos falando de tempo de execução, então vamos adiante;
Retirado do datasheet do ATmega2560:
7.8.1 Interrupt Response Time
The interrupt execution response for all the enabled AVR interrupts is five clock cycles minimum.
After five clock cycles the program vector address for the actual interrupt handling routine is executed.
During these five clock cycle period, the Program Counter is pushed onto the Stack. The
vector is normally a jump to the interrupt routine, and this jump takes three clock cycles. If an
interrupt occurs during execution of a multi-cycle instruction, this instruction is completed before
the interrupt is served. If an interrupt occurs when the MCU is in sleep mode, the interrupt execution
response time is increased by five clock cycles. This increase comes in addition to the
start-up time from the selected sleep mode.
A return from an interrupt handling routine takes five clock cycles. During these five clock cycles,
the Program Counter (three bytes) is popped back from the Stack, the Stack Pointer is incremented
by three, and the I-bit in SREG is set.
Então, temos:
Objetivo: Setar GPIO0 com o valor de PIND0;
Utilizando interrupção:
1 clock para leitura do pino
5 clocks para chamar vetor
2 clocks para chamar <__vector_1>
27 clocks para executar rotina de interrupção
14 Clocks para setar GPIOR0 ou 875 nanosegundos.
Total de 35 Clocks ou 2 microsegundos.
Pooling:
1 clock para leitura do pino
2 clocks para sbis
1 clock para out
Total de 4 Clocks ou 250 nanosegundos.
Deu para entender?
Qual valor é menor? 875 ou 250?
-
Primeiramente, gostaria de desejar que o Sijoga continue seguindo em seu aprendizado. Você percebeu as dificuldades em usar apenas um Arduino, ou de um Arduino entre o PC e os motores de passo. Realmente a solução mais simples neste momento é o Phase Driver e depois aconselho-o a usar um driver mais elaborado que possua chopper.
Jorge,
Finalmente alguém entendeu os pontos de vista que eu estava tentando expor e fazer o coleguinha Cláudio entender....
Cláudio,
Primeiramente, você deveria entender o propósito deste fórum e o propósito deste tópico, criado por causa de um problema simples e bastante específico. Quando o colega "Sijoga" expôs suas dúvidas, ficou claro para mim onde ele queria chegar, apenas acionar seus motores de passo, mas "havia um Arduino no meio de caminho".
Por outro lado, você, de certa forma, acabou transformando este tópico numa exibição pessoal. Não sou contra exibicionismos, isso é fórum de cada um, mas quando não ajudam o colega e ocupam espaço, ficam totalmente fora de propósito e contraproducentes.
Gosto muito de programar e não quero desfiar a minha experiência e formação (graduação, mestrado, doutorado, ....) em vários assuntos relacionados, inclusive programação. Trabalho "de carteira assinada" com automação industrial (nas áreas de manutenção, engenharia, desenvolvimento, ensino, pesquisa, ....) há mais de 28 anos, mas, não quero ocupar mais ainda este tópico com minha exibição de ego.
Você deveria aprender que em automação industrial, controle de processos, robótica, CNC, ....nem tudo se resolve com programação, frequentemente, deve-se partir para soluções intergradas, usando dispostivos específicos (DSP, PLD, FGPA, ....), hardware dedicado, redes de alta velocidade e de baixa velocidade, comunicação entre sistemas, sistemas distribuídos, circuitos analógicos, mecânica, química, óptica, física, .... Na engenharia, vale mais o bom senso e saber aplicar a melhor solução, mas, isso exige conhecimento, experiência, talento, formação, networking, .....
Me parece que para você a programação é um "martelo" e todos os problemas se chamam "pregos". E você parece que só conhece um "martelo chamado C" e parece não enxergar que num simples CNC o programa (seja em C, código G, Java, Python, Matlab, LabView, Assembly, ....) é parte de um todo, que deve funcionar harmonicamente, com baixo jitter, com eficácia, ....
Além disso, você não entendeu nada do que eu disse e ainda distorceu o que eu afirmei aqui. Você parece não saber ouvir o que o interessado postou e nem o que outras pessoas postaram e estão postando.
Eu fiz um programa para o meu Arduino e consegui alcançar a frequência de 250KHz acionando um motor de passo, mas foi necessário algum malabarismo e usando diretamente alguns registradores do ATMega. Coisa que o IDE do Arduino não disponibiliza para principiantes. Assim mesmo, isso só me deixou ainda mais convencido de que o Arduino somente, e com o melhor programa, não atende a finalidade demandada neste tópico, simplesmente porque não implementa um controle de corrente (e que se for implementado vai gastar mais recursos da CPU e torná-la mais lenta), para que vou gastar ainda mais meu tempo nisto? Cabeça é para pensar e pesar as coisas...
Não sei se você já percebeu, neste fórum há pessoas que estão começando e devem ser ajudadadas sem elocubrações, tem se procurado manter os tópicos bem focados e com começo, meio e fim, sem baboseiras e pavonices. Finalmente, o respeito mútuo é um ítem de muito valor e que se preza em todas as dicussões.
Se você quiser criar seu tópico para discutir o assunto em profundidade, ok, poderia até participar. Mas ao menos, não fique poluindo ainda mais esse tópico com suas demonstrações de suposto conhecimento e pirotecnia de leitura de manual.
-
Cláudio,
Utilizando interrupção:
1 clock para leitura do pino
5 clocks para chamar vetor
2 clocks para chamar <__vector_1>
27 clocks para executar rotina de interrupção
14 Clocks para setar GPIOR0 ou 875 nanosegundos.
Total de 35 Clocks ou 2 microsegundos.
Pooling:
1 clock para leitura do pio no
2 clocks para sbis
1 clock para out
Total de 4 Clocks ou 250 nanosegundos.
Deu para entender?
Qual valor é menor? 875 ou 250?
Você não considerou que existe uma coisa chamada jitter, que vai fazer pulsos ocorrerem no meio do programa e esses pulsos eventualmente serão perdidos, se o programa não for suficientemente rápido. Esse tipo de problema não se trata desse jeito profissionalmente, usa-se um processador cuja interrupção possua latência adequada ao problema ou, mais frequentemente, parte-se para algo do tipo FPGA, hardware dedicado, ....
Você está usando uma teoria simplista em seu raciocínio, faltam alguns fundamentos estatísticos, melhor metodologia, .... para saber medir e expressar esse tipo de situação na realidade (jitter, eventos simultâneos, ...). A leitura do manual é necessária, mas é insuficiente, um teste de bancada bem orientado e focado é mais conclusivo que copiar e colar linhas do data sheet.
Se quer mostrar algo útil, deixe de poluir ainda mais esse tópico, crie o seu tópico e faça medições e demonstre o que diz. Manuais não se defendem e podem ser mal interpretados...
-
Primeiramente, gostaria de desejar que o Sijoga continue seguindo em seu aprendizado. Você percebeu as dificuldades em usar apenas um Arduino, ou de um Arduino entre o PC e os motores de passo. Realmente a solução mais simples neste momento é o Phase Driver e depois aconselho-o a usar um driver mais elaborado que possua chopper.
Pra variar, você está enganado.
Se você criticasse menos e prestasse mais atenção, saberia que ele não achou um driver com valor condizente a aplicação. Ele pediu orientação nisso. E como é seu metiê, acredito que você poderia ajudá-lo a encontrar uma controladora barata e funcional.
Graças ao Enéias, ele resolveu da melhor forma PARA ELE. Colocou pra funcionar e economizou uma grana.
Jorge,
Finalmente alguém entendeu os pontos de vista que eu estava tentando expor e fazer o coleguinha Cláudio entender....
Você errou! Simples não? Mas não se preocupe, isso acontece. E te garanto que vai ficar tudo bem.
Ficou sem saída Gil? Sua última cartada é tentar me ridicularizar? Que pena que você preferiu ir por esse lado. Não era necessário.
O bacana é que aqui no fórum está tudo gravado. Se você realmente não sabe onde errou, basta voltar à primeira página.
Apesar de não acreditar nisso, vou me defender beirando a demência levando em consideração que você está perdido até agora.
Cláudio,
Primeiramente, você deveria entender o propósito deste fórum e o propósito deste tópico, criado por causa de um problema simples e bastante específico. Quando o colega "Sijoga" expôs suas dúvidas, ficou claro para mim onde ele queria chegar, apenas acionar seus motores de passo, mas "havia um Arduino no meio de caminho".
Problema tão simples, mas você chegou com os dois pés na porta!
E problema realmente era simples. O circuito dele funcionava no programa "RoutOut Manager V 3.5", mas não funcionara no TurboCNC e Mach3. Ele queria entender o porquê disso, mas você mandou ele desistir, pois não funcionaria.
Por outro lado, você, de certa forma, acabou transformando este tópico numa exibição pessoal. Não sou contra exibicionismos, isso é fórum de cada um, mas quando não ajudam o colega e ocupam espaço, ficam totalmente fora de propósito e contraproducentes.
Não sou eu quem estou me exibindo. Você caiu do cavalo.
Em vez de dar a mão a palmatória, ou pelos menos ser humilde e perguntar como funcionaria, afirmou que era impossível.
Eu só fiz mostrar onde você estava errando e responder aos seus questionamentos.
Gosto muito de programar e não quero desfiar a minha experiência e formação (graduação, mestrado, doutorado, ....) em vários assuntos relacionados, inclusive programação. Trabalho "de carteira assinada" com automação industrial (nas áreas de manutenção, engenharia, desenvolvimento, ensino, pesquisa, ....) há mais de 28 anos, mas, não quero ocupar mais ainda este tópico com minha exibição de ego.
Parabéns Gil! Fico contente por você. Estou falando sério, fico feliz em ver pessoas dedicadas e que conseguem atingir seus objetivos.
Mas espero que esteja sempre se renovando. Afinal de contas, não usamos mais válvulas.
Você deveria aprender que em automação industrial, controle de processos, robótica, CNC, ....nem tudo se resolve com programação, frequentemente, deve-se partir para soluções intergradas, usando dispostivos específicos (DSP, PLD, FGPA, ....), hardware dedicado, redes de alta velocidade e de baixa velocidade, comunicação entre sistemas, sistemas distribuídos, circuitos analógicos, mecânica, química, óptica, física, .... Na engenharia, vale mais o bom senso e saber aplicar a melhor solução, mas, isso exige conhecimento, experiência, talento, formação, networking, .....
Gil,
Mais suposições... Você me conhece? Sabe da minha vida?
DSP, PLD e FGPA precisam ser programados para funcionar. Trabalho com esses caras também. Meu projeto atual, contém uma SPARTAN-6, CoolRunnerII e um LPC4088.
Me parece que para você a programação é um "martelo" e todos os problemas se chamam "pregos". E você parece que só conhece um "martelo chamado C" e parece não enxergar que num simples CNC o programa (seja em C, código G, Java, Python, Matlab, LabView, Assembly, ....) é parte de um todo, que deve funcionar harmonicamente, com baixo jitter, com eficácia, ....
Fugindo do contexto Gil? Achei que nossa discussão fosse sobre o Arduino!
Além disso, você não entendeu nada do que eu disse e ainda distorceu o que eu afirmei aqui. Você parece não saber ouvir o que o interessado postou e nem o que outras pessoas postaram e estão postando.
Tome um gole de café e releia a sua participação neste tópico. Você não agregou em nada. Só criticou.
Eu fiz um programa para o meu Arduino e consegui alcançar a frequência de 250KHz acionando um motor de passo, mas foi necessário algum malabarismo e usando diretamente alguns registradores do ATMega. Coisa que o IDE do Arduino não disponibiliza para principiantes. Assim mesmo, isso só me deixou ainda mais convencido de que o Arduino somente, e com o melhor programa, não atende a finalidade demandada neste tópico, simplesmente porque não implementa um controle de corrente (e que se for implementado vai gastar mais recursos da CPU e torná-la mais lenta), para que vou gastar ainda mais meu tempo nisto? Cabeça é para pensar e pesar as coisas...
Gil, está registrado! Até ontem você não conseguia fazer um pino pulsar a mais de 70 kHz no Arduino. Hoje já elaborou um driver de 250 kHz? Isso é o que se chama curva de aprendizado.
Mas, se for mentira, sei que você aprendeu como fazer seu arduino pulsar em até 8 MHz.
Não sei se você já percebeu, neste fórum há pessoas que estão começando e devem ser ajudadadas sem elocubrações, tem se procurado manter os tópicos bem focados e com começo, meio e fim, sem baboseiras e pavonices. Finalmente, o respeito mútuo é um ítem de muito valor e que se preza em todas as dicussões.
Esse é o ponto em que eu mais me preocupo. Uma pessoa que não tem a sua experiência, ou não convive com você, pode interpretar errado o que você diz. Cuidado com isso. Você pode estar prejudicando alguém.
Quando uma pessoa te pedir ajuda, ou pedir ajuda neste fórum, tente entender o problema e a situação, leia, re-leia se for necessário, e pense na resposta. Faça um rascunho. Veja se está condizente.
Se você quiser criar seu tópico para discutir o assunto em profundidade, ok, poderia até participar. Mas ao menos, não fique poluindo ainda mais esse tópico com suas demonstrações de suposto conhecimento e pirotecnia de leitura de manual.
Isso depende de você. Quer esclarecer mais algum ponto?
Apesar de tudo, se achar que eu possa te ajudar em algo, mande uma PM, e-mail ou ..., sei lá! Eu não tenho medo de passar conhecimento, nem de aprender e muito menos de discutir pontos de vista.
Eu levo isso na esportiva, pois tenho um pai com 63 anos e cabeça dura. Formado em Engenharia Eletrônica. Ele sabe que existe 1000 maneiras de se fazer algo, mas só a dele é a correta.
-
Cláudio,
Você não considerou que existe uma coisa chamada jitter, que vai fazer pulsos ocorrerem no meio do programa e esses pulsos eventualmente serão perdidos, se o programa não for suficientemente rápido. Esse tipo de problema não se trata desse jeito profissionalmente, usa-se um processador cuja interrupção possua latência adequada ao problema ou, mais frequentemente, parte-se para algo do tipo FPGA, hardware dedicado, ....
Você está usando uma teoria simplista em seu raciocínio, faltam alguns fundamentos estatísticos, melhor metodologia, .... para saber medir e expressar esse tipo de situação na realidade (jitter, eventos simultâneos, ...). A leitura do manual é necessária, mas é insuficiente, um teste de bancada bem orientado e focado é mais conclusivo que copiar e colar linhas do data sheet.
Se quer mostrar algo útil, deixe de poluir ainda mais esse tópico, crie o seu tópico e faça medições e demonstre o que diz. Manuais não se defendem e podem ser mal interpretados...
Está piorando Gil.
Agora você quer usar um canhão para matar uma mosca.
Fundamente sua teoria sobre jitter.
Você disse que iria testar meu programa. O que te fez mudar de ideia?
Ahh, todos esses códigos, foram feitos com base em AVR. E não para PC como você pensou!
Gil, entendo que você esteja perdido, pois você não é especialista nisso. Mas o manual é de extrema importância para desenvolvimento.
Faço referência ao Manual, pois gosto de discutir assuntos com fundamento.
Eu posso muito bem falar que o AVR é o uC mais rápido do mundo. E dai? Você vai acreditar em mim? Claro que não! Não poderia fazer afirmação mais idiota. Mas como você teria certeza? Lendo fóruns na internet? hmm... vai procurar datasheets não é verdade?
Então, por favor, da um tempo. Tópico está considerado fechado. Não precisamos ficar medindo quem tem o maior membro.
-
Cláudio,
Só vou comentar uma coisa....
Mas espero que esteja sempre se renovando. Afinal de contas, não usamos mais válvulas.
Você realmante não me conhece, acho que sou bem mais atualizado e bem formado do que você, não é a idade que conta, meu jovem.... Eu não preciso me alongar e nem provar nada a você.
Outra coisa, você realmente não sabe de nada, .... quem disse que não se usam válvulas. Não sabe o que ocorre à sua volta, jovem? E o Magnetron do forno de microondas de sua cozinha é o que? E os satélites que usam TWTs? Você sabe o que é um TWT? E os laboratórios de física de alta anergia que usam válvulas fotomultiplicadoras? E os tubos de Raios X dos dentistas? E os aparelhos de tomografia que usam tubos de Raio X? , ... Ainda bem que elas existem, estão bem ativas e se modernizam...
Muita coisa não mudou, inclusive a física dos semicondutores, já a educação para alguns (como você) saiu da agenda.
Quanto as besteirras que você escreveu, quem sabe um dia alguém lhe ensina, se você não o destratar antes.
Realmente está tudo registrado, talvez nem isso deve estar, são coisas e falatórios inúteis a meu ver.
-
kkkkkkk... Calma Gil! Não vá ter um ataque cardíaco!
Foi apenas uma brincadeirinha para responder a altura.
Já disse em outro post. Respeito muito sua bagagem e conhecimento.
Mas aqui você errou. É uma pena que lhe falte humildade para reconhecer isso.
E que a vida continue... ;)
-
Cláudio,
kkkkkkk... Calma Gil! Não vá ter um ataque cardíaco!
Não se preocupe, estou tranquilo e saudável, mas acho que você deveria tomar uns remedinhos para a sua cabeça. Quem sabe assim deixa de truncar e torcer o que as pessoas postam.
Já disse em outro post. Respeito muito sua bagagem e conhecimento.
Mas aqui você errou. É uma pena que lhe falte humildade para reconhecer isso.
Não errei não e a minha opinião é a mesma desde o início deste tópico. Além disso, passei a conhecer uma pessoa que muito provavelmente tem dificuldades de relacionamento, não enxerga o que acontece à sua volta e não sabe reconhecer seus erros.
Sei reconhecer quando erro e sempre estou aprendendo, sou um profissional do ensino e sei bem o que é aprender.
Por outro lado, procure se informar mais e melhorar seus conhecimentos de programação em tempo real aplicada e não apenas teórica. E lembre-se, nem tudo se resolve só com a "linguagem C", o mundo do CNC e da automação é bem maior do que isso....
-
Gil,graças a DEUS você não desisti eu aprendi muito com seus post,sou seu fâ,
Grato,Reginaldo
-
Não se preocupe, estou tranquilo e saudável, mas acho que você deveria tomar uns remedinhos para a sua cabeça. Quem sabe assim deixa de truncar e torcer o que as pessoas postam.
Não errei não e a minha opinião é a mesma desde o início deste tópico. Além disso, passei a conhecer uma pessoa que muito provavelmente tem dificuldades de relacionamento, não enxerga o que acontece à sua volta e não sabe reconhecer seus erros.
Sei reconhecer quando erro e sempre estou aprendendo, sou um profissional do ensino e sei bem o que é aprender.
Por outro lado, procure se informar mais e melhorar seus conhecimentos de programação em tempo real aplicada e não apenas teórica. E lembre-se, nem tudo se resolve só com a "linguagem C", o mundo do CNC e da automação é bem maior do que isso....
Gil,
Mais ofensas pessoais? Acredito que você tenha boa reputação neste fórum. Não estrague isso. Você consegue fazer melhor.
Não se preocupe com minha vida pessoal. Mas se te interessa: vai muito bem, obrigado!
Não estou aqui atrás de amigos e nem de coleguinhas. Este fórum já me ajudou bastante, aprendi muito com vocês e nas mais diversas áreas.
Voltemos ao assunto técnico ok? Esse é o objetivo.
Você quer debater sobre jitter? É sério isso, ou você está ficando sem argumentos?
Vamos recapitular. Se passaram tantas coisas que pode ter caído no esquecimento.
Você afirmou:
"Tenho desconfiança que um Arduino dos mais simples consiga fazer isso com as bibliotecas padrão e o compilador C usual."
"Também já fiz vários experimentos da velocidade máxima em trens de pulsos via programa, usando um oscilosópio, não chega a algumas dezenas de KHz em linguagem C"
"Pois bem, testei um Arduino Mega-SDK (processador ATmega2560 @ 16MHz) com um programa bem simples:
A frequência obtida no pino 13 foi de aproximadamente 70 KHz.
Concluindo, o Arduino é capaz de acionar um motor de passo. A questão é, a que velocidade de acionamento do motor e se é possível o sincronismo do movimento com o Mach3 ou TurboCNC sem perder nenhum passo, sem jitter no acionamento do motor e com todos os eixos do CNC sincronizados. Aí, a coisa fica bem complicada se for usar um Arduino e seu ambiente padrão de programação (compilador, bibliotecas, ...) apenas...."
Te respondi dizendo:
"O que define a velocidade é a experiência do programador."
E postei exemplos de como poderia fazer funcionar, mesmo utilizando o arduino. Que é a ferramenta que o criador do tópico tem em mãos.
E então, você me desafiou:
"Ok, agora faça um Arduino gerar os sinais para o motor a partir dos sinais Step e Dir..."
"Faça um que funciona, otimizado ou não, mas o motor não deve girar apenas a algumas dezenas ou centenas de RPM, o programa não deve perder pulsos gerados pelo Mach3 ou TurboCNC e não deve haver jitter no acionamento do motor em relação ao sinal gerado pelo Mach3 ou TurboCNC. Como você mesmo disse, com o "sinal para o motor balançando" a várias centenas de KHz."
Eu como bom aluno, aceitei o desafio e elaborei, em uma hora, um programa simples com seus requisitos.
Entenda, a idéia era fazer funcionar e não criar um produto comercial a prova de falhas.
Você falou sobre jitter oriundo do pc, eu levei isso em consideração sim. Existe uma janela de 800ns. Mesmo a 25 kHz, temos uma folga de 2%.
Existem difersas maneiras de se fazer isso, inclusive mais eficientes. Porém, serviu para o propósito: Demonstrar que é possível.
Se não for pedir muito, fundamente suas argumentações. Se eu estou errado, por gentileza, aponte o erro, mas de forma sucinta.
Estou aqui para aprender. E gosto de evoluir.
-
Cláudio,
Entenda, a idéia era fazer funcionar e não criar um produto comercial a prova de falhas.
Você falou sobre jitter oriundo do pc, eu levei isso em consideração sim. Existe uma janela de 800ns. Mesmo a 25 kHz, temos uma folga de 2%.
Existem difersas maneiras de se fazer isso, inclusive mais eficientes. Porém, serviu para o propósito: Demonstrar que é possível.
Se não for pedir muito, fundamente suas argumentações. Se eu estou errado, por gentileza, aponte o erro, mas de forma sucinta.
Estou aqui para aprender. E gosto de evoluir.
Não, você ainda não entendeu.
Eu posso ter te desafiado, mas o objetivo este tópico já foi alcançado. Título: "Re:Problemas com porta paralela e mach3"
Para mim, este tópico está muito mais do que encerrado.
Se você quiser abrir um novo tópico, sinta-se à vontade. Nele poderá ser discutido o que você propuser, mas explique o que quer alcançar, o termo "fazer funcionar" é subjetivo. Fazer funcionar o que exatamente e com quais requisitos?
Finalmente, como moderador, peço que seja trancado este tópico.
-
Sei que já resolveu o problema, mas todo mundo deixou passar um detalhe logo nos primeiros posts:
O Colega "sijoga" disse que o programa para, mas o motor não. Logo o arduino esta enviando pulsos se a entra estiver on
lpt1 esta ficando no mesmo estado como se o botão da direção estivesse precionado.
Portanto esta assim:
LPT "sinal alto" -> Arduino "pulsos" |_-_-_-_-_|
LPT "sinal baixo" -> Arduino "sinal Baixo" |_______|
A Lpt não trabalha com tipo "liga/desliga" os motores, mas sim por passos, cada pulso que sai do lpt é um passo no motor. Logo não precisa do arduino para fazer nada. Ligar diretamente como você fez soluciona.
Pode ate usar o Arduino como uma BOB, ligado entre a LPT e o driver (chip no seu caso). Basta usar o codigo:
int pino;
void setup() {
pinMode(1, INPUT);
pinMode(2, INPUT); // pinos de entrada
pinMode(3, OUTPUT);
pinMode(4, OUTPUT); // pinos de saida
}
void loop(){
for(pino=1 ; pino < 3 ; pino++)
{
if (digitalRead(pino)==HIGH)
digitalWrite(pino+2, HIGH);
else
digitalWrite(pino+2,LOW);
}
}