[ag-automation] configuration concept for fieldbus stack

[Robert Schwebel]

On Tue, Jul 17, 2007 at 02:26:47PM +0200, Dieter Hess wrote:
> > Is it somehow possible to address digital I/Os via register access? As
> > far as I understand the modbus spec there is a modicon extension,
> > but the standard itself says to access the digi I/Os via
> > read/write_single_coil.
> 
> Th modbus stack should always read at bytes from the devices with
> register access and the application should access the single bits (=
> single coil) in the bytes readed.

But writing to "coils" (digital outs) and registers (16 bit values) is a
different thing regarding to the modbus spec; it uses another function
code -> another "address space". So I'm wondering how you can use a
single "register" address space to perform all actions.

For the Wago modbus coupler we are currently using there is a
representation of the digital outs in the "register" space, but that
seems not to be a feature specified in the modbus spec but a modicon
extension.

> > Is it the intended way to issue a CMD_START here? Do we have to
> > check if the bus driver goes into "operational" state here?
> > Blocking/nonblocking? Are other steps necessary?
> 
> Commands are blocking as I described it (however we can discuss,
> wether it should be!). Anyway it is a good id to ask for the state,
> because the start command can fail or be timed out.

Ok, so I'll introduce the usual O_NONBLOCK mechanism known from other
posix calls (see 'man 3 read' for reference). This makes it possible to
have both scenarios in the API:

- issue "CMD_START" and block until the stack has gone into
  "operational" state

- issue "CMD_START" with O_NONBLOCK and come back immediately

I'll also add a timeout.

> In your example the following is missing/no correct (or I don't
> understand it):
> - The modbus driver must be bound to a low level driver.

That's done by the 

	fddi_iface_attr_setclass(&modbus0_attr, "libmodbus");

call. It connects this instance of the soon-to-be-initialized
modbus0_iface to the backend driver for libmodbus (which is an example
for a certain "vendor stack" -> an open source modbus library in this
case, but you can also think of it as any $VENDOR stack).

> May be "modbus0_attr" is a reference to a low level driver?

No, the "attr" thing is a trick to keep a constructor API constant while
it's arguments may vary over the time. The "iface" object is set up by
providing an "attr" object, containing the initialization values. When
over the time the standard for the API evolves and the attr object gets
more values, the call to fddi_iface_init() remains constant.

See for example "man 3 pthread_create" for reference.

> In the case of the Modbus TCP this is a IP socket interface.

Yes, that's still an unsolved issue in the current code. The IP address
of the bus coupler is a property of the IO device, so it should be put
into the IO device's configuration sniplet.

> - The start command is executed on a device not on the interface

Ah, right. That means that if you have different devices on one bus,
you'll have to issue a CMD_START command for each device.

Would it make sense to let

	fddi_iface_cmd(&modbus0_iface, CMD_START)

propagate the CMD_START command to all of it's IO devices?

rsc
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9