state library (was: Getting ready for the first release!)

J

Thread Starter

Jiri Baum

Mario:
> This library can have a global variable in the cmm for the global state
> of the plc (stop, run, going_down, coming_up, ...?). Each of the modules
> would also have an independent state variable (run, stop, update, ....).

> We can then have a command line utility to change the state of these
> variables, and every module would then respect their state.

This would have to be changeable programmatically, too.

> I would start off with five states for the PLC:
...

Are these states or requests for change? Who sets these values and who reads them? Serialization?

> Modules could have three states:

Again, are these states (set by the module) or requests for change (set by something else)? If requests, how do they get acknowledged? Serialization?


Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001

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

Mario de Sousa

Jiri Baum wrote:
>
> Mario:
> > This library can have a global variable in the cmm for the global state
> > of the plc (stop, run, going_down, coming_up, ...?). Each of the modules
> > would also have an independent state variable (run, stop, update, ....).
>
> > We can then have a command line utility to change the state of these
> > variables, and every module would then respect their state.
>
> This would have to be changeable programmatically, too.

Yes, sure.

> > I would start off with five states for the PLC:
> ...
>
> Are these states or requests for change? Who sets these values and who
> reads them? Serialization?

They are all states, but I guess you could consider some of them as requests for change, i.e. they are transient states.

Setting the values: open to discussion. At the moment I was considering any module could, besides the user using command-line utilities.
Changing the values would be done by specific library functions.

Reading the values: The state library would use the the plc_scan_beg/end() function calls into the plc library to verify if the module should
continue the scan, or if it should simply stop. he problem here are the modules that do not run in a loop, and therefore do not call these functions...

Serialization: We will probably have to use semaphores, either one per state, or a semaphore state protected variable. This would be enough
to assure consistency?

> > Modules could have three states:
>
> Again, are these states (set by the module) or requests for change (set by
> something else)? If requests, how do they get acknowledged? Serialization?
>

states vs requests for change: see previous answer.

acknowledgement: after calling the function requesting the change, call a blocking or nonblocking functions confirming the change.

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

Jiri Baum wrote:
>
> Jiri:
> > > 11 - finish lib/util/puffinplc.c so that it can wait for a quit point,
> > > and then eliminate the demo/*/demo perl scripts. They were quick and
> > > dirty hacks to begin with and should die (I can say that, I wrote
> > > them).
>
> Mario:
> > > Jiri, I would like to do this properly from the start. We need to
> > > think about this before we go charging ahead.
>
> Mario:
> > What I meant above is that I don't like the idea of using a user-space
> > plc_point to control the current state of the plc.
>
> The other side of the coin is creating a completely new interface that will
> need to duplicate much of the functionality of the existing interface...
> We'll then have to add this interface into all the programming languages we
> support, so that stepladder can stop the PLC etc.

Yes, you have a good point here. Let me think about this a little more...

>
> > I have been thinking a couple of minutes about this and at the moment
> > what seems most clean to me would be to create a 'state' library used to
> > control the state of the plc.
>
> Personally, for the first release, I'd just put in the quit point; it won't
> be that big a problem to make a backwards-compatibility function once the
> library is written (if it will even be needed) - just wait for the point
> then call the state library.
>

OK. Agreed. I'm not too sure about the backwards compatibility though. It will depend on the previous point. (Last night was a difficult night. I'm sleeping on my feet. Pls bare with me).

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