SMM: work availability

J

Thread Starter

Jiri Baum

Hello Simon Martin,

good to see you back. I'll update your entry in doc/Maintainers later today.

> By the way I had a wonderful holiday and am back on-line again. Next week
> I will be in the UK and will have more time available for this project
> (at least 2 hours a day).

Will you be able to put together the Shared Memory Manager soon? It's basically the first part that needs to be written, so that the other bits can interface to it, and I think some people at least have been waiting...

I can do it if you don't have time, but I didn't want to start when you weren't around since you've volunteered to do it.

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Simon Martin

Hi all,

I shall start coding this tomorrow (my personal customers are a bit nervous at the moment). I intend to have a working SMM and client API by the end of Feb. I'll post results as and when I have them. To recap on my design (please correct the things I have missed in my absence!!!):

Config files reside in /etc/puffin. The IO Map is specified in the iomap.conf file. I expect this file to just be a set of global specifications and a sequence of "include" statements. The actual io point specifications being in individual files specified by the include. An io
point is specified by

<type> <file> : <point> / <element> {persistent | volatile [= <initial
value>]} <owner>

The SMM is responsable for persistance and handing each client a "photograph" of the IO on request. The API is defined as follows:

/* *******************************************
* definition of the plc environment
*
* each process that requires access to the shared memory
* must hold a valid context. the context is used to identify
* the process and it's attributes to the shared memory
* manager and thus permit access control, etc to the
* io table
* ******************************************* */

struct tag_plc_env {
int id;
};

typedef struct tag_plc_env plc_env_t;

/* *******************************************
* prototypes
* ******************************************* */

/* context generation/destruction */
plc_env_t *register(const char *process_name);
void unregister(plc_env_t *env);

/* create an io table for this process. this will populate a memory area that belongs to this process with a copy of the io in the shared memory manager.

on successful completion it returns '0', otherwise it returns an error status.
*/
int init_scan(plc_env_t *env);

/* update the SMM io data

on successful completion it returns '0', otherwise it returns an error status.
*/
int commit_io(plc_env_t *env);

/* retrieve the address of an io point

on successful completion it returns a the address of the io_point to be set, otherwise it returns '0' and sets errno.
*/
long get_iopoint_addr(plc_env_t *env,const char *name);

/* retrieve the value for an input. the immediate functions force the shared memory manager to initiate a transfer directly from the io manager.

on successful completion it returns a pointer to a plc_io_point structure, otherwise it returns null and sets the errno.
*/
void *get_input_by_name(plc_env_t *env,const char *name);
void *get_input_by_addr(plc_env_t *env,const long address);
void *get_input_by_name_immediate(plc_env_t *env,const char *name);
void *get_input_by_addr_immediate(plc_env_t *env,const long address);

/* set the value for an output. the immediate functions force the shared memory manager to initiate a transfer directly to the io manager.

on successful completion it returns a pointer to a plc_io_point structure, otherwise it returns null and sets the errno.
*/
int set_output_by_name(plc_env_t *env,const char *name);
int set_output_by_addr(plc_env_t *env,const long address);
int set_output_by_name_immediate(plc_env_t *env,const char *name);
int set_output_by_addr_immediate(plc_env_t *env,const long address);

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

There is a chasm of carbon and silicon the software cannot bridge

PS: Where did everyone go?

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Simon Martin:
> I shall start coding this tomorrow (my personal customers are a bit
> nervous at the moment). I intend to have a working SMM and client API by
> the end of Feb. I'll post results as and when I have them.

If you stick it in the CVS, interested parties can watch the progress...

(I think this is significant enough to have its own top-level directory, say smm; documentation might go into doc/smm)

> * each process that requires access to the shared memory
> * must hold a valid context. the context is used to identify
> * the process and it's attributes to the shared memory
> * manager and thus permit access control, etc to the
> * io table

Would it make sense to have a pre-defined context (or a special name) which means "pure read-only access" and doesn't identify a particular process?

> struct tag_plc_env {
> int id;
> };

> typedef struct tag_plc_env plc_env_t;

Probably less confusing to combine the two... also, every structure should be protected by magic.

typedef struct {
int magic;
int id;
} plc_env_t;

...
> /* retrieve the value for an input. the immediate functions force
> the shared memory manager to initiate a transfer directly from
> the io manager.

Probably better to call them just points or something. As far as the SMM interface is concerned, there are just "read-only points" and "read-write points".

(Don't forget - from the point of view of the I/O scanners, inputs are read-write and outputs are read-only, which is opposite to what you are
saying. Internal coils mix this up even more completely.)

It might also be worthwhile to leave the "immediate" semantics as WDTL (We'll Do That Later) in order to get the basic functionality quicker; perhaps at present just get a fresh copy from the shared memory, and leave hooks in for later. (We might also want to restrict who can trigger full-immediate inputs/outputs, and who's only allowed to get a fresh copy from the SMM but not touch the actual IO timing.)

> on successful completion it returns a pointer to a plc_io_point
> structure, otherwise it returns null and sets the errno.

Who and when deallocates that structure?

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top