Depois do "tempão" sem escrever... Os leitores reclamando...kkkkkk volto com a documentação para os pacotes MODBUS que serão utilizados... agora bruno vai começar a ter o que fazer com gosto de gás.... rsrsrsrsrsrs Seguem os modelos de pacote criados por mim depois de uma noite árdua de trabalho :)
Modelos de pacotes MODBUS
_____________________________________
Parar Aquisição (Quando estiver constante)
Entrada:
A70000 Solicita o cancelamento da aquisição constante
Saída:
A71000 ( Já se encontrava no estado solicitado)
A71001 (Estado foi mudado com sucesso)
A71002 (O sistema não está adquirindo)
Desligamento da Bomba
Entrada:
B71000 Solicita a parada da bomba
B72000 Solicita o acionamento da bomba
B73000 Solicita a parada automática
B740000 Cancela a parada automática
Saída:
B71001 Bomba já está parada
B71002 Bomba Iniciou a execução
B72001 Bomba já está em funcionamento
B72002 Bomba foi acionada
B73001 Parada automática configurada
B73002 Já está ativado a automaticidade
B74001 Parada automática retirada
B74002 Configuração já é válida
Acionamento de Lâmpadas
Entrada:
C70000 Ligar a lâmpada
C70001 Desligar a lâmpada
Saída:
C71000 ( Já se encontrava no estado solicitado)
C71001 (Estado foi mudado com sucesso)
Acionamento de Ar Condicionado
Entrada:
D71000 Ligar o ar condicionado
D72000 Desligar o ar condicionado
D730XX Modificar temperatura
D74000 Verificar temperatura
Saída:
D71001 Ar já está ligado
D71002 Mudou ar para ligado
D72001 Ar já está desligado
D72002 Mudou ar para desligado
D73000 Temperatura Modificada
D740XX Temperatura atual
Porta da Garagem
Entrada:
E71000 Abrir porta
E72000 Fechar porta
E73000 Travar porta
E74000 Destravar porta
Saída:
E71001 Porta já está aberta
E71002 Porta foi aberta
E72001 Porta já está fechada
E72002 Porta foi fechada
E73001 Porta já esté travada
E73002 Porta foi travada
E74001 Porta já está destravada
E74002 Porta foi destravada
Detector de Incêndio
Entrada:
F71000 Ativar detector de incêndio
F72000 Desativar detector de incêndio
Saída:
E71001 Detector já está ativado
E71002 Detector foi ativado
E72001 Detector já está desativado
E72002 Detector foi desativado
E73001 Mensagem de Alerta
Alarme da Casa
Entrada:
A81000 Ativar alarme
A82000 Desativar alarme
Saída:
A81001 Alarme já está ativado
A81002 Alarme foi ativado
A82001 Alarme já está desativado
A82002 Alarme foi desativado
A83001 Mensagem de Alerta
segunda-feira, 20 de outubro de 2008
quinta-feira, 16 de outubro de 2008
16 de Outubro de 2008
O que foi fetio hoje e ontem:
Uma situação crítica consiste em um momento em que o valor adquirido não é permitido pelo sistema (como por exemplo um torque acima do normal) então o sistema suspende a aquisição e um comando de repeat deve ser lançado para que se possa novamente interpretar os pacotes recebidos. Se esse comando não for realizado o sistema recebe os pacotes mas não mostrará os valores adquiridos. Nos testes coloquei como situação crítica o aterramento, então ao aterrar o zigbee o tratamento era lançado!
Metas para Sexta (se possível):
Colocar tarefas na interface em java para comecar essa aquisição e organizar todo o código em C para que fique bem feito e com comentário. =P
I FEEL GOOD =D
FRASE DO DIA: O trabalho Fascina-me tanto, que ás vezes paro e fico a olhar para ele!!! rsrsrs
Hoje foi um dia suuuuuupeeeerrrr produtivo. Não perdi muito tempo na UFPB virtual, até porque não era meu dia. Deixei tudo para Jerry =P \o/ Hoje consegui colocar o sistema para interpretar os pacotes em MODBUS e dizer para a tarefa da uart o que fazer. Assim as aquisições só são feitas pela quantidade indicada dentro de cada pacote.
Os pacotes tratados são do tipo FA00XX. Onde FA00 é o cabeçalho de um pacote de transmissão, que deve ser alterado para o cabeçalho do protocolo MODBUS. O XX indica em hexadecimal o número de aquisições que o sistema irá realizar. Para o XX igual a FF a tarefa irá fazer a aquisição de dados por tempo indeterminado até que um comando de parada seja executado (Stop - ou algo que comece com s). O comando Quit (ou algo que comece com q) finaliza a conexão com o socket do servidor. O comando Repeat (ou algo comecado com R) deve ser usando no momento em que uma situação crítica for encontrada.
Uma situação crítica consiste em um momento em que o valor adquirido não é permitido pelo sistema (como por exemplo um torque acima do normal) então o sistema suspende a aquisição e um comando de repeat deve ser lançado para que se possa novamente interpretar os pacotes recebidos. Se esse comando não for realizado o sistema recebe os pacotes mas não mostrará os valores adquiridos. Nos testes coloquei como situação crítica o aterramento, então ao aterrar o zigbee o tratamento era lançado!
Metas para Sexta (se possível):
Colocar tarefas na interface em java para comecar essa aquisição e organizar todo o código em C para que fique bem feito e com comentário. =P
I FEEL GOOD =D
FRASE DO DIA: O trabalho Fascina-me tanto, que ás vezes paro e fico a olhar para ele!!! rsrsrs
quarta-feira, 15 de outubro de 2008
15 de Outubro de 2008
Desculpaassss....
Não tive tempo de escrever nada ontem, embora tenha sido desenvolvido algumas coisas.
O que foi fetio hoje e ontem:
Iniciai a implementação da parte do código responsável pela interpretação dos pacotes MODBUS, ainda não estudei para saber como de fato tem que ser um pacote mas já consegui mudar o código para quando for digitado (enviado) um pacote, o mesmo seja impresso na tela. Já estou conseguindo armazelá-lo em um buffer (array de char). O que é preciso fazer agora é entender o que vem dentro do pacote e passar para a tarefa de aquisição da UART o que é preciso para ela fazer, quantidade de aquisições ou etc etc etc...
Metas para Quinta:
Enviar pacotes MODBUS pelo socket e interpretá-los no NIOS, sabendo quantas aquisições devem ser realizadas. Além disso, dar andamento a interface com Bruno e baixar manuais para entender como é de fato um pacote MODBUS TCP/IP.
Não tive tempo de escrever nada ontem, embora tenha sido desenvolvido algumas coisas.
O que foi fetio hoje e ontem:
Iniciai a implementação da parte do código responsável pela interpretação dos pacotes MODBUS, ainda não estudei para saber como de fato tem que ser um pacote mas já consegui mudar o código para quando for digitado (enviado) um pacote, o mesmo seja impresso na tela. Já estou conseguindo armazelá-lo em um buffer (array de char). O que é preciso fazer agora é entender o que vem dentro do pacote e passar para a tarefa de aquisição da UART o que é preciso para ela fazer, quantidade de aquisições ou etc etc etc...
Metas para Quinta:
Enviar pacotes MODBUS pelo socket e interpretá-los no NIOS, sabendo quantas aquisições devem ser realizadas. Além disso, dar andamento a interface com Bruno e baixar manuais para entender como é de fato um pacote MODBUS TCP/IP.
segunda-feira, 13 de outubro de 2008
13 de Outubro de 2008
O que foi fetio hoje:
Hoje não foi um dia produtivo... :(
Passei a manhã pesquisando sobre terremotos para um amigo e resolvendo as coisas da UFPB Virtual, que por sinal tinha muitoo que fazer (Cadê Jerry meu Deus?). Bem depois do momento improdutivo (para o mestrado) comecei a fazer novos testes e alterações no sistema. Como estava funcionando tudo direitinho fiz logo um back-up (clarooo! por que Só Deus salva, o ser humano faz back-ups!!! dâmmmm).
Teste o sistema utilizando uma variável (array) para obter comandos maiores que somente uma letra através de sockets. Isso serve para receber os pacotes no protocolo MODBUS que serão enviados pelo cliente do socket (que será servidor Web) que contém o software em Java!!! Os testes ainda estão meio insatisfatórios mas... chegaremos lá! Bem o que está acontecendo de anormal é que ele só detecta o primeiro conjunto de palavras digitadas, depois ele nõa detecta mais nada, nem entra na parte de Buffer Managment. Bem amanhã farei mais testes para conseguir enviar esses dados... espero!!
Metas para Terça:
Conseguir enviar comandos através do socket e ser interpretados pelo Nios. Estes comandos vão simular os pacotes MODBUS eniados para o servidor....Ufa, um dia eu chego lá!
Descontração do dia:
Hoje não foi um dia produtivo... :(
Passei a manhã pesquisando sobre terremotos para um amigo e resolvendo as coisas da UFPB Virtual, que por sinal tinha muitoo que fazer (Cadê Jerry meu Deus?). Bem depois do momento improdutivo (para o mestrado) comecei a fazer novos testes e alterações no sistema. Como estava funcionando tudo direitinho fiz logo um back-up (clarooo! por que Só Deus salva, o ser humano faz back-ups!!! dâmmmm).
Teste o sistema utilizando uma variável (array) para obter comandos maiores que somente uma letra através de sockets. Isso serve para receber os pacotes no protocolo MODBUS que serão enviados pelo cliente do socket (que será servidor Web) que contém o software em Java!!! Os testes ainda estão meio insatisfatórios mas... chegaremos lá! Bem o que está acontecendo de anormal é que ele só detecta o primeiro conjunto de palavras digitadas, depois ele nõa detecta mais nada, nem entra na parte de Buffer Managment. Bem amanhã farei mais testes para conseguir enviar esses dados... espero!!
Metas para Terça:
Conseguir enviar comandos através do socket e ser interpretados pelo Nios. Estes comandos vão simular os pacotes MODBUS eniados para o servidor....Ufa, um dia eu chego lá!
Descontração do dia:
"Ontem consegui o que tanto queria e desejava ficarmos no quarto sozinho, no quarto, só eu e você, você passava por cima de mim, sussurrava em meus ouvidos, eu não conseguia segurar suas pernas.pela manhã vi o lençol sujo de sangue o seu sangue, finalmente consegui o tempo queria, sonha e almejava, matar você maldita muriçoca!!!"
sábado, 11 de outubro de 2008
11 de Outubro de 2008
É, eu sei que é sábado, mas mesmo assim resolvi vir dar uma adiantada nos trabalhos com Bruno. Viemos tentar colocar a aquisição para funcionar no progrma em Java.
O que foi fetio hoje:
O que foi fetio hoje:
Hoje fiz um teste assim que cheguei no laboratório. Coloquei o zigbee para receber dados e testei a recepção via sockets pelo telnet em outro pc. Tudo ocorreu em ordem, e deixei adquirindo por uma hora inteira (09:00 as 10:00) e nenhum erro ocorreu. Também fiquei oscilando a voltagem, uma hora deixava aterrado e outra mudava para enviar a impedância do ar.
Com relação aos valores altos que vinham, descobri que estes são obra de ais um mistério do zigbee. Ao desligar o zigbee e fazer tudo certinho do início o erro sumia. Muitas vezes somente desligando o módulo zigbee base já era possível regularizar os dados que eram recebidos.
No código em java conseguimos imprimir os valores através do system.ou.println. De início imprimimos apenas 1000 através de um laço while e funcionou corretamente. Entretanto quando tentamos criar um painel, o mesmo não funcionou com o while dentro. Tentamos algumas coisas e não funcionaram...
Por hoje está bom, vou agora pro Golfinho com a turma, segunda continuo rsrsrsrs
Metas para Segunda:
Consguir colocar a interface em java para funcionar e iniciar um controle para a aquisição de dados do zigbee para que só seja lido da porta serial quando o comando de ler for executado via sockets.
Abaixo uma figura do Nios e ZigBee e minha fiarada de coisas para testar o sistema rsrsrs.
Com relação aos valores altos que vinham, descobri que estes são obra de ais um mistério do zigbee. Ao desligar o zigbee e fazer tudo certinho do início o erro sumia. Muitas vezes somente desligando o módulo zigbee base já era possível regularizar os dados que eram recebidos.
No código em java conseguimos imprimir os valores através do system.ou.println. De início imprimimos apenas 1000 através de um laço while e funcionou corretamente. Entretanto quando tentamos criar um painel, o mesmo não funcionou com o while dentro. Tentamos algumas coisas e não funcionaram...
Por hoje está bom, vou agora pro Golfinho com a turma, segunda continuo rsrsrsrs
Metas para Segunda:
Consguir colocar a interface em java para funcionar e iniciar um controle para a aquisição de dados do zigbee para que só seja lido da porta serial quando o comando de ler for executado via sockets.
Abaixo uma figura do Nios e ZigBee e minha fiarada de coisas para testar o sistema rsrsrs.
Thats All Folks
sexta-feira, 10 de outubro de 2008
10 de Outubro de 2008
Hoje trabalhei menos que os outros dias, mas o dia foi produtivo, finalmente os dados foram enviados via socket!
O que foi fetio hoje:
Hoje o ZigBee teimou em fazer o seu mistério de não capturar dados e disponibilizar para o Nios II. Na verdade não consegui descobrir ainda a origem desse mistério (por isso é um mistério dâaaa)... O problema tanto pode ser do módulo zigbee quanto da FPGA com o Nios. O que acontece é que os dados não são recebidos e mostrados no terminal. Da ultima vez que isso aconteceu eu iniciei do início fazendo um software chamado teste_01 com a arquitetura 5. Com relação aos testes que necessitavam ser realizados hoje, fiz apenas um que foi colocando o tx_wr_pos para receber o buffer mas o mistério começou e tive que parar novamente. Tentei com o teste_01 e deu errado também, só saíram zeros mas ao tirar o zigbee da placa e colocar de novo ele voltou a funcionar, é como se algum buffer enchesse por causa que o nios não está recebendo ou algo do tipo.
Vamos agora aos testes novamente:
Teste para ver quantos são impresos:
Por volta de 134 valores foram recebidos e enviados para o socket. Depois disso o terminal nios deixa de mostrar os dados que foram enviados para o socket mas o mesmo continua imprimindo como se fosse algum lixo e depois começa a mostrar o lixo de memória.
Teste limpando o buffer com a variável tx_wr_pos:
Depois de conseguir colocar o zigbee para funcionar tentei novamente com a variável tx_wr_pos fazendo ela receber tx_buf. Deu certo, o socket permaneceu recebendo os dados por tempo indeterminado. Enretanto, após um certo tempo os valores começaram vir aleatórios, acho que isso ocorre porque a thread de escrita no socket executa mais rápido que a de aquisição de dados do zigbee. Se aumentar o TK_Sleep também parece não dar certo mas faltam alguns testes. O extranho é que quando dá esse erro ficam vindo valores muito altos e mesmo ao parar e executar o software de novo, os valores altos vêm logo no início.
Metas para Amanhã:
Testes com o sistema para saber de onde vem esse erro dos dados com valores altos e testas a aquisição através do código em java para saber se dessa vez não irá imprimir o lixo de memória também.
Vamos agora aos testes novamente:
Teste para ver quantos são impresos:
Por volta de 134 valores foram recebidos e enviados para o socket. Depois disso o terminal nios deixa de mostrar os dados que foram enviados para o socket mas o mesmo continua imprimindo como se fosse algum lixo e depois começa a mostrar o lixo de memória.
Teste limpando o buffer com a variável tx_wr_pos:
Depois de conseguir colocar o zigbee para funcionar tentei novamente com a variável tx_wr_pos fazendo ela receber tx_buf. Deu certo, o socket permaneceu recebendo os dados por tempo indeterminado. Enretanto, após um certo tempo os valores começaram vir aleatórios, acho que isso ocorre porque a thread de escrita no socket executa mais rápido que a de aquisição de dados do zigbee. Se aumentar o TK_Sleep também parece não dar certo mas faltam alguns testes. O extranho é que quando dá esse erro ficam vindo valores muito altos e mesmo ao parar e executar o software de novo, os valores altos vêm logo no início.
Metas para Amanhã:
Testes com o sistema para saber de onde vem esse erro dos dados com valores altos e testas a aquisição através do código em java para saber se dessa vez não irá imprimir o lixo de memória também.
quinta-feira, 9 de outubro de 2008
09 de Outubro de 2008
O que foi feito hoje:
Hoje continuei tentando colocar o sistema Nios para enviar os dados através de sockets. Apés verificar os problemas com as variáveis e tentar de algumas formas utilizar semáforos, vi que o problema era apenas a necessidade de colocar a thread para dormir. A thread do socket pois a de aquisição de dados já estava dormindo.
Após isso consegui enviar os dados pela ethernet para o servidor. Depois surgiu um problema, quando recebe-se o dado pelo telnet, depois de um determinado tempo, começa-se a vir lixo de memória e ainda não sei o porque.
Começamos a dar funcionalidade a interface em java que bruno (que sabe fazer interface em java pra ca¨@%¨&#%@¨#% piiiiiiiiiiiii...) me ajudou bastate a desenvolver.
Metas para amanhã:
Fazer testes para saber o porque do lixo de memória. Ver se esse lixo vem de um buffer ou se o mesmo se dá pelo mau acesso da variável global que foi criada. Outras tentativas podem ser: fazer um array de variáveis globais e um controle desse array para que atue como um buffer e fazer uma depuração de impressão dos dados colocando os dados que acabaram de ser impressos pela ethernet para saber se o erro é no cliente do socket somente ou se o lixo já vem do servidor.
Hoje continuei tentando colocar o sistema Nios para enviar os dados através de sockets. Apés verificar os problemas com as variáveis e tentar de algumas formas utilizar semáforos, vi que o problema era apenas a necessidade de colocar a thread para dormir. A thread do socket pois a de aquisição de dados já estava dormindo.
Após isso consegui enviar os dados pela ethernet para o servidor. Depois surgiu um problema, quando recebe-se o dado pelo telnet, depois de um determinado tempo, começa-se a vir lixo de memória e ainda não sei o porque.
Começamos a dar funcionalidade a interface em java que bruno (que sabe fazer interface em java pra ca¨@%¨&#%@¨#% piiiiiiiiiiiii...) me ajudou bastate a desenvolver.
Metas para amanhã:
Fazer testes para saber o porque do lixo de memória. Ver se esse lixo vem de um buffer ou se o mesmo se dá pelo mau acesso da variável global que foi criada. Outras tentativas podem ser: fazer um array de variáveis globais e um controle desse array para que atue como um buffer e fazer uma depuração de impressão dos dados colocando os dados que acabaram de ser impressos pela ethernet para saber se o erro é no cliente do socket somente ou se o lixo já vem do servidor.
Assinar:
Postagens (Atom)
