Oi pessoal,

Continuando o tópico http://www.guiacnc.com.br/emc-linux/nem-freud-explica/msg188293/?topicseen#msg188293 ...

O Smile permite comunicação com o PC para alteração da sua configuração (corrente do motor, ...) ou mesmo atualização do firmware. Uma das etapas para entrar em modo de comunicação é mudar o estado do sinal de DIREÇÃO 10x, mantendo o sinal de PASSO imóvel. Na prática é algo que não deveria acontecer, mas acontece. Ainda não sei o motivo.

Algum colega poderia explicar o motivo da DIREÇÃO pulsar sem que o PASSO mude? Aparentemente o EMC2 faz isso, mas ainda não descartei o MACH. Até prova em contrário, o TurboCNC não faz isso (testei um monte de vezes aqui em casa).

Pelos testes que o Vitor fez, aparentemente o Smile pode entrar em modo de comunicação quando está fresando. O led amarelo do Smile passa a ficar constantemente ligado (indicando que está se comunicando) ao invés das duas piscadas do coração. Aconteceu no EMC2 do Vitor e do Lolata.

Mais alguém percebeu esta característica?

Estou anexando o programa 3.NGC que o Vitor criou. Seria possível os colegas que usam Smile rodar este programa e relatar o resultado, por favor?

Hoje fiz um teste para que o sinal de DIREÇÃO mudasse 100x ao invés de 10x (sempre considerando-se o sinal de PASSO imóvel) para entrar em modo de comunicação. Resultado: o programa rodou até o fim e o Smile funcionou perfeitamente.

Ainda estou pesquisando, mas é certo que o Smile deverá ser mais seletivo quanto a entrar em modo de comunicação.

Abraços,
Rudolf

Ave Fabio,

O tamanho (ou duração) dos pulsos de passo e mais importante que isso, a tensão (e corrente) no sinal de passo que está sendo gerado pelo EMC ou qualquer outro sistema.

Comento isso porque o Lolata está usando um laptop...

O Lolata e o Vitor usam desktop nas máquinas deles. Exceto pelo programa 3.NGC, não houve perda de passo ou este "reset" nos Smiles do Lolata.

O Lolata tem um notebook que usa(va) quando visita(va) clientes para eliminar dúvidas sobre instalação e configuração do programa do PC. Como não tenho EMC2 em casa, pensei em usar o dele.

O Vitor ofereceu o desktop dele (e o CNC também) para testar em casa, mas um notebook é bem mais leve hehehe

que é sabido que estes computadores fornecem pouca tensão na porta, e a bob dos Smile sei que condiciona os sinais mas claro dentro de certos limites - talvez esteja aí a coisa....

Poderia até ser se usassem note ao invés de desktop.

Abraços,
Rudolf

Boas.
Vou atirar uma ideia boba para o ar, ja que não tenho esse driver.
No caso de a CNC não ter resolução tão grande quanto o display (no mach que é o que uso), com pequenas variações na 3ª e 4ª casa após a virgula, acontece o pino Dir mudar e não chegar a ocorrer nenhum passo, já que por configuração, não é possivel dar um passo para uma deslocação inferior ao passo da páquina. poderá ser essa a causa de o PC dar as tais 10 mudanças de direção sem dar nenhum passo.
Ta meio confuso, mas no meu caso, o mostrador mostra x.yyzz. apenas uma mudança no digito x ou y é que provoca movimento no motor. Se a variação for apenas nos digitos z, o motor não mexe, mas o pino Dir julgo que altera conforme o programa pede.
É questão de verificarem se não será isso que ocorre.Se for, é possivel configurar a unidade acima e acrescentar isso na configuração de motor.
No meu caso não me chateia para já, mas ja ponderei mudar as unidades para milimetro, e assim já ia ter o mostrador x.yyyz (já só teria um digito morto)

tenho dúvidas se por exemplo houver diferenças no que o digital mostra em relação À geração de passos - para mim, se houve um deslocamento que justifique um passo, o drive lê este passo e pronto, mas se as variações forem menores que um passo, nada aconteceria.

De qualquer forma, uma coisa é pensar em um passo isoladamente - outra é numa cadeia de passos.

Digamos que o drive está ajustado para 400 passos por volta e a máquina tenha um fuso de 5mm de passo - serão necessários 80 passos para deslocar 1mm, o que dá uma resolução de 0,0125 mm deslocados por cada passo, então se pensarmos em um passo isoladamente, caso o deslocamento for menor que esta resolução, nada deveria acontecer, mas creio que se o deslocamento for maior que isso, o interpretador deveria fazer alguma coisa - no final, creio que teria um erro de um passo para mais ou para menos porque seriam deslocamentos fisicos sempre dentro dessa resolução... e os sinais de passo respeitariam isso.