Olá.

Estou terminando de montar minha primeira router e estou na fase de testes elétricos e mecânicos.  Uso uma TB6560 (blue board) + três drivers para X, Y e Z.  Estava tudo indo razoavelmente bem;  por exemplo fiz funcionar os motores sem grandes problemas, só tendo que ajustar com mais cuidado as velocidades máximas.   

O problema começou quando montei as chaves de fim de curso, botão de emergência e sensor para o zero de Z.  Assim que tentei configurar as portas vi que todos os 5 sinais estavam permanentemente em "high".  Percebi que nada muda isso do ponto de vista do PC; as chaves em quaisquer posições (ligadas ou desligadas) e combinações não surtem efeito.  Mesmo com o cabo paralelo desconectado o PC continua mostrando os cinco sinais em "high"; também verifiquei o status com o LinuxCNC e dá o mesmo resultado.

O micro que estou usando é um HP-Compaq Pentium 4 com tudo onboard (vídeo, LPT, etc).  O que penso em fazer é desativar a LPT onboard (e o vídeo também para tentar resolver problemas de latência medidos com o LinuxCNC) mas tenho dúvidas se esse caminho dará resultado para o problema da LPT.  Eu gostaria de saber se alguém já viu esse tipo de comportamento e saberia a razão.  Se for uma característica do computador HP/Compaq então provavelmente terei de substituir a máquina toda e o gasto com as novas plaquinhas poderia ser evitado nesse momento.

Tentei encontrar casos parecidos mas não tive sorte.

Abraços.
David

Fiz mais alguns testes com diferentes configurações da BIOS para a LPT mas as entradas 10, 11, 12, 13 e 15 continuam sempre ativas:

Eu testaria cada uma dessas entradas, ligando ao SGND ou a 3 pilhas em série (4,5V), sendo o SGND os pinos 18 a 25. E ver o que o software consegue ler.

Quanto ao software de teste, se você usa Linux, é bem trivial fazer um programa em linguagem "C" que leia a LPT1 e apresente a saída no terminal (linha de comando), com o velho e bom "printf". Exemplo de programa que escreve na LPT1, para ler, usar o comando inpb.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <asm/io.h>

#define base 0x378   //LPT0

//to compile:  gcc -O parport.c -o parport
//after compiling, set suid:  chmod +s parport   then, copy to /usr/sbin/


int main(void) {
  if(ioperm(base,1,1))
    fprintf(stderr, "Couldn't open parallel port"), exit(1);

  outb(255,base);  //set all pins hi
  sleep(5);
  outb(0,base);    //set all pins lo

  return 0;
}

Ou, se preferir, com Python pode-se fazer algo em mais alto nível.

Fiz os testes e aproveitei para testar com o modo "somente saída" também.   As entradas continuam altas sem estímulo e com estímulo não mudam. Então me ocorreu de tentar aterrar essas entradas.  Quando fiz isso com cada pino os sinais correspondentes foram para zero. 

Parece-me que essa interface do HP/Compaq não deve lidar muito bem com a alta impedância da controladora. Então irei diminuir a impedância artificialmente como recurso para resolver esse problema: colocarei resistores conectando cada uma das entradas (10, 11, 12, 13 e 15) ao GND; espero que isso baste.



>----+-----> entrada
     !
    +++
    | |
    +++
     !
     !
    ---
     -

         

Irei atualizando meu progresso (espero) aqui neste tópico.

Abraços.
David

Acho que são necessários alguns reparos e alinhamentos de conceitos, para facilitar o entendimento e a comunicação.

(...)

Cuidado no que for ligar. Pode danificar algo ou tirar conclusões erradas.

Se a sua porta paralela foi metodicamente testada e funciona corretamente, o problema pode ser:
(1) Na sua interface conectada à porta paralela, meça as tensões de saída da mesma, que vão para a porta paralela, tentando simular os dois níveis lógicos de saída.
(2) No cabo, teste com um multímetro.
(3) Na parametrização de seu programa CNC. Verifique seu programa.

Gil,
    encontrei a origem do problema! 
    Estava localizado no lugar onde quase sempre está: na interface que conecta a cadeira ao teclado. 

    Fiz como você sugeriu e fui estudar mais.  Vi que o comportamento estaria correto: resulta mesmo em níveis altos na leitura (bit em "1") para o caso da entrada desconectada - e também 5V - e níveis baixos (bit em "0") para entrada aterrada - ou 0V;  com a exceção do pino 11 (BUSY) que é o inverso. Testei tudo novamente e confirmei as leituras com o programa em C que fiz - com base no que você enviou - que exibe continuamente a leitura desses 5 sinais.

    O fato é que eu tinha tirado conclusões erradas: por desconhecimento de minha parte achei que a interface do meu computador estivesse com problemas.

    Porém o problema original continuava: não conseguia ler os fins-de-curso nem o sensor de ferramenta.

    Desmontei a controladora - ela é separada dos drivers - e a levei para a bancada para testá-la. Parecia tudo ok, com a comunicação acontecendo normalmente.  Inspecionando a placa foi que me dei conta que a alimentação dos sensores (que excita os fotoacopladores) é separada: ela usa a alimentação 12V-24V que é marcada como "opcional" - problemas de tradução do chinês? - na parca documentação que consegui dessa placa.  Como eu não havia conectado essa alimentação, os sensores não funcionariam mesmo!

    Remontei tudo na máquina, conectei a fonte à entrada "12V-24V" e pronto: sensores funcionando!  Configurei o MACH3 da maneira tradicional, com detecção automática de cada entrada, e ficou perfeito.

    Solucionado.

    Muito agradecido por sua paciência em me apontar a direção certa.   Acho que décadas longe da bancada me deixaram muito enferrujado.

    Abraços!
    David