COM - Thoughts for later on

D

Thread Starter

Dan Pierson

Background: Curt has COM on his list of not so good ideas because he's not sure it can be open and free.

In the short term I agree because it would be a distraction and the support isn't quite there.

In the longer term, I'm not so sure. COM is a pretty good solution for very efficent binary modularity. The Mozilla project has adopted it with their own implementation as XPCOM. There's a fairly new project:
http://www.armored.net/gcom/ to provide a portable, open source COM. We may want to keep these in mind for later use.

Dan Pierson

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

Locke, Alan S

Stan Brown Wrote:

> You know, this thing is really starting to come together in my mind. Let me run some
> thoughts by the group. The way I see things we have multiple co-operating tasks. We
> have I/O scanner task(s), logic engine, tasks, timer execution tasks, pid execution
> tasks. motion control execution tasks. etc. These tasks all talk to each other via the
> data tables we have sketched out earlier. The question about where to execute that
> timers really formulated this in my mind. The user would set up the data tables, and all
> the processes would communicate with each other via these. These would be in shared
> memory, and the various tasks would all pass data through them. This ties in very well
> with the thoughts I have previously posted about I/O scanner tasks and logic processor
> tasks. How does this sound?

Yes, this is a very good summarization of how things are shaking out for us.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Fri Jan 14 09:25:58 2000 Mark Bayern wrote...
>
>Stan Brown wrote:
>>
>> You know, this thing is really starting to come together in my mind.
>> Let me run some thoughts by the group.
>>
>> The way I see things we have multiple co-operating tasks. We have I/O
>> scanner task(s), logic engine, tasks, timer execution tasks, pid
>> execution tasks. motion control execution tasks. etc.
>>
>> These tasks all talk to each other via the data tables we have sketched
>> out earlier. The question about where to execute that timers really
>> formulated this in my mind.
>>
>> The user would set up the data tables, and all the processes would
>> communicate with each other via these. These would be in shared memory,
>> and the various tasks would all pass data through them.
>>
>> This ties in very well with the thoughts I have previously posted about
>> I/O scanner tasks and logic processor tasks.
>>
>> How does this sound?
>>
>
>
>Does the phrase 'make it so...' sound too presumptious??
>

Well then, may I humbly suggest that we start coding the routines to access this shared memory data table? They are required for any of the actual modules, IE logic engine(s), I/O scanner(s). The perhaps the timer execution code could be done next, as an example, since it should
be relatively simple. Please note that I said relatively simple, not trivial, it has issues of it's own. For example, how to process
multiple (many) timer functions at once. Any bright ideas on this?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.


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

Curt Wuollet

Hi Stan and all.

I'm simply amazed, but, you are right at what I have in mind, I was a little worried for a while as the discussion wandered far afield. Let me put what I am actually doing in perspective. My modbus/TCP scanner will be an I/O task that writes to the shared memory page. This could run asynchronously with a simple "in use" flag to prevent reads or writes during a scan. For the sake of determinisn and predictable behaviour, we may want two way sync though, to preserve the read
solve write sequence. This I/O table can be used directly or with a second table for the solver to read for abstraction and the features folks have been talking about. They can reside in the same place and update and ops between them would just involve pointers (very fast). This is a subsystem. On the "other side" of this
interface would lie the solver and other "users" of the data. I wanted to scream "YES!" , but restrained myself, when I saw your post. The one question I have though, is: If we use two pages, which "side" handles the updates and ops between them. I would say the solver, because some of them will be programmable. We may need a "master" I/O program to fire all the I/O scanners in sequence.

Regsrds

Curt W.


Stan Brown wrote:

> On Fri Jan 14 09:25:58 2000 Mark Bayern wrote...
> >
> >Stan Brown wrote:
> >>
> >> You know, this thing is really starting to come together in my mind.
> >> Let me run some thoughts by the group.
> >>
> >> The way I see things we have multiple co-operating tasks. We have I/O
> >>scanner task(s), logic engine, tasks, timer execution tasks, pid
> >> execution tasks. motion control execution tasks. etc. ...<clip>
>
> Well then, may I humbly suggest that we start coding the routines to access this shared memory data table? They are required for any of the actual modules, IE logic engine(s), I/O scanner(s). ...<clip>

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

> The logic engines will also make a copy of the output states, before
> beginning their scan. They will then see the output states during the
> scan dynamicly as they are modified (this is required for things like 3
> wire seal ins to work properly). At the end of the logic processor
> scan, they will then take the resultant set of outputs, lock the output
> image table, and update them. The I/O scanner(s) can then update the
> real I/O as a part of their scan.
>

Only if the logic process(singular in this case) has exclusive control
of the output. If not we'll have to lock the output when its read
_before_ starting the logic scan.

Mark

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Fri Jan 14 13:11:22 2000 Mark Bayern wrote...
>
>Stan Brown wrote:
>
>> The logic engines will also make a copy of the output states, before
>> beginning their scan. They will then see the output states during the
>> scan dynamicly as they are modified (this is required for things like 3
>> wire seal ins to work properly). At the end of the logic processor
>> scan, they will then take the resultant set of outputs, lock the output
>> image table, and update them. The I/O scanner(s) can then update the
>> real I/O as a part of their scan.
>
>Only if the logic process(singular in this case) has exclusive control
>of the output. If not we'll have to lock the output when its read
>_before_ starting the logic scan.

I thought we had gone down that road. It is my strongly held opinion, that real outputs _must_ be locked to a single logic engine for the
purpose of setting, now if another logic engine wants to acquire the status in a read only fashion, that will be OK.

I suppose this does raise the question of whether the logic engines need to make a local copy of non I/O data table for consistency reasons.

Opinions?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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

> I thought we had gone down that road. It is my strongly held opinion, that real outputs _must_ be locked to a single logic engine for the
purpose of setting, now if another logic engine wants to acquire the status in a read only fashion, that will be OK. <

I know we've started down that road, didn't know it had been settled. But clearly we both agree.

> I suppose this does raise the question of whether the logic engines need to make a local copy of non I/O data table for consistency reasons. <

Guess it depends on where the data is comming from and if the application programmer expects the data to remain constant for a 'scan'. I haven't given any thought to control processes that don't implement 'scans' yet.

Mark

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Fri Jan 14 15:05:05 2000 Mark Bayern wrote...
>
>Stan Brown wrote:
>>
>> I thought we had gone down that road. It is my strongly held opinion,
>> that real outputs _must_ be locked to a single logic engine for the
>> purpose of setting, now if another logic engine wants to acquire the
>> status in a read only fashion, that will be OK.
>
>I know we've started down that road, didn't know it had been settled. But clearly we both agree. <

Maybe it's not settled?

>> I suppose this does raise the question of whether the logic engines need
>> to make a local copy of non I/O data table for consistency reasons. <<
>
>Guess it depends on where the data is comming from and if the
>application programmer expects the data to remain constant for a
>'scan'. I haven't given any thought to control processes that don't implement 'scans' yet.

I am still struggling with that concept. In the end everything is a Von Numen (sp) machine, so how can it not be?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, Jan 14, 2000 at 03:40:19PM -0500, Stan Brown wrote:
> On Fri Jan 14 15:05:05 2000 Mark Bayern wrote...
> >
> >Guess it depends on where the data is comming from and if the
> >application programmer expects the data to remain constant for a
> >'scan'. I haven't given any thought to control processes that don't
> >implement 'scans' yet.
>
> I am still struggling with that concept. In the end everything is a Von
> Numen (sp) machine, so how can it not be?

One example of a non-scanning machine might be a purely event-driven one. I usually prefer to run a scan in the application programming in that sort of environment anyway, but in some situations it might be sufficient to ably handle events.

Having multiple agents/engines writing outputs would certainly be tough in an event-driven environment, though maybe not intractable if any
change to the output signaled an event to the engine.

--
Ken Irving
Trident Software
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]nuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri Jan 14 20:00:48 2000 Curt Wuollet wrote...
>
>Hi Stan and all.
>
>I'm simply amazed, but, you are right at what I have in mind, I was a little
>worried
>for a while as the discussion wandered far afield. Let me put what I am actually
>doing in perspective. My modbus/TCP scanner will be an I/O task that writes to
>the shared memory page. This could run asynchronously with a simple "in use"
>flag to prevent reads or writes during a scan. For the sake of determinisn and
>predictable behaviour, we may want two way sync though, to preserve the read
>solve write sequence. This I/O table can be used directly or with a second table
>for the solver to read for abstraction and the features folks have been talking
>about.
>They can reside in the same place and update and ops between them would just
>involve pointers (very fast). This is a subsystem. On the "other side" of this
>interface would lie the solver and other "users" of the data. I wanted to scream
>"YES!" , but restrained myself, when I saw your post. The one question I have
>though, is: If we use two pages, which "side" handles the updates and ops
>between them. I would say the solver, because some of them will be programmable.
>We may need a "master" I/O program to fire all the I/O scanners in sequence.

Well, we are indeed close here. Let me put in a bit more detail.

As I see it there will need to be some configuration file(s) that will map physical I/O to I/O data table locations. Given this the I/O
scanner(s) can (for the first pass anyway) free run. If they need to lock the shared memory then they can (using a semaphore ?). But this locking should be for as short a time as possible.

The I/O scanner(s) will need to check the output states as set by the logic engines vs the force table states, and pass the states as overridden if necessary to the real outputs.

The logic engine(s) will be responsible for checking the inputs as provided by the I/O scanner against the current state of the input
force table, and making their own copy to use. This will allow for a consistent view of the inputs during a logic processor scan.

The logic engines will also make a copy of the output states, before beginning their scan. They will then see the output states during the scan dynamicly as they are modified (this is required for things like 3 wire seal ins to work properly). At the end of the logic processor
scan, they will then take the resultant set of outputs, lock the output image table, and update them. The I/O scanner(s) can then update the
real I/O as a part of their scan.

Sound right?


--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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