A
Given the data types, I suggest a code structure as follows.
I imagine a group of objects to run
1) For example: 5 objects - the first a state-transition language which defines the states of StartUp, Normal, Shutdown, and Fault. The other 4
being ladder logic for each of the states. Here we would have 2 different command processors running.
2) For example: a BASIC or math formula interpreter to run inside of flow blocks - or support the 4 languages of IEC1131.
3) The code design should allow read-only & reenterant command processors to be created (coders options)
4) I imagine the first thing most code should do is allocate some data memory - perhaps the data memeory can have a similir (but slightly
different) organization.
The first object is a header which identifies & envelops the whole code memory. Only 1 such object will exist. I suggest we start all IMPORTANT objects with a unique key or id to allow for effective debugging & error trapping:
typedef struct t_mcod { /* master code record */
UINT32 obj_id; /* force to 0x6D436F44 ("mCoD") */
UINT32 length; /* total size of code memory */
UINT32 count; /* count of code objects to follow */
} MAS_CODE;
What follows could be thought of as a program which includes the type of command processor to run it, a name, revision info. These code objects
could be thought of as alternative programs to run, or parallel programs etc :
typedef struct t_code { /* normal code record */
UINT32 obj_id; /* force to 0x634F6445 ("cOdE") */
UINT32 length; /* total size of this code object */
UINT32 proc_id; /* processor id to run this type of
code */
UINT16 proc_major; /* minimum revision of processor id */
UINT16 proc_minor; /* - ditto - */
UINT32 glob_opts; /* flags/options common to all code */
UINT32 local_opts; /* flags/options specific to this
proc_id */
CODE_OBJ *next; /* next link - linked list for this
proc_id */
CODE_OBJ *prev; /* next link - linked list for this
proc_id */
UINT16 rev_major; /* major.minor to track code revisions */
UINT16 rev_minor; /* - ditto - */
DATE rev_date; /* date code object created */
DATE rev_time; /* date code object created */
STRING32 code_name; /* program name in memory */
VISIBLE_STRING remarks; /* text comments, min 2 bytes, max =
256 */
} CODE_OBJ;
The following is a sub-code block - more like a sub-routine. These would be called by the major code objects above :
typedef struct t_scod { /* sub-code record */
UINT32 obj_id; /* force to 0x53634F64 ("ScOd") */
UINT32 length; /* total size of this sub-code object */
UINT32 proc_id; /* processor id to run this type of
code */
} SUB_CODE;
August Albert
[email protected]
Singapore
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I imagine a group of objects to run
1) For example: 5 objects - the first a state-transition language which defines the states of StartUp, Normal, Shutdown, and Fault. The other 4
being ladder logic for each of the states. Here we would have 2 different command processors running.
2) For example: a BASIC or math formula interpreter to run inside of flow blocks - or support the 4 languages of IEC1131.
3) The code design should allow read-only & reenterant command processors to be created (coders options)
4) I imagine the first thing most code should do is allocate some data memory - perhaps the data memeory can have a similir (but slightly
different) organization.
The first object is a header which identifies & envelops the whole code memory. Only 1 such object will exist. I suggest we start all IMPORTANT objects with a unique key or id to allow for effective debugging & error trapping:
typedef struct t_mcod { /* master code record */
UINT32 obj_id; /* force to 0x6D436F44 ("mCoD") */
UINT32 length; /* total size of code memory */
UINT32 count; /* count of code objects to follow */
} MAS_CODE;
What follows could be thought of as a program which includes the type of command processor to run it, a name, revision info. These code objects
could be thought of as alternative programs to run, or parallel programs etc :
typedef struct t_code { /* normal code record */
UINT32 obj_id; /* force to 0x634F6445 ("cOdE") */
UINT32 length; /* total size of this code object */
UINT32 proc_id; /* processor id to run this type of
code */
UINT16 proc_major; /* minimum revision of processor id */
UINT16 proc_minor; /* - ditto - */
UINT32 glob_opts; /* flags/options common to all code */
UINT32 local_opts; /* flags/options specific to this
proc_id */
CODE_OBJ *next; /* next link - linked list for this
proc_id */
CODE_OBJ *prev; /* next link - linked list for this
proc_id */
UINT16 rev_major; /* major.minor to track code revisions */
UINT16 rev_minor; /* - ditto - */
DATE rev_date; /* date code object created */
DATE rev_time; /* date code object created */
STRING32 code_name; /* program name in memory */
VISIBLE_STRING remarks; /* text comments, min 2 bytes, max =
256 */
} CODE_OBJ;
The following is a sub-code block - more like a sub-routine. These would be called by the major code objects above :
typedef struct t_scod { /* sub-code record */
UINT32 obj_id; /* force to 0x53634F64 ("ScOd") */
UINT32 length; /* total size of this sub-code object */
UINT32 proc_id; /* processor id to run this type of
code */
} SUB_CODE;
August Albert
[email protected]
Singapore
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
