C
Hi Louis and all
I've been trying to get some concensus on this for a while now. We don't even need a full PLC for now, just representative IO and the thing that sequences it (dodging terminology problems)
loading the map. This will allow us to answer most of the speed questions and come up with an approach that will work. The time to scan X points is our major constraint. This will allow us to define our method for driving IO and define map structure and location. If we use the map as our dividing line and get that much done, we can get many more people working. The problem is
that much of the discussion is about things that go on the IO side. I suggest we decide on the minimum feature set the drivers will have to support:
For Example
status request.
Read all inputs to map.
Write all mapped outputs.
Read dig. inputs to map.
Read analog inputs to map.
Write mapped dig. outputs.
Write mapped analog outputs.
Not all forms of IO would have these:
ioctls for setup.
ioctls for features, (en)(dis)able latch, (en)(dis)able counter, resets, etc.
status/error register(s) in map
All drivers will present data in the same format in an assigned
location, maybe fixed map for now.
etc. etc.
I see the thing that sequences it as doing something like this:
input_map_valid_flag(0);
lock_map(); /* or semaphore++ */
for( entity = 0 ; entity < num_devices ; entity++)
{
standard_read_all_call( entity );
}
spin_on_status_until_all_reads_complete(); /* or sleep */
input_map_valid_flag(1);
unlock_map(); /* or semaphore-- */
and much the same on writes. Please don't attack the semantics of my
"C-docode" I think in C.
If we could get just this much really working it would show us a lot about what we are going to have to do to get scan times in line and many other questions we talk about. And people could start on test drivers for their favorite IO.
Well, we'd also need a map display.
The most critical information in the least time to enable the most work to start or continue.
Curt Wuollet,
Wide Open Technologies.
LouisKriek wrote:
>
> So is it time to decide on some - - very limited - - specifications for the
> first LinuxPLC.
> Just do PLC alone, Leave HMI till later.
> Treat it as only a practice_run, version 0.0000000000000000000000000001
> ;-)
> This is our "throw away", or a "tutorial" version.
>
> Here is a simple specification that everyone will recognise or is familiar
> with:
> Just a small 10in,8out shoe-box plc only doing bit banging relays, timers,
> counter with no retentivity yet (IL not yet LD). 1K instructions max.
> Something like a SLC503. Leave the HMI till latter, for just use whatever
> AB software you already have to download and monitor.
> Or pick on a brand that we know is not popular but is extremely easy to
> simulate, and the HMI is cheap.
>
> We can argue, and produce a better specification while we are leering by
> doing the simple thing.
> For most of us, there are an awful lot of things to learn just doing this
> much. Not many of us have many compilers designs to our name.
>
> If we eventually decide to make the LinuxPLC be a (6)1131 compliant device,
> we are going to have to become competent in a lot of computer science, by
> starting simple first. I suggest that we -do- the "very simple" version
> first almost right now, and simultaneously hold discussions about the best
> architecture that the first real LinuxPLC. Learn to make the first real
> LinuxPLC, by doing, on the "too simple", "throw-away", "getting started",
> version.
>
> Yes/No/Maybe/Never/Good/Bad/Indifferent?
>
> <clip>
> Lets not get so much stuff on our plate, that we never
> produce a system at all.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
I've been trying to get some concensus on this for a while now. We don't even need a full PLC for now, just representative IO and the thing that sequences it (dodging terminology problems)
loading the map. This will allow us to answer most of the speed questions and come up with an approach that will work. The time to scan X points is our major constraint. This will allow us to define our method for driving IO and define map structure and location. If we use the map as our dividing line and get that much done, we can get many more people working. The problem is
that much of the discussion is about things that go on the IO side. I suggest we decide on the minimum feature set the drivers will have to support:
For Example
status request.
Read all inputs to map.
Write all mapped outputs.
Read dig. inputs to map.
Read analog inputs to map.
Write mapped dig. outputs.
Write mapped analog outputs.
Not all forms of IO would have these:
ioctls for setup.
ioctls for features, (en)(dis)able latch, (en)(dis)able counter, resets, etc.
status/error register(s) in map
All drivers will present data in the same format in an assigned
location, maybe fixed map for now.
etc. etc.
I see the thing that sequences it as doing something like this:
input_map_valid_flag(0);
lock_map(); /* or semaphore++ */
for( entity = 0 ; entity < num_devices ; entity++)
{
standard_read_all_call( entity );
}
spin_on_status_until_all_reads_complete(); /* or sleep */
input_map_valid_flag(1);
unlock_map(); /* or semaphore-- */
and much the same on writes. Please don't attack the semantics of my
"C-docode" I think in C.
If we could get just this much really working it would show us a lot about what we are going to have to do to get scan times in line and many other questions we talk about. And people could start on test drivers for their favorite IO.
Well, we'd also need a map display.
The most critical information in the least time to enable the most work to start or continue.
Curt Wuollet,
Wide Open Technologies.
LouisKriek wrote:
>
> So is it time to decide on some - - very limited - - specifications for the
> first LinuxPLC.
> Just do PLC alone, Leave HMI till later.
> Treat it as only a practice_run, version 0.0000000000000000000000000001
> ;-)
> This is our "throw away", or a "tutorial" version.
>
> Here is a simple specification that everyone will recognise or is familiar
> with:
> Just a small 10in,8out shoe-box plc only doing bit banging relays, timers,
> counter with no retentivity yet (IL not yet LD). 1K instructions max.
> Something like a SLC503. Leave the HMI till latter, for just use whatever
> AB software you already have to download and monitor.
> Or pick on a brand that we know is not popular but is extremely easy to
> simulate, and the HMI is cheap.
>
> We can argue, and produce a better specification while we are leering by
> doing the simple thing.
> For most of us, there are an awful lot of things to learn just doing this
> much. Not many of us have many compilers designs to our name.
>
> If we eventually decide to make the LinuxPLC be a (6)1131 compliant device,
> we are going to have to become competent in a lot of computer science, by
> starting simple first. I suggest that we -do- the "very simple" version
> first almost right now, and simultaneously hold discussions about the best
> architecture that the first real LinuxPLC. Learn to make the first real
> LinuxPLC, by doing, on the "too simple", "throw-away", "getting started",
> version.
>
> Yes/No/Maybe/Never/Good/Bad/Indifferent?
>
> <clip>
> Lets not get so much stuff on our plate, that we never
> produce a system at all.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
