C
Hi all
Jiri Baum wrote:
>
> Jiri:
> > > We don't at this stage have any logging modules. (Which, now that you
> > > mention it, is a serious omission...)
>
> Juan:
> > In fact I was thinking some time ago of adding a tendency graph to the
> > hmi_gtk module but I had no source to feed the information.
>
> Graphing should probably be a separate module still... unless you take the
> log, massage it lightly and send it to gnuplot (which would have its
> advantages).
That would be the Linux/OSS wey. Actually, a separate module that uses Gnuplot would be good as one could substitute other available
visualization packages complete with the data messager for their format.
> > Just to start with something: (Please understand that I am in a hurry and
> > I just want to show the idea, the format is not rigorous for now).
>
> > [data_logger]
> > File filename1 period [n] # Se explanation below for n
> > File filename2 period [n]
>
> I was actually thinking of a really simple one that just logs to one file.
> You can always run two copies if you need more than one.
>
> > filename point [ScaleFactor] point [ScaleFactor] ...
>
> > filename2 point [ScaleFactor] point [ScaleFactor] ...
>
> Better make it a table:
>
> log <point1> [as <type>]
> log <point2> [scaled <factor>] [as <type>]
>
> > Or as a table first line column descriptions and then each line has the
> > values ordered by columns first column the time and date and the next
> > columns each point value.
>
> Yup.
>
> > I sometimes think that a log that only contains the last n values is
> > usefull because the file does not grow indefinetly,
>
> Yes, but it has implementation difficulties... An easier alternative is to
> put the dow or date into the filename, or else the usual linux thing with
> yesterday's log being log-0, day before's log-1.gz etc up to some
> configurable maximum.
>
> Again, the simple/first version of the module might not have that.
>
> > And if you start thinking in this direction, we may also add an alarm
> > module this will save an alarm to a log file when a condition is true.
>
> Actually, there are quite a few other things that can be done with
> alarms... we might want to be comprehensive about them.
The essential thing is that we put enough thought into how we organize data that we can maintain compatibility when we add new tables and relations. We can keep it open for dev releases, but once someone writes external software to it we have to be prepared to freeze it and extend it only with another relational table keyed to it. I see different roles for flat files and database data. It would be good to be able to simply use flat files for apps that need only transient displays and use a database for apps where
historical data will be important. A one shift trend isn't worth running a database but SPC ERP and CAM will want a geteway to a db service. So, the basic log table should deal with what we can
do with either a flat file or a db and more esoteric stuff can be relational because at that point we would be using a db and can do joins to obtain extended vfirtual records.
Does any of that make sense? I'm on my first cup of coffee.
Regards
cww
> _______________________________________________
> MAT-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mat-devel
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc
Jiri Baum wrote:
>
> Jiri:
> > > We don't at this stage have any logging modules. (Which, now that you
> > > mention it, is a serious omission...)
>
> Juan:
> > In fact I was thinking some time ago of adding a tendency graph to the
> > hmi_gtk module but I had no source to feed the information.
>
> Graphing should probably be a separate module still... unless you take the
> log, massage it lightly and send it to gnuplot (which would have its
> advantages).
That would be the Linux/OSS wey. Actually, a separate module that uses Gnuplot would be good as one could substitute other available
visualization packages complete with the data messager for their format.
> > Just to start with something: (Please understand that I am in a hurry and
> > I just want to show the idea, the format is not rigorous for now).
>
> > [data_logger]
> > File filename1 period [n] # Se explanation below for n
> > File filename2 period [n]
>
> I was actually thinking of a really simple one that just logs to one file.
> You can always run two copies if you need more than one.
>
> > filename point [ScaleFactor] point [ScaleFactor] ...
>
> > filename2 point [ScaleFactor] point [ScaleFactor] ...
>
> Better make it a table:
>
> log <point1> [as <type>]
> log <point2> [scaled <factor>] [as <type>]
>
> > Or as a table first line column descriptions and then each line has the
> > values ordered by columns first column the time and date and the next
> > columns each point value.
>
> Yup.
>
> > I sometimes think that a log that only contains the last n values is
> > usefull because the file does not grow indefinetly,
>
> Yes, but it has implementation difficulties... An easier alternative is to
> put the dow or date into the filename, or else the usual linux thing with
> yesterday's log being log-0, day before's log-1.gz etc up to some
> configurable maximum.
>
> Again, the simple/first version of the module might not have that.
>
> > And if you start thinking in this direction, we may also add an alarm
> > module this will save an alarm to a log file when a condition is true.
>
> Actually, there are quite a few other things that can be done with
> alarms... we might want to be comprehensive about them.
The essential thing is that we put enough thought into how we organize data that we can maintain compatibility when we add new tables and relations. We can keep it open for dev releases, but once someone writes external software to it we have to be prepared to freeze it and extend it only with another relational table keyed to it. I see different roles for flat files and database data. It would be good to be able to simply use flat files for apps that need only transient displays and use a database for apps where
historical data will be important. A one shift trend isn't worth running a database but SPC ERP and CAM will want a geteway to a db service. So, the basic log table should deal with what we can
do with either a flat file or a db and more esoteric stuff can be relational because at that point we would be using a db and can do joins to obtain extended vfirtual records.
Does any of that make sense? I'm on my first cup of coffee.
Regards
cww
> _______________________________________________
> MAT-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mat-devel
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc
