[ag-automation] configuration concept for fieldbus stack

[Robert Schwebel]

On Tue, Jul 10, 2007 at 05:34:53PM +0200, Dieter Hess wrote:
> if no cyclic communication is used just don't define TPUs in the
> configuration and use async read and write services. Modbus is not a
> typical fieldbus, because there is no difference between
> cyclic/synchrounus and acyclic/asynchrounous communication.

Yup, true.

> In fact there is only master initiated asynchrounous communication.
> Cyclic TPUs are just "simulated" by the fddi-driver to let modbus look
> like a real fieldbus protocol and to get a realistic use case for the
> fddi. 

I'm wondering if TPUs are necessarily cyclic. It's process data, but the
question when a TPU transfer is being triggered should IMHO be answered
by the application.

Maybe our understanding of TPUs is still inconsistent. I understand a
TPU as a "set of process variables". Right?

Another question: I don't understand yet how the device in your example
looks like; let's for example only take one part:

<FddiDevice>
  ...
  <FddiParam Id="1011" Name="TpuAdress" Type="int">20</FddiParam>
  <FddiParam Id="1012" Name="TpuSize" Type="int">4</FddiParam>
  <FddiParam Id="1013" Name="TpuGranularity" Type="int">1</FddiParam>
  <FddiParam Id="1014" Name="TpuUpdateRate" Type="int">50</FddiParam>
  <FddiParam Id="1014" Name="TpuDirectionWrite" Type="bool">true</FddiParam>
  ...
</FddiDevice>

Is that a TPU at address 20? Does that correspond to modbus address 20?
It's lenth is 4 bytes, consisting of 4 1-byte process variables?

When there is more than one read-TPU defined for a device: why is it
possible to specify different update rates then? I understand that
having different update rates is necessary (take a slow temperature
sensor plus a fast motor position value, which would be split up into
different TPUs). But I'd supposed that it is possible to put different
PVs into one TPU, being maybe spread over the address space, like this:

<FddiDevice id="wagoclamp">

  <name>Wago Clamp</name>

  <!-- do async stuff here, similar to your example -->

  <tpu direction="in" updaterate="100">

    <pv id="motor_speed">
      <property id="modbusaddress" value="30001"/>
      <name>Motor Speed</name>
      <type>uint16_t</type>
      <offset>0x0</offset>
    </pv>

    <pv id="motor_pos">
      <property id="modbusaddress" value="30042"/>
      <name>Motor Position</name>
      <type>uint16_t</type>
      <offset>0x2</offset>
    </pv>

  </tpu>

</FddiDevice>

Don't beat me because of naming or cdata-vs-attributes, it's just in libpv
nomenclature because I can :-) 

libpv allows to put <property/> tags into everything; in this case it is
interpreted in modbus context, which would know how to handle it correctly.

This would result in a TPU containing

	uint16_t motor_speed;
	uint16_t motor_pos;

in that order, although the values have been taken from modbus input registers
at addresses 30001 and 30042 (spread).

Regards,
Robert Schwebel
-- 
 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