C
I have been looking to tcl/tk to produce "fill in the blanks" config tools mostly for the reason that it's the expected ease of use standard in
the industry, and we _have_ to circumvent "the Linux has no gui" fud. We will, of course, produce editable files for those who would rather
simply import or heads down key hundreds of points rather than wimp their way through an afternoon. I'm sure Glade or some other gui
builder could be used to produce these config screens also. Since we will have highly diverse and idiosyncratic IO connected, a set could consist of a driver, config screen script, and an IO proc that will link in to add the IO to the scan loop and map. Tcl/tk has the advantage
that a lot of the code would be reused from screen to screen making adding an IO type a task that more people could handle. Part of my job as team leader is to keep things supportable through normal attrition and use tools that most people can understand. I would like the win/win that we support traditional UNIX text config files and
still provide easy "fill in the blanks" mistake proof configuration for the command line challenged. The typical documentation last or never attitude of developers is somewhat mitigated in this fashion. The commonalities between say, configuring a DIO card and intelligent Ethernet IO are practically nil. This makes a "universal" setup scheme quite difficult to realize. I lean strongly towards modular dedicated configuration tools that match the features of the device and don't require rebuilding any common code when adding a new device type. This means of course a defined API to the SMM and an IO scheduler API that handles IO in a consistant high level manner. We config the IO, register the particular IO proc with the IO scheduler on init and go.
The config files would then have common sections mapping the IO and switches of the type being discussed, start up state, persistance, etc. anything that we support across all IO. They
would also require a section with any specific details for the IO device, eg IRQ, DMA chan, hardware MAC address, baud rate, phase of the moon, magic incantations, etc, that it takes to actually get the thing to work.
I would greatly prefer that these _not_ be stanzas in a huge common config file as debugging would be a nightmare and an errant config could whack the parser and stop everything. I would rather have a menu of config screens in keeping with the incremental development and fluid nature of a project such as this.
I have not communicated this previously as we are not dealing with this area yet. I bring it out now not to provoke a flurry of discussion when nobody's writing the code for it but, to illustrate my reasons for reluctance to jump into XML or other universal schemes at this point. In effect to say: "tho' this be madness yet there is method to it". I am not simply rejecting things out of hand. I have a plan and when we get to discussing the plan at coding time, I'm sure XML will resurface and, if it makes sense be adopted.
This is slightly dictatorial at this point. but only because mine is the only plan I've seen pending that discussion. This is of course, open for discussion, but that would be more fruitful when we are close to writing the code. We have a problem with focus here, but a reasonable amount of anarchy is a good thing.
Regards
cww
jackh wrote:
> Hi,
>
> Before using XML I was just hacking together a file format by hand. It
> started to get ugly when I added the configuration for the IO scanner.
> The IO devices are much more varied between device.
>
> The XML structure did force some integrity. In particular you can
> develop a document definition format (Document Type Definition - DTD)
> that includes argument types, hierarchy, allowed repititions, etc. With
> XML you can parse it with software that will check the document for
> basic layout and syntax (non-validating), or you can do full document
> checking that verifies content also (validating). On the FreeLC (the
> PLC) I have written my own parser that does the final validation, but on
> the programming software and other client programs a validating parser
> makes a lot of sense, and will add another layer of defense against user
> program bugs. This format also means that if you want to construct PLC
> files by hand you can use an XML editor, and be more sure that it is
> correct.
>
> Hugh
>
> |
> |
> |Is any data integrity brought to the table
Snip (for brevity)
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
the industry, and we _have_ to circumvent "the Linux has no gui" fud. We will, of course, produce editable files for those who would rather
simply import or heads down key hundreds of points rather than wimp their way through an afternoon. I'm sure Glade or some other gui
builder could be used to produce these config screens also. Since we will have highly diverse and idiosyncratic IO connected, a set could consist of a driver, config screen script, and an IO proc that will link in to add the IO to the scan loop and map. Tcl/tk has the advantage
that a lot of the code would be reused from screen to screen making adding an IO type a task that more people could handle. Part of my job as team leader is to keep things supportable through normal attrition and use tools that most people can understand. I would like the win/win that we support traditional UNIX text config files and
still provide easy "fill in the blanks" mistake proof configuration for the command line challenged. The typical documentation last or never attitude of developers is somewhat mitigated in this fashion. The commonalities between say, configuring a DIO card and intelligent Ethernet IO are practically nil. This makes a "universal" setup scheme quite difficult to realize. I lean strongly towards modular dedicated configuration tools that match the features of the device and don't require rebuilding any common code when adding a new device type. This means of course a defined API to the SMM and an IO scheduler API that handles IO in a consistant high level manner. We config the IO, register the particular IO proc with the IO scheduler on init and go.
The config files would then have common sections mapping the IO and switches of the type being discussed, start up state, persistance, etc. anything that we support across all IO. They
would also require a section with any specific details for the IO device, eg IRQ, DMA chan, hardware MAC address, baud rate, phase of the moon, magic incantations, etc, that it takes to actually get the thing to work.
I would greatly prefer that these _not_ be stanzas in a huge common config file as debugging would be a nightmare and an errant config could whack the parser and stop everything. I would rather have a menu of config screens in keeping with the incremental development and fluid nature of a project such as this.
I have not communicated this previously as we are not dealing with this area yet. I bring it out now not to provoke a flurry of discussion when nobody's writing the code for it but, to illustrate my reasons for reluctance to jump into XML or other universal schemes at this point. In effect to say: "tho' this be madness yet there is method to it". I am not simply rejecting things out of hand. I have a plan and when we get to discussing the plan at coding time, I'm sure XML will resurface and, if it makes sense be adopted.
This is slightly dictatorial at this point. but only because mine is the only plan I've seen pending that discussion. This is of course, open for discussion, but that would be more fruitful when we are close to writing the code. We have a problem with focus here, but a reasonable amount of anarchy is a good thing.
Regards
cww
jackh wrote:
> Hi,
>
> Before using XML I was just hacking together a file format by hand. It
> started to get ugly when I added the configuration for the IO scanner.
> The IO devices are much more varied between device.
>
> The XML structure did force some integrity. In particular you can
> develop a document definition format (Document Type Definition - DTD)
> that includes argument types, hierarchy, allowed repititions, etc. With
> XML you can parse it with software that will check the document for
> basic layout and syntax (non-validating), or you can do full document
> checking that verifies content also (validating). On the FreeLC (the
> PLC) I have written my own parser that does the final validation, but on
> the programming software and other client programs a validating parser
> makes a lot of sense, and will add another layer of defense against user
> program bugs. This format also means that if you want to construct PLC
> files by hand you can use an XML editor, and be more sure that it is
> correct.
>
> Hugh
>
> |
> |
> |Is any data integrity brought to the table
Snip (for brevity)
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc