SMM interface

S

Thread Starter

Simon Martin

Hi All,

This the status of my SMM client interface. The IO manager registers with the name "IOManager" and will have write access to all inputs.

/* *******************************************
* definition of the plc context
*
* 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_context {
int id;
};

typedef struct tag_plc_context plc_context_t;

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

/* context generation/destruction */
plc_context_t *register(const char *process_name);
void unregister(plc_context_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_context_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



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Tue Jan 18 10:10:16 2000 Simon Martin wrote...
>
>Hi All,
>
>This the status of my SMM client interface. The IO manager registers with
>the name "IOManager" and will have write access to all inputs.
>
>/* *******************************************
> * definition of the plc context
> *

A small request, could you call it something besides context? AB PLC-3 used the term context to mean separate programs within the same
controller. Only one could be "user visible" and executing at any one time.

I may have more comments on this message later.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Tue Jan 18 10:10:16 2000 Simon Martin wrote...
>
>Hi All,
>
>This the status of my SMM client interface. The IO manager registers with
>the name "IOManager" and will have write access to all inputs.
>

This looks really good. However I have a question.

It seems very I/O centric, what about all the other areas of data table?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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

But why does the I/O and other data have to be treated the same way.

There are different priorities here. The logic engine may need to see the (I/O or some of it) on a fast update <1mS, but the internal database may
only need external access to the HMI, the update here can easily (as it currently is in existing systems) be up in the (low) 100's mS.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Stan Brown

This looks really good. However I have a question.

It seems very I/O centric, what about all the other areas of data
table?


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Simon Martin:
> This the status of my SMM client interface. The IO manager registers with
> the name "IOManager" and will have write access to all inputs.

Will there be just one IO manager?

I'd suggest having each I/O driver as a separate process, and each should have write access for the inputs it's handling.

(Of course this can also be done through an IO manager, but much of the interface will be simply duplicated, maybe with different function names.)

> struct tag_plc_context {
> int id;
> };

I suggest that the first field in any struct ought to be
int magic;


> 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);

I'd probably do this by a partial commit_io() (maybe "commit_io_point()") followed by a regular get...(), but that's probably neither here nor there. Same for the outputs - a regular set...() followed by a commit_io_point().

But your way is just as good, so don't consider this paragraph a criticism, just food for thought.


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
On Thu Jan 20 19:05:18 2000 Jiri Baum wrote...
>
>Simon Martin:
>> This the status of my SMM client interface. The IO manager registers with
>> the name "IOManager" and will have write access to all inputs.
>
>Will there be just one IO manager?

I think we may have a terminology issue here.

I think we all agree that there need to be multiple I/O scanners. Then we diverge.

I see that they, and the logic engines, timer engines, etc will all call a common set of library routines to access the shared memory I/O
data tables.

Some others seem to feel that there needs to be a process that is used as an interface to these shared memory segments.

My question is why? Is it creation/destruction of these segments? For as
I see it the library routines could handle this. The first process that called them should trigger the library to read the config files, and set
up the shared memory segments if they don;t already exist.

Or is there some other reason that people think we need this "shared memory manager" task?

>I suggest that the first field in any struct ought to be
> int magic;
>

That being the "ID" of the task? If so I think this is mandatory.

>But your way is just as good, so don't consider this paragraph a criticism, just food for thought.
>

I second that.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, Jan 21, 2000 at 08:54:58AM -0500, Stan Brown wrote:
> On Thu Jan 20 19:05:18 2000 Jiri Baum wrote...
...
> >I suggest that the first field in any struct ought to be
> > int magic;


> That being the "ID" of the task? If so I think this is mandatory.

No!

The init routine puts some number into the magic field, and all other routines handling the struct check that it's still there. If it isn't, then
either you got handed a pointer to the wrong thing, or something clobbered the struct. Either way, you have a problem.

As in:

int print_foo(foo*f) {
if (!p || p->magic!=FOO_MAGIC) {
... error ...
}
...
}


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
On Sun Jan 23 07:40:04 2000 Jiri Baum wrote...
>
>On Fri, Jan 21, 2000 at 08:54:58AM -0500, Stan Brown wrote:
>> On Thu Jan 20 19:05:18 2000 Jiri Baum wrote...
>...
>> >I suggest that the first field in any struct ought to be
>> > int magic;
>
>> That being the "ID" of the task? If so I think this is mandatory.
>
>No!
>
>The init routine puts some number into the magic field, and all other
>routines handling the struct check that it's still there. If it isn't, then
>either you got handed a pointer to the wrong thing, or something clobbered
>the struct. Either way, you have a problem.
>

I think you 2 are talking about apples & oranges.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun, Jan 23, 2000 at 04:40:26PM -0500, Stan Brown wrote:

> I think you 2 are talking about apples & oranges.

No, we aren't.

He proposed a struct, like this:
> struct tag_plc_context {
> int id;
> };

I suggested that the first field in any struct ought to be
int magic;
that is, that the struct ought to look like this:
# struct tag_plc_context {
# int magic;
# int id;
# };

Better?

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