Module status maps

P

Thread Starter

Philip Costigan

Hi all,

In developing my modbus_tcp module I have started to ponder on the method of telling the linuxplc that communications has failed or that the module has stopped and possibly a whole miriad of information about the module.

My first thought was to create generic names for my modules diagnostics and then appending them into the linuxplc.conf file. :p

Another Idea is to have another smm for system diagnostics. Maybe?

Then I had another idea that requires some thought. Maybe the points in the smm should auto address. Then each module could have their own key words that pass diagnostic info into the smm. Module developers can then provide a conf file that would only need including. The conf file would *not* need editing at all.

The new format for linuxplc.conf would be somthing like this.

<snip>

[SMM]
point my_input "my favorite input" my_module type bool
point my_output "my flashy output" your_module type bool


[my_module]
*include my_module.conf
my_point my_input 192.168.0.22 1 182 din 0
my_point my_output 192.168.0.23 1 12 dout 0
blah blah blah...........................


</snip>

inside the modules conf file my_module.conf the following tags would be added

<snip>

[SMM]
point my_module_run_status "status of this module" my_module type int
point my_module_error_val "error code for this module" my_module type int
blah blah blah.........................

</snip>


One disadvantage to some people is that the same point can not have more than one name but in my book that keeps each point's documentation unique like it should be. ( I'll save this debate for another day. )


Just another subject to throw on the table.
I hope this dosn't repeat too much old discussion but we do need to do somthing.

Phil

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Philip Costigan:
> In developing my modbus_tcp module I have started to ponder on the method
> of telling the linuxplc that communications has failed or that the module
> has stopped and possibly a whole miriad of information about the module.

Right now, these should go into the log file.

> My first thought was to create generic names for my modules diagnostics
> and then appending them into the linuxplc.conf file. :p

Proposal: the diagnostic point names should be a concatenation of the module name and their function; if the point doesn't exist, the module
should log this but otherwise continue normally. Like this:

char *module = plc_module_name();
char *diag_name = strdup3(module, "_", "OK"); /* concatenate */

plc_pt_t diag = plc_pt_by_name(diag_name); /* try to obtain handle */

if (!diag.valid) { /* point not found */
plc_log_wrnmsg(...); /* log warning */
diag = plc_pt_null(); /* make it a data sink */
}

free(module); free(diag_name); module=diag_name=NULL;

Note: this means that the diag point will not necessarily remember its previous value. Therefore program logic must not depend on it.

Later logic can determine whether diag is a datasink by using plc_pt_len(), which returns zero for null points and positive numbers otherwise.

> Another Idea is to have another smm for system diagnostics. Maybe?

Eventually we may want to timestamp all points. The timestamp may have a "quality" field. But I think that's definitely in the WDIL basket.

> Maybe the points in the smm should auto address.

Yes, they should. To some extent that was the thinking behind the "at" keyword. I haven't been doing much coding at all on the linuxplc the last
three months or so, but I think Mario has laid much of the groundwork for this to happen.

> Then each module could have their own key words that pass diagnostic info
> into the smm. Module developers can then provide a conf file that would
> only need including. The conf file would *not* need editing at all.
[snip]

This wouldn't work, because module names are dynamic (determined at startup-time). Right now using the --PLCmodule switch, when the launcher
gets written it may be easier still. The points in the module-conf would have the wrong owner.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Philip Costigan

On Sat, 23 Sep 2000, Jiri wrote:

> > I have started to ponder on the method
> > of telling the linuxplc that communications has failed or that the module
> > has stopped and possibly a whole miriad of information about the module.
>
> Right now, these should go into the log file.

OK


> Proposal: the diagnostic point names should be a concatenation of the
> module name and their function; if the point doesn't exist, the module
> should log this but otherwise continue normally. Like this:
>
> char *module = plc_module_name();
> char *diag_name = strdup3(module, "_", "OK"); /* concatenate */
>
> plc_pt_t diag = plc_pt_by_name(diag_name); /* try to obtain handle */
>
> if (!diag.valid) { /* point not found */
> plc_log_wrnmsg(...); /* log warning */
> diag = plc_pt_null(); /* make it a data sink */
> }
>
> free(module); free(diag_name); module=diag_name=NULL;
>
> Note: this means that the diag point will not necessarily remember its
> previous value. Therefore program logic must not depend on it.
>
> Later logic can determine whether diag is a datasink by using plc_pt_len(),
> which returns zero for null points and positive numbers otherwise.

Thats close to what I'm after but it would be nice to not have to edit linuxplc.conf in any major way to make the data available to logic processing.


> > Maybe the points in the smm should auto address.
>
> Yes, they should. To some extent that was the thinking behind the "at"
> keyword. I haven't been doing much coding at all on the linuxplc the last
> three months or so, but I think Mario has laid much of the groundwork for
> this to happen.
>
> > Then each module could have their own key words that pass diagnostic info
> > into the smm. Module developers can then provide a conf file that would
> > only need including. The conf file would *not* need editing at all.
> [snip]
>
> This wouldn't work, because module names are dynamic (determined at
> startup-time). Right now using the --PLCmodule switch, when the launcher
> gets written it may be easier still. The points in the module-conf would
> have the wrong owner.

OK. So this is where dynamic memory allocation to the smm becomes a possible requirement. (it could get very complicated).

What direction should I take right now?
1. Just log errors to a logfile. ( which is what I am doing really ).
2. Do the concatination thingy
3. Just hang back and wait until someone has a brain wave.

Phil

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

Philip Costigan

> On Sat, 23 Sep 2000, Jiri wrote:

> > Proposal: the diagnostic point names should be a concatenation of the
> > module name and their function; if the point doesn't exist, the module
> > should log this but otherwise continue normally. Like this:
> >
> > char *module = plc_module_name();
> > char *diag_name = strdup3(module, "_", "OK"); /* concatenate */
> >
> > plc_pt_t diag = plc_pt_by_name(diag_name); /* try to obtain handle */
> >
> > if (!diag.valid) { /* point not found */
> > plc_log_wrnmsg(...); /* log warning */
> > diag = plc_pt_null(); /* make it a data sink */
> > }
> >
> > free(module); free(diag_name); module=diag_name=NULL;
> >
> > Note: this means that the diag point will not necessarily remember its
> > previous value. Therefore program logic must not depend on it.

Is it possible to create these points on the fly and then apend them to the file linuxplc.conf and then ask all the modules to re-read the linuxplc.conf file.

It sounds a bit tacky but the idea is food for thought.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Philip Costigan:
> Is it possible to create these points on the fly and then apend them to
> the file linuxplc.conf and then ask all the modules to re-read the
> linuxplc.conf file.

Well, the logic program needs to be written to take notice of them, so if they don't exist yet it'll trip its own (fairly serious) error. Besides, once you're writing the points into your logic program, it's not that much extra work to ask you to put them in the conf file.

If you're not using the points for anything, then the try-or-null mechanism is sufficient.

It may be an idea to have a general "alarm" mechanism. However, this will require some thought (and a lot of policy!), and most likely it'll feed off the logging functions to a great extent.

For instance, the logging library could keep track of the most serious warning/error so far (globally across the whole lPLC).


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > Proposal: the diagnostic point names should be a concatenation of the
> > module name and their function; if the point doesn't exist, the module
> > should log this but otherwise continue normally. Like this:
...

Philip Costigan:
> Thats close to what I'm after but it would be nice to not have to edit
> linuxplc.conf in any major way to make the data available to logic
> processing.

That's what the linuxplc.conf file does, any points you want available you have to specify in there.

How else will the IDE know the point exists?

...
> > module names are dynamic (determined at startup-time). Right now using
> > the --PLCmodule switch, when the launcher gets written it may be easier
> > still. The points in the module-conf would have the wrong owner.

> OK. So this is where dynamic memory allocation to the smm becomes a
> possible requirement. (it could get very complicated).

I'd rather not. Eventually it will be necessary (for on-line changes), but this isn't an on-line change. This is just a point, being made available
just like any other point.

> What direction should I take right now?
> 1. Just log errors to a logfile. ( which is what I am doing realy ).
> 2. Do the concatination thingy

I'm not so sure the concatenation thing was such a bright idea, on second thoughts. It may be better to just use a config variable, just like any other point name would, except that there's a null point as the default.

> 3. Just hang back and wait until someone has a brain wave.

That'll work, too. As I wrote in the other e-mail, any brain wave on this frequency is likely to be plugged into the logging library, in which case doing number 1 will be all that's wanted.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Philip Costigan

On Sun, 24 Sep 2000, Jiri wrote:
>
> Well, the logic program needs to be written to take notice of them, so if
> they don't exist yet it'll trip its own (fairly serious) error. Besides,
> once you're writing the points into your logic program, it's not that much
> extra work to ask you to put them in the conf file.
>
> If you're not using the points for anything, then the try-or-null mechanism
> is sufficient.
>
>
> It may be an idea to have a general "alarm" mechanism. However, this will
> require some thought (and a lot of policy!), and most likely it'll feed off
> the logging functions to a great extent.
>
> For instance, the logging library could keep track of the most serious
> warning/error so far (globally across the whole lPLC).
>

OK I think I see the light now.
If I use the point concatenated module name method and then just place a message into the log file that lets people know that some error points can be monitored if included into the linuxplc.conf then it can be up to the developer to decide whether to use them or not.

The message structure ( I guess ) would be somthing like

- WARNING - modbus_tcp - To monitor communication status for 192.168.7.23 \
add to [smm] point modbus_tcp_comm1 "communication error for 192.168.7.23" \
modbus_tcp at n


Let me know if this is a bit wordy.

Does all this ring true?

Phil.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun, Sep 24, 2000 at 08:34:57PM +1100, Philip Costigan wrote:
> On Sun, 24 Sep 2000, Jiri wrote:

> > Well, the logic program needs to be written to take notice of them, so
> > if they don't exist yet it'll trip its own (fairly serious) error.
> > Besides, once you're writing the points into your logic program, it's
> > not that much extra work to ask you to put them in the conf file.
...
> OK I think I see the light now.
> If I use the point concatenated module name method and then just place a
> message into the log file that lets people know that some error points
> can be monitored if included into the linuxplc.conf then it can be up to
> the developer to decide whether to use them or not.

Yup. Most likely this should be in a library somewhere eventually, but for now just write your own.

> The message structure ( I guess ) would be somthing like

> - WARNING - modbus_tcp - To monitor communication status for 192.168.7.23 \
> add to [smm] point modbus_tcp_comm1 "communication error for 192.168.7.23" \
> modbus_tcp at n


> Let me know if this is a bit wordy.

Since we don't have a logging policy, it's your module, you log whatever you like :) When a logging policy is made, we'll have to go through all code and make it follow that policy.

Personally, though, I do find it a bit wordy - I'd leave out the syntax of the linuxplc.conf line, just saying the point name...
- WARNING - modbus_tcp - communication status available on point
modbus_tcp_comm1
Or
- WARNING - modbus_tcp - communication status point
modbus_tcp_comm1 not found (ignored)
But then again maybe that's just me.


BTW, the syntax should probably be given as:
smm:point modbus_tcp_comm1 "..." modbus_tcp at n

> Does all this ring true?

Yup, rings true.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

Mario de Sousa

Hi everybody,

I'm back online on a regular basis...

Jiri Baum wrote:

> > OK I think I see the light now.
> > If I use the point concatenated module name method and then just place a
> > message into the log file that lets people know that some error points
> > can be monitored if included into the linuxplc.conf then it can be up to
> > the developer to decide whether to use them or not.
>
> Yup. Most likely this should be in a library somewhere eventually, but for
> now just write your own.
>
> > The message structure ( I guess ) would be somthing like
>
> > - WARNING - modbus_tcp - To monitor communication status for 192.168.7.23 \
> > add to [smm] point modbus_tcp_comm1 "communication error for 192.168.7.23" \
> > modbus_tcp at n
>
> > Let me know if this is a bit wordy.
>

I'm sorry to bother you all, but I wasn't quite able to follow all the logic behind this argument. Let me explain what I understood, and you can correct where I go wrong.

Phil wants to place status info in the SMM so other modules may get at it (network error, etc...).

It seems you want to create plc_points dynamically. Is this right? The SMM currently doesn't support this, and if I recall correctly, we had a previous discussion on this (point aliases, point structures, multi-owned points
...) and we got to the conclusion we were only going to support single-owned points, and allow for point aliasing, no dynamic points, but allow dynamic aliases (i.e. anonymous points). [Maybe we should get down and define some common
syntax/wording so we can all understand each other...]

Phil, could you please explain why you don't want to put the point definition in the config file?

Why can't we have something like ths:

[SMM]
point P1 ....
point P2 ....
point P3 ....
...

[module_A]
smm: point_alias comm_error_status_point P1
...


I'm sure you have considered the above already, but maybe you could please explain what you don't like about it?

Thanks,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

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

DigiMicro (Gilles Allard)

>Phil wants to place status info in the SMM so other modules may get at
>it (network error, etc...).
>
>It seems you want to create plc_points dynamically. Is this right? The
>SMM currently doesn't support this, and if I recall correctly, we had a
>previous discussion on this (point aliases, point structures, multi-owned >points ...) and
>we got to the conclusion we were only going to support single-owned
>points, and
>allow for point aliasing, no dynamic points, but allow dynamic aliases
>(i.e.
>anonymous points). [Maybe we should get down and define some common
>syntax/wording so we can all understand each other...]
>
>Phil, could you please explain why you don't want to put the point
>definition in the config file?


This discussion rang a bell in my mind.
For sure, we need a way for an IO driver to publish some statuses.
For example:
- comm status (OK, frozen, unconnected, failed, etc)
- error count
- timeout counter
- etc
Should these data points be created by the user in the config file or should they be automatically created by SMM when a driver is attached?
If they are user-defined, how will the driver be informed they are existing?
If they are user-defined, will the names be standardized?

Gilles

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

Mario de Sousa

"DigiMicro (Gilles Allard)" wrote:

> -----Original Message-----
> From: Mario de Sousa <[email protected]>
>
> >Phil wants to place status info in the SMM so other modules may get at
> >it (network error, etc...).
> >(...)
> >Phil, could you please explain why you don't want to put the point
> >definition in the config file?

I've been thinking on this and I think I get your point. No need to explain any longer. Please see below for another alternative.


> This discussion rang a bell in my mind.
> For sure, we need a way for an IO driver to publish some statuses.
> For example:
> - comm status (OK, frozen, unconnected, failed, etc)
> - error count
> - timeout counter
> - etc
> Should these data points be created by the user in the config file or should they be automatically created by SMM when a driver is attached?
>

What I was suggesting is that they be configured by the user in the config file. The module could use a name = value pair, in which the value
would tell the module what point to use for status dissemination. For example:

[SMM]
point P1 ...
...

[module_A]
comm_status_point = P1

If it doesn't find this in the module configuration, then it means that it doesn't need to publish it's status.


The other suggestion you gave, i.e. that the modules create the points on the fly, requires some more thought. This really is included in a
discussion that has been put off (correctly I believe) regarding online changes. I think we should maybe put it off for another month or two.
Right now I would like to tackle the synchronisation issue. (Please see my next post)

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario de Sousa:
> What I was suggesting is that they be configured by the user in the config
> file. The module could use a name = value pair, in which the value would
> tell the module what point to use for status dissemenation. For example:

> [SMM]
> point P1 ...
> ...

> [module_A]
> comm_status_point = P1

> If it doesn't find this in the module configuration, then it means that
> it doesn't need to publish it's status.

I agree with this.

Earlier I made a suggestion about point names generated from the module name, but on reflection I think it was a bad idea.

If we agree on this, we should write a function that will do the lookup, error-handle and just return a point, with little or nothing left to do.
Make it easier for everyone to do.

plc_pt status = plc_pt_cfg_optional("comm_status_point");

The only decision is what to do if comm_status_point exists but has a value that doesn't correspond to a point. Should we return failure or a null pt?

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

Philip Costigan

> plc_pt status = plc_pt_cfg_optional("comm_status_point");
>
> The only decision is what to do if comm_status_point exists but has a value
> that doesn't correspond to a point. Should we return failure or a null pt?
>

I did a quick hack last night and came up with what I think might be what people would expect.

For every single point that drives a real world output or reads a real world input I have appended the text ".err" and then checked to see if it exists in the smm point list. If it is then that point has an error status bit. If it does not exist then a warning is logged.

At this stage I only created one an error status bit but I believe this can be extended to accomodate other forms of point information as well.

eg. Analog input over-range / under range etc. etc.

I hope I haven't jumped the gun too much in this area.

Phil.


P.S. I'm off to Mexico on saturday for a week so I might not get much of a chance to tidy my code up before then. ( Work not holidays ).

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> I did a quick hack last night and came up with what I think might be what
> people would expect.

> For every single point that drives a real world output or reads a real
> world input I have appended the text ".err" and then checked to see if it
> exists in the smm point list. If it is then that point has an error
> status bit. If it does not exist then a warning is logged.

Yup, that'll do the job.

The only slight complaint might be that it's not flexible, but that's more theoretical than practical. For example, it can't handle two outputs reflecting the error status of each other - like I said, theoretical. [1]


If there's general agreement, that'll be the first function to go in the "IO module library". I would create it in the directory lib/io, in line
with the proposed directory reorganization / smm directory breakout.

plc_pt_t io_status_pt(const char *base, const char *suffix, int loglevel);

sample usage:
point_in_error = io_status_pt(tag_name, "err", 3);

Comments?

Jiri
[1]Easily solved by allowing a "mcn1filsol_err=xyzzy" override, if needed.
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

Philip Costigan

> > For every single point that drives a real world output or reads a real
> > world input I have appended the text ".err" and then checked to see if it
> > exists in the smm point list. If it is then that point has an error
> > status bit. If it does not exist then a warning is logged.
>
> Yup, that'll do the job.
>
> If there's general agreement, that'll be the first function to go in the
> "IO module library". I would create it in the directory lib/io, in line
> with the proposed directory reorganization / smm directory breakout.
>
> plc_pt_t io_status_pt(const char *base, const char *suffix, int loglevel);
>
> sample usage:
> point_in_error = io_status_pt(tag_name, "err", 3);
>
> Comments?

That seems OK by me.

Is this going to end up being the inter-module (process) communication method or are we looking at other alternatives as well?

Phil

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

> > > For every single point that drives a real world output or reads a
> > > real world input I have appended the text ".err" and then checked to
> > > see if it exists in the smm point list. If it is then that point has
> > > an error status bit. If it does not exist then a warning is logged.

Jiri Baum:
> > Yup, that'll do the job.

> > If there's general agreement, that'll be the first function to go in
> > the "IO module library". I would create it in the directory lib/io, in
> > line with the proposed directory reorganization / smm directory
> > breakout.

Philip Costigan:
> That seems OK by me.

OK, I've put the declaration there. I'll cut'n'paste the code, too.

> Is this going to end up being the inter-module (process) communication
> method or are we looking at other alternatives as well?

It has the advantage that stepladder (and anything else) can handle it just like any other point.

But we may need something further, later.


Jiri
--
Jiri Baum <[email protected]com.au>
What we do Every Night! Take Over the World!

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