What now? (was: plc5 status ? >> and more)

M

Thread Starter

Mario de Sousa

Hugh Jack wrote:
>
> Hi,
>
> Please give me some time to look over the docs and source code - a
> couple of days would work. In the mean time you can have a look at my
> specs at;
>
> http://claymore.engineer.gvsu.edu/lpcd/lpc.0.0.7.4/docs/io_spec.doc
>
> The basic architecture is a central process loader that loads modules as
> dynamically linked libraries. Each library is linked to a common set of
> routines that handle execution. They can exchange data and messages
> through the loader. The loader is very lightweight. This is by design so
> that it can be replaced easily to switch between pthreads, rtlinux, or
> roll your own OS.
>

Hi Hugh,

I seem to remember we started discussing this privately, but I started concentrating on other details and never really got back to you. Sorry
Hugh!

I think Hugh's modules and our own are similar, but different in that our modules include a main() function and only use the library to
interface to the common data. Hugh's modules are library functions that get called by the main program (the loader - it actually creates a
pthread for each). Without really thinking too much on the subject, what I sugest is to:
- write a generalised linuxplc wrapper module (with a main function) that loads a PPLC module and implements the functions provided by Hugh's
loader.

We could then run any PPLC module as a linuxplc module.

I'll have to take some time out to look into it more thoroughly though.

I would like to press on with the effort of producing a binary release, but I think this merging of efforts is also important. What should we concentrate on now?

-------------

Things left to do until a binary release:
- finish the oven demo
Juan is working on this...

- add a few features to the dsp to support the oven demo
I am working on this. It shouldn't take too long.

- get the tcl code to compile.

This should take 5 minutes for somebody who knows how to configure autoconf. We merely need to link the current code with the librt library (i.e. add -lrt to the linker)

- get the modbus code to compile

This should take 10 minutes using the quick hack of inserting the missing function (now in the io library) directly into the modbus code.

- create demos for the dio and modbus modules.

- create the binaries for release...

Jiri, do you think you could add a top-level Makefile so we can do a '$make dist' whenever we want to make a release. This would do a '$make dist-compile' followed by a 'make dist-clean' that would delete all the intermediate .o files, and finished by a '$make dist-tarball' that would make the tarball file whose name would include the release version. This would make further relaeses much easier.

Cheers,

Mario.

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

The box said it requires Windows 95 or better, so I installed Linux

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

Mario de Sousa

Mario de Sousa wrote:
>
> Things left to do until a binary release:
> - finish the oven demo
> Juan is working on this...
>
> - add a few features to the dsp to support the oven demo
> I am working on this. It shouldn't take too long.
>
> - get the tcl code to compile.
> This should take 5 minutes for somebody who knows how to configure
> autoconf. We merely need to link the current code with the librt library
> (i.e. add -lrt to the linker)
>
> - get the modbus code to compile
> This should take 10 minutes using the quick hack of inserting the
> missing function (now in the io library) directly into the modbus code.
>
> - create demos for the dio and modbus modules.
>
> - create the binaries for release...
> Jiri, do you think you could add a top-level Makefile so we can do a
> '$make dist' whenever we want to make a release. This would do a '$make
> dist-compile' followed by a 'make dist-clean' that would delete all the
> intermediate .o files, and finished by a '$make dist-tarball' that would
> make the tarball file whose name would include the release version. This
> would make further relaeses much easier.
>

Yes Jiri, I know you want to get rid of the scripts launching the demos. You sugested using a global quit point for that. I have been
thinking about this, and came to the conclusion it would be better to have a quit synch_pt instead of a quit pt.

- A simple pt would have to be polled. We could sleep on a synch_pt.

I was thinking of implementing a first quick hack for a state library. This library would create two transitions (and associated synch_pt's)
and a single place upon plc_setup().

Althought the following would not be placed in the config file, just to explain it better the following is a config file that would generate the
equivalent of what plc_setup() would create automatically.

transition quit
transition await_quit
place quit_request

arc quit -> quit_request
arc quit_request -> await_quit

The linuxplc command line program could then launch all the modules and then synch(await_quit). Followed by killing off all the processes it first launched.

The kbd modules would simple synch(quit) instead of plc_set(quit, 1). If you prefer, we could have a plc_quit_request() or simply plc_quit()
function, instead of calling synch(quit). We would then probably be better protected against future changes to the state library.


This is just a quick hack to get the binary release out the door. We could then augment this to fully support on-line configuration changes,
and the like.

Comments, sugestions?

Cheers,

Mario.


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

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario:
> Yes Jiri, I know you want to get rid of the scripts launching the demos.

Actually, I feel this is a lot less urgent since I've written the -u option on plctest the other day... (which let me reduce the CPU usage to something sensible)

Still, the modules should be launched by the equivalent of "smm-mgr -l", and there's got to be a way to kill them all before that can happen (the
current perl script keeps a list of PIDs).

(Hmm, maybe the launcher should also check that all the modules exist; maybe even offer to run "make" if they don't. Maybe not - I don't know. Which probably means it should be a command-line option.)

BTW, once we have the linuxplc utility, we can use #! syntax in the linuxplc.conf files.

> You sugested using a global quit point for that. I have been thinking
> about this, and came to the conclusion it would be better to have a quit
> synch_pt instead of a quit pt.
...
> The linuxplc command line program could then launch all the modules and
> then synch(await_quit). Followed by killing off all the processes it
> first launched.

Sounds good.

> The kbd modules would simple synch(quit) instead of plc_set(quit, 1).

The kbd modules are generic I/O modules, so the synch(quit) should go in the logic (chaser.c, chaser.il).

For the others, it's easy enough to write a little quit poller module that watches a point and when it comes true, initiates the shutdown.

> If you prefer, we could have a plc_quit_request() or simply plc_quit()
> function, instead of calling synch(quit). We would then probably be
> better protected against future changes to the state library.

More importantly, against changes in the plc shutdown library.

Not sure if it should be called plc_quit(), plc_abort() or plc_shutdown(). Probably doesn't matter - whichever you prefer.

> This is just a quick hack to get the binary release out the door. We
> could then augment this to fully support on-line configuration changes,
> and the like.

Actually, it doesn't sound that bad.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

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

Mario de Sousa

Jiri Baum wrote:
>
> Mario:
> > Yes Jiri, I know you want to get rid of the scripts launching the demos.
>
> Actually, I feel this is a lot less urgent since I've written the -u option
> on plctest the other day... (which let me reduce the CPU usage to something
> sensible)

Sorry, but what does the plctest -u option have to do with doing away with the perl scripts?

> Still, the modules should be launched by the equivalent of "smm-mgr -l",
> and there's got to be a way to kill them all before that can happen (the
> current perl script keeps a list of PIDs).

Yes. I was thinking of having the state library keep the pid of runing modules in the cmm. The functions to launch and shutdown a module would
move from the linuxplc code to the state library. The linuxplc code would simply call these functions.

This way we could have the linuxplc utility launch all the modules, and the user later launch a few more with the smm-mgr -l utility. A
plc_shutdown_all_modules() would kill off all modules. A plc_shutdown_module(char *module) would only kill the named module.

> (Hmm, maybe the launcher should also check that all the modules exist;
> maybe even offer to run "make" if they don't. Maybe not - I don't know.
> Which probably means it should be a command-line option.)

This would come in handy for IL modules! I think we should leave this for later...

> BTW, once we have the linuxplc utility, we can use #! syntax in the
> linuxplc.conf files.

Sorry, you lost me here...

> > You sugested using a global quit point for that. I have been thinking
> > about this, and came to the conclusion it would be better to have a quit
> > synch_pt instead of a quit pt.
> ...
> > The linuxplc command line program could then launch all the modules and
> > then synch(await_quit). Followed by killing off all the processes it
> > first launched.
>
> Sounds good.
>
> > The kbd modules would simple synch(quit) instead of plc_set(quit, 1).
>
> The kbd modules are generic I/O modules, so the synch(quit) should go in
> the logic (chaser.c, chaser.il).
>

No. You missed the point. The kbd module is the one that checks that the Q key was pressed, and therefore it is this module that requests the
shutdown by synching on the synch_pt. The other modules will get killed off by the linuxplc command when it returns from the synch(await_quit)
call.

Cheers,

Mario.

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

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> > Mario:
> > > Yes Jiri, I know you want to get rid of the scripts launching the
> > > demos.

Jiri:
> > Actually, I feel this is a lot less urgent since I've written the -u
> > option on plctest the other day... (which let me reduce the CPU usage
> > to something sensible)

Mario:
> Sorry, but what does the plctest -u option have to do with doing away
> with the perl scripts?

It let me fix the CPU-hogging thing. Previously the script would keep running plctest -g over and over and over.

> > Still, the modules should be launched by the equivalent of "smm-mgr
> > -l", and there's got to be a way to kill them all before that can
> > happen (the current perl script keeps a list of PIDs).

> Yes. I was thinking of having the state library keep the pid of runing
> modules in the cmm. The functions to launch and shutdown a module would
> move from the linuxplc code to the state library. The linuxplc code would
> simply call these functions.

Sounds good.

> > (Hmm, maybe the launcher should also check that all the modules exist;
> > maybe even offer to run "make" if they don't. Maybe not - I don't know.
> > Which probably means it should be a command-line option.)

> This would come in handy for IL modules! I think we should leave this for
> later...

Easy enough to put it in, it's just a couple of string manipulations and a system(3)...

> > BTW, once we have the linuxplc utility, we can use #! syntax in the
> > linuxplc.conf files.

> Sorry, you lost me here...

Once you have a linuxplc command like this:
linuxplc l.conf

you can also have l.conf executable and put on the first line:
#!/usr/local/bin/linuxplc

> > > The kbd modules would simple synch(quit) instead of plc_set(quit, 1).

> > The kbd modules are generic I/O modules, so the synch(quit) should go
> > in the logic (chaser.c, chaser.il).

> No. You missed the point. The kbd module is the one that checks that the
> Q key was pressed, and therefore it is this module that requests the
> shutdown by synching on the synch_pt.

On the other hand, any of the I/O modules can take the place of kbd; I don't think quit-checking logic should be put into all of them, especially since in any real application the quit logic will be more complicated than that (making sure the machine is in a safe state).

> The other modules will get killed off by the linuxplc command when it
> returns from the synch(await_quit) call.

Yes.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

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

Mario de Sousa

Hi Juan,

I have just commited a new mult(iplying) block for the dsp.

We can now multiply two or more plc points.


I have updated the oven demo to use this new block and the initialising of points from the linuxplc.conf file. The constants.c file is now no
longer required. (Jiri, I still haven't quite figured out how to work with the new cvs. Could you please remove the /demo/oven/constants.c
file?)

I will later write a div(ision) and a switch blocks to completely eliminate the extramath.c file now in the oven demo.

Cheers,

Mario.

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

The box said it requires Windows 95 or better, so I installed Linux

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