Portas de comunicação

Introdução

Portas de comunicação são o meio utilizado pelos drivers de protocolo para enviar e receber dados. Uma porta de comunicação pode ser usada por um  ou mais drivers de protocolo, simultaneamente.

As portas de comunicação são separadas da implementação dos protocolos para permitir uma maior flexibilidade do sistema. Uma aplicação dessa real que pode ser feita com essa arquitetura, é associar uma porta TTCP_UDPPort com um COMServer (equipamento que nada mais é que um gateway RS-232/485/422 para TCP/IP), para por exemplo, comunicar com algum equipamento Modbus RTU a muitos quilômetros de distância sobre internet. Outra vantagem deste design é colocar dois ou mais protocolos usando a mesma porta de comunicação simultaneamente na mesma aplicação. Isto é possível pelo fato de todas portas contar com um mecanismo que só permite que um protocolo use a porta durante a operação de comunicação.  Ou seja, uma aplicação pode comunicar com vários equipamentos,  estes equipamentos com diferentes protocolos de comunicação e todos conectados na mesma rede RS-485. É possível, apesar de não ser recomendado.

Todas as portas existentes no PascalSCADA descendem da classe TCommPort, que implementa os métodos base para abrir e fechar a porta, ler e escrever dados e limpar os buffers de leitura e escrita em caso de falha de comunicação. Mas lógico que estes métodos precisam ser especializados caso uma nova porta de comunicação esteja sendo implementada.

Seleção_090TSerialPort

A classe TSerialPort, derivada da classe TCommPort, foi criada para permitir os protocolos trocar dados sobre portas seriais, independente do meio físico utilizado pela porta.

Em sistemas operacionais Windows, esta classe necessita uma porta serial com o nome entre COM1 e COM255.

Rodando sobre Linux, qualquer dispositivo que o nome comece com tty<número>, ttyUSB<número> ou ttyACM<número> é válida.

On FreeBSD, any device qualquer dispositivo cujo o nome comece com cuad<número> é aceita pela classe.

Tanto em Linux como FreeBSD (ou outro Unix) deverá ser tomado o cuidado de adicionar o usuário que irá rodar a aplicação no grupo dono da porta serial, alem de dar permissão de leitura/escrita para o grupo sobre a porta serial desejada. O nome deste grupo varia conforme o sistema.

Independente de sistema operacional, a classe de porta Serial conta com as seguintes propriedades que configuram o funcionamento da porta serial:

  • COMPort: define a porta serial a ser utilizada. Caso a aplicação seja configurada com uma porta e esta porta seja desconectada do sistema (por exemplo, um conversor USB <-> Serial) e a aplicação seja iniciada, uma exceção será gerada. Se esta exceção for gerada durante a carga (inicialização) da aplicação, sua aplicação não iniciará, mesmo com a propriedade Active = FALSE.
  • Baudrate: velocidade em bits por segundo que esta porta irá utilizar durante a comunicação. Velocidades entre 110 bps e 115200 bps são aceitas.
  • DataBits: Define o tamanho da palavra de dados que será trocada durante a comunicação serial, em bits. Os tamanhos aceitos são 7 ou 8 bits, sendo o padrão 8 bits. Alguns protocolos pedem 7 bits, como por exemplo o Modbus ASCII. Outros como o Modbus RTU, definem o tamanho da palavra de dados de 8 bits.
  •  StopBits: Configura a quantidade de bits que será usada para marcar o início e o final de cada palavra transmitida na comunicação serial. O padrão é 1 stop bits.
  • Paridade: configura se a palavra irá contar com checagem de erros, e se em caso dela existir, se a checagem vai ser par ou impar.
  • Timeout: Define o tempo máximo que a porta serial irá aguardar pela leitura de uma certa quantia de dados. Este tempo é definido em milissegundos. Em casos de estouro do timeout, uma limpeza dos buffers de leitura e escrita é realizada.
  • AcceptAnyPortName: Esta propriedade, quando habilitada em um sistema Unix (Linux, FreeBSD,  etc), faz com que qualquer nome de dispositivo seja aceito na propriedade COMPort. Muito útil quando alguns drivers criam nomes de dispositivos que não são aceitos pelo padrão descrito acima. No Windows ela não tem efeito.
  • WriteReadDelay: Atraso em milissegundos entre um comando de escrita e em seguida um leitura.
  • Active: Esta propriedade controla a abertura e fechamento da porta. A porta serial não deverá estar aberta por nenhum outro processo quando esta propriedade vai para true, caso contrário a propriedade Active irá votar para false. Em tempo de desenvolvimento, Active = true só realiza as verificações para abertura da porta mas não efetua a abertura da porta.
Seleção_091TTCP_UDPPort

A classe TTCP_UDPPort, derivada da classe TCommPort, foi criada para permitir os protocolos trocar dados sobre portas TCP (testado) ou UDP (necessita testes) sobre IPv4. independente do meio físico utilizado pela porta.

Esta classe de porta, não tem propriedades que dependentes de sistema operacional, sendo que as seguintes propriedades configuram seu funcionamento:

  • Host: Endereço IPv4 que a porta irá conectar. Nomes de host não são aceitos, somente endereços IP.
  • Port: Número da porta no host destino que a porta irá conectar. são aceitos qualquer número entre 1 e 65535.
  • PortType: Define se o socket que irá ser estabelecido irá ser sobre TCP ou UDP.
  • ExclusiveDevice: Caso true, evita que a porta seja aberta durante o tempo de desenvolvimento. Util quando o host destino tem um limite muito baixo de conexões disponíveis.
  • EnableAutoReconnect: Caso true e caso o socket for desconectado (problema no meio físico ou com o host) habilita o temporizador que irá ficar tentando reconectar o socket. Neste caso o socket com problemas é fechado e a propriedade Active permanece true.
  • ReconnectRetryInterval: Esta propriedade define o intervalo de tempo em milissegundos em que a porta tentará reconectar conexões perdidas. Esta propriedade só é valida caso EnableAutoReconnect e Active sejam true.
  • Timeout: Define o tempo máximo que a porta irá aguardar pela confirmação de escrita ou leitura de uma certa quantia de dados. Este tempo é definido em milissegundos. Caso alguma operação exceda este tempo, os buffers são limpos, a porta é verificada e em caso de alguma anormalidade, o socket será descartado e se EnableAutoReconnect é true uma tentativa de reconectar o socket será feito.
Exemplos

Abaixo estão listados exemplos de como trocar dados usando as portas de comunicação do PascalSCADA diretamente via código, ou seja sem usar, sem usar um driver de protocolo. Como todas as portas são descendentes da classe TCommPort, o exemplo abaixo também vale se quiser implementar algo usando uma porta TTCP_UDPPort.

33 ideias sobre “Portas de comunicação”

  1. hi sir good afternoon, am ajay kumar from india. i started learning of HMI’s . my question is ” HMI having two ports COM0, COM1. while COM0 in connected with PLC to pass Modbus commands over TCP . While that is happening I want to read HMI registers from another COM port on the same HMI. How can we do that?

  2. hi , my name is AJAY from INDIA. i need some answer regarding below question. please review on this question
    basically HMI having 2 ports vise COM0 & COM1. now am connected COM0 to passed Modbus commands over TCP to PLC while HMI was master.
    While that is happening I want to read HMI registers from another COM port on the same HMI. How can we do that? Can you implement and show?

    1. Hi Mr. Ajay!

      Why not read and write using the same port (COM0)?

      I don’t understand if your slave is Modbus RTU or TCP. If your slave is Modbus RTU you can’t put your application using COM0 and COM1 communicating with the same PLC port, because Modbus RTU don’t alloos two masters on the same bus.

      But if:
      you are using Modbus RTU AND have two ports on your PLC

      OR

      you are using Modbus TCP

      You should put two:

      ** Two serial ports and two Modbus RTU protocolo driver, one for read other writing operations

      ** Two TCP_Udpport and two Modbus TCP driver, one for read other writing operations.

      For both cases:

      ** tags linked with with port dedicated for read, should autowrite set to false

      ** tags linked with port dedicated to write should autoread set to false

      ** Modbus driver linked with the port dedicated for read should have ReadOnly property set to true.

      I don’t what you want to do, but I hope this helps.

      The best regards from Brazil,

      Fabio

      1. thnaks Fabio for valuable information . may i use this information to solve my problem , but still i confused.
        if any issues made during my working process i will ask questions , please give some guidance for me. i want to learn good HMI knowledge. i needed this . thank you sir.
        best regards AJAY KUMAR
        INDIA

  3. Hello from Turkey. First of all thank you for this perfect project.
    I would like some update about baudrate list. As you know nowadays it is common to use upper baudrates. Could you add the following rates to TSerialPort.
    128000, 153600, 230400, 256000, 460800, 921600.

    P.S. : I am not sure if this is a right place for such kind of request.

    Thanks in advance.

    Fatih

      1. Hi Fabio,

        I have already tested in lab for modbus rtu protocol by adding extra baudrates above. Of course mentioned limits depend on the capability of hardware, our adapter works up to 2 Mbits.
        As I said I can make the modifications on code but in order to use up-to-date code without editing, it would be better, it also helps other people as well. I have just test it in Windows, but in next week, I can test in Linux .

        Thanks.
        Fatih

    1. Bom dia Rafael!

      Não. E não é uma limitação do PascalSCADA e sim do design das conexões (UDP,TCP)/IP que são 1:1, ou seja, em qualquer sistema de supervisão vc terá esta limitação. A única excessão é se na outra ponta, você tem um equipamento que desempenha a função de gateway, como um gateway ModbusTCP => Modbus RTU. Ai neste caso sim, um unica conexão TCP pode ser usada para “conectar-se” com vários equipamentos Modbus RTU, mantendo a conexão TCP 1:1.

      Para solucionar seu problema no PascalSCADA, será necessário uma porta TCP/IP para cada equipamento que vc precisa comunicar.

      1. Certo… Quando você fala uma porta para cada equipamento você esta se referindo a uma porta física ou uma porta componente do Pascalscada, se for a componente, você teria algum exemplo de como gerenciar essa portas? Sei que a pergunta é simples, mas acontece que só havia tido experiencias com portas seriais.
        Ahhh… outra coisa, eu gostaria também de parabeniza-lo Fabio, com certeza sei q não se lembra de mim, mas a uns 7 ou 8 anos eu fiz meu primeiro contato contigo, eu ainda morava em Vitória ES, agora estou em Petrolina PE e fico muito feliz de ver que seu trabalho permanece em desenvolvimento e ajudando dessa maneira. Desenvolvi algumas soluções usando o PascalScada, como prensas, sistemas de pesagem e o maior foi desenvolvido a uns 3 anos, um sistema de gerenciamento de 60 medidores de grandezas elétricas da Schneider Electric, PM1200, usando a serial RS232->RS485 direto nos equipamentos de shopping aqui da região.

        1. Boa tarde Rafael!

          Lembro de ti sim, você me enviou screenshots de algumas de suas aplicações a alguns anos (que estão publicados na pagina de screenshots). Se quiser mandar mais alguns screenshots das suas aplicações, me ajuda bastante.

          Bom respondendo sua pergunta, são necessário vários componentes TCP_UDPPort do PascalSCADA inseridos na sua aplicação. Este componente representa um socket tcp/ip (que é uma das várias conexões lógicas que um equipamento pode ter) que correm sobre uma porta física, que geralmente é ethernet. Então sua solução terá um PC com uma porta ethernet ligada a um switch, e deste sairá a conexão física (leia cabos) para todos os seus equipamentos. Neste PC seu PC com uma porta ethernet (porta fisica) estará rodando uma aplicação feita no PascalSCADA com vários componentes TCP_UDPPort representando várias conexões lógicas, cada uma endereçada para um equipamento, todas saindo pela mesma porta ethernet do seu PC.

          Espero ter conseguido explicar a lógica de funcionamento de uma aplicação com multiplas conexões TCP/IP.

  4. Boa noite Fabio,

    Olha eu aqui de novo… quando desabilitamos o AutoRead e o AutoWrite, o comando para ler é simples de usar… mas na hr de usar o de escrita ele pede algumas informações que eu não soube decifra. Quanto ao prints… vou organizar e mandar tudo já com essa nova aplicação!!!

  5. Hi, Fabio! Thanks for your great work!
    I am trying to use SerialPortDriver to connect Modbus RTU via MOXA 5110 tcp NPort (Win32). Everything works fine, but after the program is completed, the process remains in memory, and the virtual COM port remains blocked. How to complete the process and release the port? My code OnFormClose:
    SerialPortDriver1.Active:=False;
    SerialPortDriver1.COMPort:=”;
    SerialPortDriver1.Free;
    Thank you in advance!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

HMI/SCADA para desenvolvedores