I still like the concept of keeping force data in the IO table. A monitor process simply has to modify the force bit in the IO table, which at scan time the "kernel" will mask with the actual Program value of the IO and the result is presented to the Hardware Drivers. When a monitor routine gets written, it simply will modify the force locations, thereby preventing contention with the logic writing to the IO table.

I don't think that modifying the config file in order to input force data is valid, because it needs to occur at run time. Is this True??

I think forcing all data values is essential. From Jiri's description, all IOs are treated equally (Internal as well as external) so there shouldn't be a problem forcing internals.

~Ken

>>> Philip Costigan <[email protected]> 11/02 6:32 AM >>>
On Thu, 02 Nov 2000, Jiri Baum wrote:

> > It is interesting to note that they include "Force" data in the
table so
> > that they can quickly mask tags to see if there is a force
condition
> > applied by the debugging program.
>
> There are no forces at present. They could be implemented
relatively simply
> by taking away "write" rights to a point. (Hmm, this makes them
part of the
> online-change monster.)
>
> (What are the correct semantics for forces? The above would apply
the
> forces at I/O scan time; (re)setting a forced point would change
its value
> for the rest of the scan for that module, then it would revert.)

Some PLC's only allow forcing on external I/O and others allow forcing on everything. If we choose to only allow forcing on external I/O then
we can use the recently added function io_status_pt() and modify it to be somthing like

io_parameter_pt( const char *base, const char *suffix, int
loglevel);

and this point can drive io points, digital or analog.

eg. io_parameter_pt( tag, "force_val", 4 );
io_parameter_pt( tag, "force_en", 4 );

The linuxplc.conf would look something like

point mcn1filsol "machine 1 fill solenoid"
some_module at 0.0
point mcn1filsol.force_val "force bit for solenoid"
forcing_module at 0.1
point mcn1filsol.force_en "enable force on this bit"
forcing_module at 0.2

It could be then also used for seting up analog card's ranges from
module
control instead of hard coded (for some devices anyhow).

eg.

point vat1temp "vat 1 temperature" io_module at 47
point vat1temp.setup "0=4-20mA 1=0-10V" setup_module at
48.0 3

I can't, at this stage, see that forcing everything will be
acheivable too soon
but what I propose here may be achievable for version 0.1 or 0.2.

Let me know your thoughts.
--
Regards

Philip Costigan


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

 

Ken Emmons, Jr.:
> I still like the concept of keeping force data in the IO table. A monitor
> process simply has to modify the force bit in the IO table, which at scan
> time the "kernel" will mask with the actual Program value of the IO and
> the result is presented to the HArdware Drivers. When a monitor routine
> gets written, it simply will modify the force locations, thereby
> preventing contention with the logic writing to the IO table.

My current working concept for forces would be to temporarily reassign ownership of the point in question to the monitor module. Once that
happens, the monitor module no longer needs anything special for the force; it is the owner and therefore has write rights to the point.

This applies forces at the globalmap level. The original owner can (and probably will) scribble over the private value. Other modules will never
get to see it, but it can be a subtlety within that module (if the point is used in further logic or calculations after being changed).

However, that's just a concept; what eventually gets implemented may well be completely different.

> I don't think that modifying the config file in order to input force data
> is valid, because it needs to occur at run time. Is this True??

Yes.

> I think forcing all data values is essential. From Jiri's description,
> all IOs are treated equally (Internal as well as external) so there
> shouldn't be a problem forcing internals.

Yup.


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