# Program structure

J

#### Jansen, Joe

Has there been any agreement on how the structure of this system would fit together? I have been slogging through the email archives, but January is fairly daunting to get through, so I will risk repeating something that was discussed.

I would like to make the following suggestion. Whoever does the ladder engine would be passed an I/O table (or pointer to) and a Linked list( or
whatever) of op-codes, p-code, or however that individual wants it. The engine would perform one scan, update the I/O, and return. This way, if I wanted to run an IL instead of ladder, I could 'plug in' the engine of my choice, and give it the appropriate user code. I would think this would make it very easy for a 'controlling skeleton' to be able to execute a ladder
program, a flow chart, an IL, etc. The editors would then compile the human readable language into the executable. Since most online data monitoring is just deciding how to display the data table, the editor could do the tricks
with lighting up the instructions that are true, etc. based in the data tables.

Online edits would be easily accomplished, just make the edits in a mirrored copy of the file, and when the user commits, change the pointer
reference.

I/O drivers would also be plugged and unplugged based on what the user has. The driver would function as the "abstraction layer" so that the processing engines did not need to be concerned with what was out there.

The control skeleton would then simply execute I/O drivers, then execute each processing engine that was needed, either sequentailly or multi
threads, then update I/O again. If the editor was needed, it would spawn that process.

I am not a C programmer (yet), so what I suggested needs to be run through the reality checker. However, I will be taking classes starting in April, and would be interested in self-teaching now while trying to write an IL
processing engine. I would like to have some guidelines, however, on what the interface needs to look like. As I said, I would like to see the
engines passed a pointer to the I/O tables, and the p-code linked list. I think this would maximize our ability to adapt to what the user wants to run, and makes it easier for us to implement something VERY simplistic now, and have the ability to add more engines, and refine existing engines, without messing everything else up.

As I mentioned at the beginning, if this has already been covered, tell me to get lost, and I will go along with what has been determined. If not, then let me know what everyone thinks.

In the meantime, I will try to find time to learn C enough to hack together a dumb-simple IL processor.

As a side note, I think that for testing the engines, everything could be done with simulated I/O. An I/O simulator might also be the best driver to write first, and the "real life" hardware drivers can write to the same interface.

Comments? This is my \$.02 worth..........

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

J

#### Jiri Baum

Hello,

Jansen, Joe:
> I would like to make the following suggestion. Whoever does the ladder
> engine would be passed an I/O table (or pointer to)

Yup.

> and a Linked list( or whatever) of op-codes, p-code, or however that
> individual wants it.

I think that's up to the individual logic engine. Some logic engines might be hard-coded in C, even, or they might be neural nets that take weights rather than opcodes.

> The engine would perform one scan, update the I/O, and return.

The engine was expected to be running in a separate task, so it would be perform one scan, update the I/O, and repeat'.

> this way, If I wanted to run an IL instead of ladder, I could 'plug in'
> the engine of my choice, and give it the appropriate user code.

Yup.

> I would think this would make it very easy for a 'controlling skeleton'
> to be able to execute a ladder program, a flow chart, an IL, etc. The
> editors would then compile the human readable language into the
> executable.

That's logic-engine dependent. Some might be interpreters (or PID controllers that just read in a dozen numbers and go).

> Since most online data monitoring is just deciding how to display the
> data table, the editor could do the tricks with lighting up the
> instructions that are true, etc. based in the data tables.

Yup.

> Online edits would be easily accomplished, just make the edits in a
> mirrored copy of the file, and when the user commits, change the pointer
> reference.

This is not so easy if you have a language which includes the notion of state' (finite-state machine, petri net, stacks and things). But for
stateless languages like ladder this is almost perfectly true. Almost, because the loading is going to cause timing jitter.

> I/O drivers would also be plugged and unplugged based on what the user
> has. The driver would function as the "abstraction layer" so that the
> processing engines did not need to be concerned with what was out there.

Definitely.

In fact, in some applications, you might not have a logic engine at all. For a "traffic cop" you'd just have a set of I/O drivers.

> As a side note, I think that for testing the engines, everything could be
> done with simulated I/O. An I/O simulator might also be the best driver
> to write first, and the "real life" hardware drivers can write to the
> same interface.

This is the mirror of the "traffic cop" situation: there would be two logic engines and no I/O driver. One of the logic engines would run "the program to be tested" and the other would be "the simulator"[1].

Jiri
[1] starring Arnold Schwartzenegger ?
--
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

#### Joe Jansen

Good Morning! (US, Central Standard Time) :^}

I am still making progress on the january archive. I have read Feb and March, and am at about Jan 16. My comments will therefore reflect events at that point in time to some extent....

-> -----Original Message-----
-> From: Jiri Baum [mailto:[email protected]]
->
-> Hello,
->
-> Jansen, Joe:
-> > I would like to make the following suggestion. Whoever does the ladder
-> > engine would be passed an I/O table (or pointer to)
->
-> Yup.
->
-> > and a Linked list( or whatever) of op-codes, p-code, or however that individual wants it.
->
-> I think that's up to the individual logic engine. Some logic
-> engines might
-> be hard-coded in C, even, or they might be neural nets that
-> take weights rather than opcodes.

So should I put together an editor as well? First?

-> > The engine would perform one scan, update the I/O, and return.
->
-> The engine was expected to be running in a separate task, so
-> it would be
-> perform one scan, update the I/O, and repeat'.

When you say 'update the I/O', do you mean write it's outputs and get another snapshot if the inputs, or trigger an update to the hardware and
wait for it to come back?

-> > this way, If I wanted to run an IL instead of ladder, I
-> could 'plug in'
-> > the engine of my choice, and give it the appropriate user code.
->
-> Yup.
->
-> > I would think this would make it very easy for a
-> 'controlling skeleton'
-> > to be able to execute a ladder program, a flow chart, an
-> IL, etc. The
-> > editors would then compile the human readable language into the
-> > executable.
->
-> That's logic-engine dependent. Some might be interpreters (or PID
-> controllers that just read in a dozen numbers and go).

I guess the point I wanted to make is that all of the logic engines should have a common interface so that if a new language comes along 5 years from
now, it can be incorporated easily.

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

J

#### Jiri Baum

> > Jansen, Joe:
> > > and a Linked list( or whatever) of op-codes, p-code, or however that
> > > individual wants it.

> > I think that's up to the individual logic engine. Some logic engines
> > might be hard-coded in C, even, or they might be neural nets that take
> > weights rather than opcodes.

Jansen, Joe:
> So should I put together an editor as well? First?

An editor will also be required, though not as urgently as some of the other parts, since it's quite viable to use one of the text-based languages and edit them with vi/emacs.

(If you want to do it, check to make sure no-one else is already doing it. I have a feeling someone was talking about it; I think nothing concrete was said, but better ask again when you are ready to start coding...)

> > > The engine would perform one scan, update the I/O, and return.

> > The engine was expected to be running in a separate task, so it would
> > be perform one scan, update the I/O, and repeat'.

> When you say 'update the I/O', do you mean write it's outputs and get
> another snapshot if the inputs, or trigger an update to the hardware and
> wait for it to come back?

The former. Triggering an update to the harware is in the WDIL basket.

The I/O drivers will be running asynchronously to the logic engine. Whenever they have data, they write it into the Shared Map, whenever the Shared Map changes they write the data to the physical outputs.

When the logic engine `updates the I/O', it'll simply copy the outputs into the Shared Map, and read in whatever's currently in the Shared Map for the inputs. This will not be a problem unless the speeds of the I/O driver and the logic engine are similar (or close to a simple fraction).

> > > I would think this would make it very easy for a 'controlling
> > > skeleton' to be able to execute a ladder program, a flow chart, an
> > > IL, etc. The editors would then compile the human readable language
> > > into the executable.

> > That's logic-engine dependent. Some might be interpreters (or PID
> > controllers that just read in a dozen numbers and go).

> I guess the point I wanted to make is that all of the logic engines
> should have a common interface so that if a new language comes along 5
> years from now, it can be incorporated easily.

OK. I suppose that depends to some extent on how similar the new language is to the existing languages. In fact, the difference between ladder

Certainly, though, even if a p-code interpreting logic engine can't be re-used, the interface to the Shared Memory will be well-defined, so that
you can just drop in another logic engine (q-code interpreting). It sort of has to be - if you allow logic engines to be written in C, then you
automatically have the provision for this.

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