[ag-automation] application layer use cases for fieldbus stack

Tue Jul 10 17:48:21 CEST 2007

Hello, 
because a drive interface need set_position and act_position at the same time real drive fieldbusses like SERCOS use just one TPU to transport all the data. But of course there are fieldbusses like CAN, where you have a number of TPUs. In this case a TPU is defined just to synchronize the whole system. In the FDDI this is done with the SYNC-Flag in the attribute of the TPU (It is already defined in fddi.h!). So a application would wake up on the one TPU with the sync attribute. All other TPUs are just read or written, without callback or explicit send. Alternativly the master system itself can explicitly sent/write the sync TPU to synchronize all attached devices. The configuration must asure that only one entity (application /device/fddi-driver) in the system write/send a sync TPU. Of course different subsets of TPUs can be controlled by different entities.

Regards

Dieter Hess 

---------------------------------------------------- 
We software Automation. 

3S-Smart Software Solutions GmbH 
Dieter Hess 
Geschäftsführer 
Memminger Str. 151, DE-87439 Kempten 
Fon +49-831-54031-0, Fax +49-831-54031-50

Email: d.hess at 3s-software.com 
Web: http://www.3s-software.com 

Besuchen Sie das CoDeSys Internet-Forum unter http://forum.3s-software.com/

3S-Smart Software Solutions GmbH 
Geschäftsführer: Dipl.Inf.Dieter Hess, Dipl.Inf. Manfred Werner  
Handelsregister:  Kempten HRB 6186 
USt-IDNr. DE 167014915

-----Ursprüngliche Nachricht-----
Von: ag-automation-bounces at www.osadl.org [mailto:ag-automation-bounces at www.osadl.org] Im Auftrag von Robert Schwebel
Gesendet: Dienstag, 10. Juli 2007 16:35
An: ag-automation at www.osadl.org
Betreff: [ag-automation] application layer use cases for fieldbus stack

Dear Colleagues,

We yesterday had a brainstorming meeting at PTX and discussed the requirements for the OSADL fieldbus stack. While we think we are making progress in understanding how things have to be structured there are still a lot of questions left which I'd like to discuss here, especially with regard to application use cases. Note that this is purely process data oriented for now - no async operations involved.

Let's further assume we have an "application object" which is a super simple motion controller, like this one:

+----------------------------------+
I              drive               I 
+----------------------------------+
I +setSpeed(speed:uint32):int      I
I +getPosition(out pos:uint32):int I
+----------------------------------+

The implementation of "drive" wants to be coded against the LDI, which offers a process variable abstraction; let's assume a super simple one (it isn't so simple in reality, but for the use cases let's forget that for now):

+--------------------+
I         pv         I
+--------------------I
I -key               I
I -value             I
+--------------------+
I +getValue(out val) I
I +setValue(in val)  I
+--------------------+

Now let's assume that "drive" connects to two fieldbusses, one that transports pv_speed to the real motor and one that transports the measured pv_position from the encoder to the controller. So the stack would put both of the pvs into a separate transportation unit (tpu), one "out" tpu (speed) and one "in" tpu (position).

So in summary, "drive" has it's personal "process image", not being continuous in memory, but being two pv objects being spread over two TPUs. We called these private process images "process variable groups".

I'm now wondering which use cases happen inside of application objects.
Here's a list of pseudocode examples which come to my mind:

A) Locking

   while (!endme) {
	pv_group_lock(&group);
	pv_get(&pv, &somewhere);
	pv_set(&pv, value);
	...
	pv_group_unlock(&group);
	sleep_until_next_period();
   }

   This is the simple PLC case, one thread/process, gaining access to
   the pv_group, then reading/processing/writing, giving up access and
   waiting until it's cycle is over. Other processes may also run, even
   with different cycle times.

B) Blocking on Change

   while (!endme) {
	pv_group_lock_on_pv_change(&group, &pv_position, timeout);
	/* we wake up when the TPU containing pv_position comes in */
	...
	pv_group_unlock(&group);

   }

C) Callback on Change

   pv_group_callback_on_group_change(&group, function);

Cases B) and C) are not so simple: when should we wake up? If one of the included TPUs comes in? On every incoming TPU? How do we do the locking in a race free way? Other concurrent processes may do TPU locking in a different order. But from an application point of view, we'd like to do the locking on the logical pv group, because that's what the application wants to know.

In past implementations of our libpv we have done a very simple "per process image" locking: when entering the critical section, we've locked the whole image. That's not very performant, but simple. Now, thinking all this over, we came to the conclusion that we also want to lock only the part of the process space which really needs locking.

And, there's another use case: streaming. For example, we have an application which reads data from a local measurement system via CANopen, collects the data, sends it over an EtherCAT line to a second box and converts it to a second local CANopen bus. In such a situation it is necessary to put all TPUs into a buffer queue and never lose one of them, wereas the realtime requirements are more or less relaxed, as long as one gets all TPUs. The same scenario is there for ultrasound
measurement: a data logger gets data sets (TPUs) out of an FPGA, queues it in a buffer line and pushes them onto a hard disc. That's no different abstraction, and I'd like to solve it with the same data structures.

Now my questions:

- Are the scenarios A-C above realistic for your applications?

- Especially with regard to the "on change" use cases - how are the
  requirements in YOUR application?

- On which "changes" would you like to be woken up? Per pv? Per TPU? Per
  pv_group? Why?

- Can you explain further use cases?

- For variables which are of "out" type (application -> fieldbus): are
  there multiple threads which could want to write to a pv? If yes, is
  there a need for inter-pv-locks, for example because a PID set of
  controller parameters is only to be changed atomically?

Thanks for your feedback.

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

_______________________________________________
ag-automation mailing list
ag-automation at lists.osadl.org
https://lists.osadl.org/cgi-bin/mailman/listinfo/ag-automation