view release on metacpan or  search on metacpan

lib/Device/Modbus.pm  view on Meta::CPAN

 $client->send_request($req) || die "Send error: $!";
 my $response = $client->receive_response;

A Modbus server:

 use Device::Modbus::TCP::Server;
 
 {
     package My::Unit;
     our @ISA = ('Device::Modbus::Unit');
 
     sub init_unit {
         my $unit = shift;
 
         #                Zone            addr qty   method
         #           -------------------  ---- ---  ---------
         $unit->get('holding_registers',    2,  1,  'get_addr_2');
     }
 
     sub get_addr_2 {
         my ($unit, $server, $req, $addr, $qty) = @_;
         $server->log(4,"Executed server routine for address 2");
         return 6;
     }
 }

 my $server = Device::Modbus::TCP::Server->new(
     log_level => 4,
     log_file  => 'logfile'
 );

 my $unit = My::Unit->new(id => 3);
 $server->add_server_unit($unit);

 $server->start;

=head1 DESCRIPTION

Modbus is an industrial communication protocol. It is implemented by many industrial devices such as servo motors, temperature controllers, force monitors, and Programmable Logic Controllers. Device::Modbus is a set of Perl modules that should allow ...

=head2 The Modbus data model

With Modbus, a I<client> sends I<requests> to a I<server> device, which returns I<responses>. We'll use the term I<unit> when referring a device capable of processing Modbus requests. Most of the time, a unit is one physical device, but a physical de...

Data within a unit is accessible through the following addressable tables:

=over

=item * Discrete inputs

=item * Discrete outputs (or coils)

=item * Input registers

=item * Holding registers

=back

Note that discrete outputs are called coils as well. This name makes reference to the automation origin of the protocol, where a coil is the actuator of an electro-mechanical relay.

Tables may even overlay each other. For example, it is not uncommon to address a particular discrete input as a bit of a register address: bit 34 may be the 3rd bit of the 3rd input register. In this distribution, addressable tables are called I<zone...

To summarize, the Modbus data model breaks a I<unit> into I<zones> in which data is addressable.

Now, Modbus uses Protocol Data Units. The PDUs are the basic blocks defined by the protocol; they are the binary messages that flow between clients and servers. PDUs encapsulate a request from a client or a response from a server. They are independen...

PDUs are further encapsulated into Application Data Units, which add a header and (in the RTU case) a footer with further information as needed for the communication layer. Device::Modbus handles the RTU and the TCP variants of the protocol through L...

Finally, clients produce requests which are sent to servers, and they receive requests in return. This distribution provides the tools to build both servers and clients.

=head2 Request generalities

Let's talk now about requests. Requests have basically four parameters. The first is implicit in the request code itself, sice each kind of request is directed at a particular zone. The other parameters are the starting address, the number of registe...

For example, we have Read Coil, Write Single Coil and Write Multiple Coils, which refer to the Discrete Outputs zone. As for addresses, a read request for multiple registers that starts at address 1 and demands 5 registers will fetch regiesters 1, 2,...

=head1 GUIDE TO THE DOCUMENTATION

The main protocol is described in the following documents:

=over

=item L<Device::Modbus::Client>

=item L<Device::Modbus::Server>

=back

The RTU and TCP variants are implemented in two separate distributions, L<Device::Modbus::RTU> and L<Device::Modbus::TCP>. This way you can install only what is needed for your application.

=head2 Documentation for writing clients

A client must be able to:

=over

=item 1. Open a connection to a server

=item 2. Create request objects

=item 3. Send requests to a server

=item 4. Receive responses to its requests

=item 5. Close the connection to the server

=back

The first point, which depends on the communication layer, is described in L<Device::Modbus::RTU::Client> and L<Device::Modbus::TCP::Client>. Items 2, 3, 4 and 5 are common to all clients, and therefore, they are documented in L<Device::Modbus::Clien...

=head2 Writing servers

Servers are more complex. They must:

=over

=item 1. Define one or more units, their addressable zones, and implement their functionalities

=item 2. Add those units to a Modbus server

=item 3. Define the interface where the server will listen for connections