# Step3

C

#### Curt Wuollet

Hi all

Here is where we have to pin some things down.
We have a map in memory. We have processes that will use the map. As I recall there were at least three approaches and probably more. I got really confused the last time when we got to this part.

1. My original approach was to have a cyclic I/O process that would run the drivers to scan the inputs. set a flag to tell the solver to run and
wait for a flag saying that the solver was done, then run the drivers to set the outputs. Repeat.

2. Have a manager that owns the map and coordinate with semaphores. I'm not sure of the sequencing here because there was so much discussion it was mind boggling. Some one please fill this in.

3. An asynchronous model that reads inputs and sets outputs as they are encountered in the application. This was from someone with strong
experience with *nix distributed control.

4. ?

For a bare bones start, I think 3 doesn't resemble a PLC, but might resemble what Ken etal. do with a state machine. I could be wrong, I haven't seen it.

I think 2 was to solve some problems with 1 and add features, I didn't get whether the mm ran the whole shebang or responded to requests from the solver and an I/O manager. I think both ways were proposed.

I'm leaning towards as simple as possible either 1 or having an overall loop that calls things in sequence. I don't have any code here yet. I have looped a driver to read to the map or write from the map, watching what happened with the map display. Will this work ?

Regards

cww

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

J

#### Jiri Baum

Hello,

Curt Wuollet:
> We have a map in memory. We have processes that will use the map. As I
> recall there were at least three approaches and probably more. I got
> really confused the last time when we got to this part.
...
> 2. Have a manager that owns the map and coordinate with semaphores.
> I'm not sure of the sequencing here because there was so much discussion
> it was mind boggling. Some one please fill this in.

The sequencing, by default and for pass 1, is to have each module loop as fast as it can.

While the overall model is asynchronous, the effect is almost synchronous. For the logic engine, the only difference from model 1 (synchronous model) is that ioscan time has been traded for latency - ioscan is negligible with
the SMM.

The logic engine has a cycle:
- read all inputs from SMM
- solve
- write all outputs to SMM

Each I/O driver has a separate cycle:
- read all outputs from SMM
- do the I/O
- write all inputs to SMM

In the smm API, the "read/write all inputs/outputs to/from SMM" are all covered by the plc_update() function.

> 3. An asynchronous model that reads inputs and sets outputs as they are
> encountered in the application. This was from someone with strong
> experience with *nix distributed control.

This is an option in the current SMM (unimplemented): to read/set a single point, you call the plc_update_point() function. This corresponds to the immediate output' feature of a PLC, but it only goes to the SMM.

> I don't have any code here yet. I have looped a driver to read to the map
> or write from the map, watching what happened with the map display. Will
> this work ?

Yes - that's exactly how it will work. Each driver will be looped independently.

When we have a problem with the sequencing, we'll put in semaphores. Theoretically, it should only be a problem where the loop speed of two of the modules is similar, so that the frequencies beat', but we'll see.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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

J

D

#### Dan Pierson

> 1. My original approach was to have a cyclic I/O process that would
> run the drivers to scan the inputs. set a flag to tell the
> solver to run and
> wait for a flag saying that the solver was done, then run the
> drivers to
> set the outputs. Repeat.

I think that Jiri has sort of cleared this up, but my impression was that the "drivers" would run to do both IO and the solver would solve in
parallel. This would be done by having the solver take a snapshot of the input map before starting and save a snapshot of its output map after solving. Snapshot copying would be interlocked to make this all safe. Multiple solvers are possible.

I put "drivers" in quotes above because I think that Jiri and I have a fairly serious disagreement here: IMHO it would be a big mistake to write an actual IO driver that did not conform to the standard Linux/Unix driver interface (i.e. open(), close(), read(), write(), ioctl(), etc.). Recent versions of RTLinux even support the preceeding subset in real time code.
Deviating from this standard will:

1. Limit the driver strictly to this project.
2. Confuse experienced Linux programmers.
3. Make it harder for this project to use existing drivers.
4. Make acceptance of the resulting code much less likely in the Linux community.

This means that a "driver" that does direct IO to the smm is not a driver in the Linux sense, but a higher level wrapper around a driver. Such a wrapper is obviously a reasonable thing to write. If I was doing this I'd write one (IO) or two (I and O) table driven tasks that wrapped standard Linux interface drivers. It appears that Jiri would rather write a wrapper for each driver. Either approach could work.

> 3. An asynchronous model that reads inputs and sets outputs as they
> are encountered in the application. This was from someone with strong
> experience with *nix distributed control.
...
> For a bare bones start, I think 3 doesn't resemble a PLC,
> but might resemble
> what Ken etal. do with a state machine. I could be wrong, I
> haven't seen it.

Yes, this the model that I believe is essential to implementing a Quickstep like state language. Control Tech definitely has applications running out there that do fine grained servo control and applications where waiting to read all the inputs before executing a step would be way, way too slow to make the program possible. I'd prefer that we *eventually* came up with a layered implementation such that a Quickstep-like language could benefit from the driver work, while an RLL-like solver could interface at a higher level. Please note the *eventually* above. It's much more important to get
something working now than to debate and design the perfect plan. That's why I've been fairly quiet about most of this stuff so far.

> I'm leaning towards as simple as possible either 1 or having
> an overall loop
> that calls things in sequence.

Agreed:

"Make it work.

Make it right.

Make it fast."

-- Kent Beck

Dan Pierson

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

C

#### Curt Wuollet

Dan Pierson wrote:

> > 1. My original approach was to have a cyclic I/O process that would
> > run the drivers to scan the inputs. set a flag to tell the
> > solver to run and
> > wait for a flag saying that the solver was done, then run the
> > drivers to
> > set the outputs. Repeat.
>
> I think that Jiri has sort of cleared this up, but my impression was that
> the "drivers" would run to do both IO and the solver would solve in
> parallel. This would be done by having the solver take a snapshot of the
> input map before starting and save a snapshot of its output map after
> solving. Snapshot copying would be interlocked to make this all safe.
> Multiple solvers are possible.

This seems kinda ambitious for this pass. We can have both running and sleep on a "map in use" flag for sync. Not optimal, but a lot simpler for now. This would be better than an overall loop.

> I put "drivers" in quotes above because I think that Jiri and I have a
> fairly serious disagreement here: IMHO it would be a big mistake to write an
> actual IO driver that did not conform to the standard Linux/Unix driver
> interface (i.e. open(), close(), read(), write(), ioctl(), etc.). Recent
> versions of RTLinux even support the preceeding subset in real time code.

Thank you for helping our non-unix folks out.

> Deviating from this standard will:
>
> 1. Limit the driver strictly to this project.
> 2. Confuse experienced Linux programmers.
> 3. Make it harder for this project to use existing drivers.
> 4. Make acceptance of the resulting code much less likely in the Linux
> community.

5. Break the princple of mechanism, not policy.
I agree, thats what I had the IO process handling. It does the reads, writes and ioctls that a "normal" char driver requires. ( a char driver reads one byte at a time usually as opposed to a block driver which is buffered by
the system) We will also have user land drivers for the Ethernet I/O and serial I/O. All the ugly details of map translation and device specific stuff would go in here. And it needs the scaling info, setup details, etc.

> This means that a "driver" that does direct IO to the smm is not a driver in
> the Linux sense, but a higher level wrapper around a driver. Such a wrapper
> is obviously a reasonable thing to write. If I was doing this I'd write one
> (IO) or two (I and O) table driven tasks that wrapped standard Linux
> interface drivers. It appears that Jiri would rather write a wrapper for
> each driver. Either approach could work.

We differ only in terminology
I like the individual approach for adding drivers incrementally, but we still need something to sequence them, or at least fire them all and wait for results.

> > 3. An asynchronous model that reads inputs and sets outputs as they
> > are encountered in the application. This was from someone with strong
> > experience with *nix distributed control.
> ...
> > For a bare bones start, I think 3 doesn't resemble a PLC,
> > but might resemble
> > what Ken etal. do with a state machine. I could be wrong, I
> > haven't seen it.
>
> Yes, this the model that I believe is essential to implementing a Quickstep
> like state language. Control Tech definitely has applications running out
> there that do fine grained servo control and applications where waiting to
> read all the inputs before executing a step would be way, way too slow to
> make the program possible. I'd prefer that we *eventually* came up with a
> layered implementation such that a Quickstep-like lanuage could benefit from
> the driver work, while an RLL-like solver could interface at a higher level.
> Please note the *eventually* above. It's much more important to get
> something working now than to debate and design the perfect plan. That's
> why I've been fairly quiet about most of this stuff so far.

It would be great to support both. Pass2, pass3?

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

J

#### Jiri Baum

Curt Wuollet:
> > > 1. My original approach was to have a cyclic I/O process that would
> > > run the drivers to scan the inputs. set a flag to tell the solver to
> > > run and wait for a flag saying that the solver was done, then run the
> > > drivers to set the outputs. Repeat.

Dan Pierson:
> > I think that Jiri has sort of cleared this up, but my impression was
> > that the "drivers" would run to do both IO and the solver would solve
> > in parallel. This would be done by having the solver take a snapshot
> > of the input map before starting and save a snapshot of its output map
> > after solving. Snapshot copying would be interlocked to make this all
> > safe. Multiple solvers are possible.

Curt Wuollet:
> This seems kinda ambitious for this pass.

> We can have both running and sleep on a "map in use" flag for sync. Not
> optimal, but a lot simpler for now. This would be better than an overall
> loop.

I'm not sure what you mean here - but if it's going to be used from more than one process/thread, it's going to need a semaphore anyway to make it safe, at which point the semaphore itself can mean map in use'.

> > I put "drivers" in quotes above because I think that Jiri and I have a
> > fairly serious disagreement here

Which has since been cleared up.

The problem was that I was rather sloppily using the word driver' to mean linuxPLC driver', forgetting the confusion that's going to cause with linux driver'.

I'll use `I/O module' for the rest of this e-mail (even though that's likely to confuse the PLC folks; just keep in mind it's a piece of s/w).

> > This means that a "driver" that does direct IO to the smm is not a
> > driver in the Linux sense, but a higher level wrapper around a driver.
> > Such a wrapper is obviously a reasonable thing to write. If I was
> > doing this I'd write one (IO) or two (I and O) table driven tasks that
> > wrapped standard Linux interface drivers. It appears that Jiri would
> > rather write a wrapper for each driver. Either approach could work.

> We differ only in terminology I like the individual approach for adding
> drivers incrementally, but we still need something to sequence them, or
> at least fire them all and wait for results.

Well, for pass 1 I was going to let them run as they will; sequencing can come later. Each I/O module would run in a separate loop:

loop forever
update with the SMM
end loop

The step marked (*) would be either done directly, or via a kernel-space driver, depending on the device.

> > > 3. An asynchronous model that reads inputs and sets outputs as they
> > > are encountered in the application. This was from someone with strong
> > > experience with *nix distributed control.
> > ...
> > > For a bare bones start, I think 3 doesn't resemble a PLC, but might
> > > resemble what Ken etal. do with a state machine. I could be wrong, I
> > > haven't seen it.

> > Yes, this the model that I believe is essential to implementing a
> > Quickstep like state language. Control Tech definitely has
> > applications running out there that do fine grained servo control and
> > applications where waiting to read all the inputs before executing a
> > step would be way, way too slow to make the program possible.
...

> It would be great to support both. Pass2, pass3?

Some function declarations are already in smm.h, but they're unimplemented. See plc_update_point() and plc_update_points() - they should be about 5
minutes to implement each. OTOH, you'd probably also want to sequence the I/O modules to take the value immediately, which isn't even designed yet...

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

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