# anonymous plc_get_pt_by_loc()

M

#### Mario J. R. de Sousa

Jiri Baum wrote:

> Hello,
>
> > > > I remeber you saying that points may not overlap, but I think we
> > > > should allow it for read points
>
> > > No problem - points may not overlap in the config file, partly because
> > > it's confusing, partly to prevent different permissions to be assigned
> > > to the same bits. Actual point handles may overlap as much as desired.
>
> > > (Already it's possible and OK to get any number of handles to a point.)
>
> > > > For write points, also allow overlap,
>
> > > I don't even mind an overlapping mixed read-write point, as long as the
> > > programmer knows what he's doing. However, I reserve the right to doubt
> > > that the programmer knows what he's doing in this case
>
> > OK. I see where you are getting at. Do not allow any kind of overlap in
> > the config file (actually it is easier to check for this in
> > mgr_load_confmap(), and I have it almost implemented), but allow for any
> > kind of overlap in point handles obtained through plc_get_pt_by_loc(), as
> > long as the ownership is not touched.
>
> Exactly.
>
> Basically, my reasoning goes like this:
>
> The point handles access the private map; each module is welcome to
> scribble all over its private map if it feels like it. (Though it's not
> necessarily a good idea to do so.)
>
> The config defines access to the global map; that has to be strict.
>
> [...]

> > > > Example of overlapping read points: Module A is a function often used
> > > > in several programs, and requires at least one input value. It is
> > > > written as using a general point Pinput as its input value. When this
> > > > function is integrated in a larger program, this point is defined as
> > > > overlapping the point that will be used as the real input point.
>
> > > This should probably be handled by putting the name of the point in the
> > > config. I guess that means new conffile_get_value/table_pt()
> > > functions... (Or plc_pt_by_conf(), I don't know.)

I favour
plc_pt_t conffile_get_value/table_pt();
But I don't really think this is at all necessary. Pls see below why.

> > > If you just use a single pre-defined name, you have the problems of
> > > - namespace pollution: no end-user and no other module may use that
> > > name, even to mean something completely unrelated.
> > > - no reentrancy: you cannot run Module A twice.
>
> > > With configurable point names, you have separate sections, and if you want
> > > to run a module twice you use the --PLCmodule switch to tell the two copies
> > > to use different sections.
>
> > OK. Well put.
>
> > But I was considering a module written in a higher level language (like
> > the IL compiler).
>
> For end-programmer written programs, it's the end-programmer's problem.
>
> For libraries, this will be just one of many problems we have to solve - IL
> doesn't lend itself all that fabulously to modularization, as far as I see.
> Whatever program is using the library will have to cope with that (provide
> actual points for the formal points used in the library).
>
> For pre-supplied programs-
>
> > This means the higher level language will have to contain 'macros' to
> > specify that the real name of a point should be obtained from the config
> > file.
>
> Yes, that's probably the best solution. It'll need those macros for tuning
> parameters, anyway (so that process constants can be read from the config).
>
> [...]
>
> > I don't think we will require any conffile_get_value/table_pt()
> > functions. Point names are just text strings, so we can go from there.
>
> Just for convenience - getting a point handle is a specific-enough task
> that it's possible to make sensible error messages; for instance, every
> time a point is taken from the config, there is the possibility of the
> error message "value VARNAME in section SEC should be a point name but it
> is VALUE' which is not a point nor alias" (or words to that effect).
>
> (The logging policy should say how to refer to config values. Actually, the
> documentation policy should say that.)
>
> Even if it's just to encapsulate the five lines of code into one function
> it's worth it, because most of the code will be error-checking, and it's
> far too tempting to skimp on it.

OK. Here's why I don't think it is necessary:

plc_pt_t conffile_get_value_pt(const char *mod, const char *name) {
plc_pt_t p = plc_pt_by_name(conffile_get_value(mod, name));

if (p.valid == 0) plc_log_errmsg(...);

return p;
}

The code that calls this function will also have to verify if (p.valid == 0) again. There is no way we can let the main prog skimp on error checking. And the error message that the main prog will log will probably be more informative (ex. could not find point xxx, using default yyy).

Maybe later it might come in useful, but for now I can't see it's use.

> > > I'm for the "alias" syntax. That makes it clear what's going on.
>
> > Yes... agreed.
>
> We theoretically could have module-specific aliases, but it'd be hell to
> debug such a system. If there's demand for them, they could be "mod_alias".
>
> (Maybe put the previous paragraph in a comment somewhere near the alias
> code, so it's not forgotten.)

Module specific aliases requires the confmap to be aware of them, unlike global aliases. I would prefer not to support this, and let the modules work with conffile_get_value() for local aliases.

> > > Also, there should be a function to provide anonymous subaliases.
>
> > Don't think that is really required. Anonymous point handles are obtained
> > through plc_pt_by_loc(). This can handle every permutation (grouping
> > points, sub-aliases, ...)
>
> The more I think about plc_pt_by_loc(), the less I like it...

I wrote it mainly to allow mgr_load_conf_map() check if there is any overlaying of points. mgr_load_confmap() sets all the bits of every defined point to 1. Before inserting a point into the confmap, I get an anonymous point handle to check all the bits are 0.

We can make this function private, or create a confmap function to remove a point.

At moment I still favour keeping plc_pt_by_loc(). Eventually somebody will want to do funny thinks we can't even imagine. We might just as well let them, but put up a warning that they take full responsibility once they start using anonymous
handles obtained through this function.

>
> To create a sub-alias, the code would first have to call a function to tell
> it the physical location of the given point, do the arithmetic and then
> call plc_pt_by_loc() - error-checking everything along the way, of course.
> Again, it's a specific-enough task that I think a utility function is
> warranted...

OK. I agree with you here.

> Grouping points is a bit more difficult; in general, there is no guarantee
> that the points will be contiguous - therefore the code would have to have
> two variants, one for contiguous points and one for the general case. I'd
> be willing to grant the use of plc_pt_by_loc() to such code...
>
> Only the end-programmer, presumably after rigorous profiling, has the
> priviledge of guaranteeing contiguity of points (and even then the freedom
> is not complete - structs will always be contiguous).

I think the support for point grouping will be unnecessary if we support structs.

> Just for completeness, there should probably be a plc_pt_null() function
> which returns a handle to a 0-bit point (like /dev/null). I'll probably
> write it sometime when I'm feeling whimsical

Nice concept, though I can't see where it would come in useful. I'm sure you or someone else can.

> > > There may eventually be special syntaxes that declare a point and a
> > > bunch of subaliases in one line, for struct-like constructs.
>
> > Yes, good idea. This is what the PID module really needs.
>
> Exactly.
>
> > Sorry to keep bothering you with all these details.
>
> No worries. A lot of this discussion should actually be taking place on the
> list - partly to get other input (more heads more eyes), partly so it
>
> If you agree, you can reply to this on-list.
>
> [...]

> > I think we have cleared the point configuration up for now, unless you
> > have anything further to add?
>
> I think so - points, aliases, maybe subaliases. That's about it, I think,
> apart from structs.

Aren't subaliases repleaceable by structs? Or vice-versa?

>
>
> > Any sugestions for the struct-like construct syntax?
>
> Not really - I'll have a think about it.
>

I'm assuming we are limiting a struct's total length to 32 bits for now. In the end a struct is just a collection of points that may overlap, but require a special syntax in the conf file so this overlapping is obvious and not subtle.

I sugest we go with subaliases and leave out structs for now.

[...]

Mario

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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

D

#### David Campbell

Please excuse me if I am wandering from the topic, this appears to be an email thread started before I joined the list last week. I have been working on the IEC 61131-3 structured text translator so some of this is relevant:

>> Basically, my reasoning goes like this:
>>
>> The point handles access the private map; each module is welcome to
>> scribble all over its private map if it feels like it. (Though it's not
>> necessarily a good idea to do so.)
>>
>> The config defines access to the global map; that has to be strict.

> >>>> Example of overlapping read points: Module A is a function often used
> >>>> in several programs, and requires at least one input value. It is
> >>>> written as using a general point Pinput as its input value. When this
> >>>> function is integrated in a larger program, this point is defined as
> >>>> overlapping the point that will be used as the real input point.

My experience with ST coding (some 1.72 MB of raw text code for one project) is that all point accessing should be done at the CONFIG level
and the aliased variable should be passed down to the relevant PROGRAM / FUNCTION_BLOCK / FUNCTION

The only reason why a routine such as a FUNCTION_BLOCK should ever access a point directly is if it is used to read a status variable. Declaring a variable aliased with a point any place is perfectly legal according to the standard but from an implementation perspective equivalent of shooting yourself in the foot. Yes you can do it but I choose not to.

>>> But I was considering a module written in a higher level language (like
>>> the IL compiler).

As soon as I sort out some nasty BISON quirks the IL compiler/translator should be a piece of cake. At least there is only one way of doing something
in IL instead of two or three ways under ST, for example the following is equivalent:

A AND B <=> A & B <=> AND(A,B)
A > B <=> GT(A,B)

For those interested the nasty quirk that I am attempting to work around is what is the default type for an integer literal? (8, 16, 32 or 64 bit,
signed or unsigned) Normally the context takes care of the problem except when the following situation occurs:

1 > 2 (is this an 8 bit int comparison or 32 bit comparison?)

I am looking at making the integer literal default to signed 16 bit integer unless the context indicates otherwise.

>> For end-programmer written programs, it's the end-programmer's problem.
>>
>> For libraries, this will be just one of many problems we have to solve -
IL
>> doesn't lend itself all that fabulously to modularization, as far as I
see.

The difference between IL and ST is the internal code within the function block. IL and ST under the IEC spec still use the same FUNCTION_BLOCK and

>> Whatever program is using the library will have to cope with that
(provide
>> actual points for the formal points used in the library).
>>
>> For pre-supplied programs-
>>
>>> This means the higher level language will have to contain 'macros' to
>>> specify that the real name of a point should be obtained from the config
>>> file.
>>
>> Yes, that's probably the best solution. It'll need those macros for
tuning
>> parameters, anyway (so that process constants can be read from the
config).

Contact me off list, I have some examples showing how this is done if you are interested.

[*snip*]

>>>> I'm for the "alias" syntax. That makes it clear what's going on.
>>
>>> Yes... agreed.

Can someone please sort this out, I am just about to reach the area of the lexical parser that handles the alias requirements. Can I have some
agreement so I can throw in the appropriate "C" code.

>> We theoretically could have module-specific aliases, but it'd be hell to
>> debug such a system. If there's demand for them, they could be
"mod_alias".

[*snip*] Arrggg!!!!

>> Grouping points is a bit more difficult; in general, there is no
guarantee
>> that the points will be contiguous - therefore the code would have to
have
>> two variants, one for contiguous points and one for the general case. I'd
>> be willing to grant the use of plc_pt_by_loc() to such code...
>>
>> Only the end-programmer, presumably after rigorous profiling, has the
>> priviledge of guaranteeing contiguity of points (and even then the
freedom
>> is not complete - structs will always be contiguous).
>
> I think the support for point grouping will be unnecessary if we support
> structs.

Don't remind me about structs, that is could a serious challenge to include into the ST translator.

>>>> There may eventually be special syntaxes that declare a point and a
>>>> bunch of subaliases in one line, for struct-like constructs.
>>
>>> Yes, good idea. This is what the PID module really needs.
>>
>> Exactly.

<RANT>
Why do you persist with this idea that you should be directly accessing points from control modules?

This sounds awfully like the concepts behind (excuse me for employer company references) the Honeywell "Data Highway" control system (called the TDC-2000, release early 1970's with the promise to be "good till the year 2000" [hence TDC-2000], there are oil refineries still running on the stuff!! and Honeywell still sells replacement boards...)

The "structural problem" with the TDC-2000 is that every PID loop has dedicated inputs and outputs. To do anything interesting (such as cascaded control) required a screwdriver and wire to link two PID loops together.

The current proposal sounds like you will require additional IO hardware to chain modules together. Not to mention the rainbow coloured rat nest of

This problem was addressed in later hardware where sepearate software modules (we call them points but they are more than a single value) are used for interfacing to physical IO and the control algorithims pull/push values from the interface modules.

For something like a PLC system you do not need anything as fancy, just alias all the points in one location (eg: CONFIGURATION) and pass references to the aliased variable. This allows the output of a PID module to be transfered to
an aliased variable or to a local variable. A local variable can then be passed onto another PID module as a remote set point.

Again I have some samples of ST code showing how this could be done including tuning constants for PID controllers.
</RANT>

David Campbell

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

C

#### Curt Wuollet

Hi all

I'm interested Dave, and we don't have a bandwidth problem. Don't feel you have to dive off-list, just ref the preceeding messages so we don't run too long and bother Ken. (Our gracious host).

regards
cww

"Campbell, David (Ex AS17)" wrote:
...<clip>...
> >> Yes, that's probably the best solution. It'll need those macros for
> tuning
> >> parameters, anyway (so that process constants can be read from the
> config).
>
> Contact me off list, I have some examples showing how this is done if
> you are interested.
>

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

J

#### Jiri Baum

Mario de Sousa:
> > > I don't think we will require any conffile_get_value/table_pt()
> > > functions. Point names are just text strings, so we can go from there.

Jiri Baum:
> > Just for convenience - getting a point handle is a specific-enough task
> > that it's possible to make sensible error messages; for instance, every
> > time a point is taken from the config, there is the possibility of the
> > error message "value VARNAME in section SEC should be a point name but it
> > is VALUE' which is not a point nor alias" (or words to that effect).

> > (The logging policy should say how to refer to config values. Actually,
> > the documentation policy should say that.)

> > Even if it's just to encapsulate the five lines of code into one
> > function it's worth it, because most of the code will be
> > error-checking, and it's far too tempting to skimp on it.

Mario de Sousa:
> OK. Here's why I don't think it is necessary:

> plc_pt_t conffile_get_value_pt(const char *mod, const char *name) {
> plc_pt_t p = plc_pt_by_name(conffile_get_value(mod, name));

> if (p.valid == 0) plc_log_errmsg(...);

> return p;
> }

Actually, it's more complicated than that. There's a difference between:
- conffile_get_value() failing (which is OK and the default should
be used), and
- conffile_get_value() succeeding and plc_pt_by_name() failing
(which is an error - inconsistent config most likely).

> Maybe later it might come in useful, but for now I can't see it's use.

OK, we can agree on that.

We'll write a convenience function when we have actual experience to tell us what would be convenient.

Jiri Baum:
> > > > I'm for the "alias" syntax. That makes it clear what's going on.

> > > Yes... agreed.

> > We theoretically could have module-specific aliases, but it'd be hell to
> > debug such a system. If there's demand for them, they could be "mod_alias".

> > (Maybe put the previous paragraph in a comment somewhere near the alias
> > code, so it's not forgotten.)

> Module specific aliases requires the confmap to be aware of them, unlike
> global aliases. I would prefer not to support this, and let the modules
> work with conffile_get_value() for local aliases.

Oh, I agree. Hence the `theoretically'.

Unfortunately, I can see where they might be useful - if some clown writes a binary-only program with hard-coded points and then becomes unavailable for updates.

I still don't want to support per-module aliases.

> > The more I think about plc_pt_by_loc(), the less I like it...

> I wrote it mainly to allow mgr_load_conf_map() check if there is any
> overlaying of points. mgr_load_confmap() sets all the bits of every
> defined point to 1. Before inserting a point into the confmap, I get an
> anonymous point handle to check all the bits are 0.

> We can make this function private, or create a confmap function to remove
> a point.

> At moment I still favour keeping plc_pt_by_loc(). Eventually somebody
> will want to do funny thinks we can't even imagine. We might just as well
> let them, but put up a warning that they take full responsibility once
> they start using anonymous handles obtained through this function.

I think this is the best approach. Like you say, people want to do funny things, and if we take it out we'll only have to put it back in again. Put
a warning in the docs... (Hmm, we should be writing docs, shouldn't we.)

> > Grouping points is a bit more difficult; in general, there is no
> > guarantee that the points will be contiguous - therefore the code would
> > have to have two variants, one for contiguous points and one for the
> > general case. I'd be willing to grant the use of plc_pt_by_loc() to
> > such code...

> > Only the end-programmer, presumably after rigorous profiling, has the
> > priviledge of guaranteeing contiguity of points (and even then the
> > freedom is not complete - structs will always be contiguous).

> I think the support for point grouping will be unnecessary if we support
> structs.

OK.

> > Just for completeness, there should probably be a plc_pt_null()
> > function which returns a handle to a 0-bit point (like /dev/null). I'll
> > probably write it sometime when I'm feeling whimsical

> Nice concept, though I can't see where it would come in useful. I'm sure
> you or someone else can.

Like I said, when I'm feeling whimsical...

Seriously, it may be useful like /dev/null where some library function requires a point handle but I'm calling it for some other effect. Say a
(badly written) timer library requiring an output point, where I want to just get time values for use in arithmetic.

> > [...]

> > > I think we have cleared the point configuration up for now, unless
> > > you have anything further to add?

> > I think so - points, aliases, maybe subaliases. That's about it, I
> > think, apart from structs.

> Aren't subaliases repleaceable by structs? Or vice-versa?

A (sub)alias is just a new name for something, which doesn't affect the global map (hence anyone can make one).

A struct is basically a bunch of point declarations that go together (sorry, I guess I put that badly earlier).

The practical difference (for now) is that parts of a struct may be owned by different modules, while subaliases inherit the ownership of the point.

(Maybe "struct" is a bad name. "subpoint" for the parts would be consistent, but whether it makes any sense apart from that I don't know.)

> > > Any sugestions for the struct-like construct syntax?

> > Not really - I'll have a think about it.

> I'm assuming we are limiting a struct's total length to 32 bits for now.
> In the end a struct is just a collection of points that may overlap, but
> require a special syntax in the conf file so this overlapping is obvious
> and not subtle.

Well, the subpoints themselves shouldn't overlap. That'd give ambiguous ownership again.

But each subpoint can have a different owner, whereas subaliases can't.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

J

#### Jiri Baum

Campbell, David (Ex AS17):
> Please excuse me if I am wandering from the topic, this appears to be an
> email thread started before I joined the list last week.

No, it was a private e-mail thread between myself and Mario that we decided really should be on the list...

Some of the below is really our fault, because we just shifted the thread onto the list without taking the time to go through and explain context.

The most important confusion word is probably "module", which refers not to modules in an IL/ST program but to modules in the PuffinPLC. That is, the logic module, the I/O module, the MMI module and so forth.

(Actually, another meaning of the word "module" is "a bunch of I/O points in the same box", but that's not what we mean either.)

> > >>>> Example of overlapping read points: Module A is a function often
> > >>>> used in several programs, and requires at least one input value.
> > >>>> It is written as using a general point Pinput as its input value.
> > >>>> When this function is integrated in a larger program, this point
> > >>>> is defined as overlapping the point that will be used as the real
> > >>>> input point.

> My experience with ST coding (some 1.72 MB of raw text code for one
> project) is that all point accessing should be done at the CONFIG level
> and the aliased variable should be passed down to the relevant PROGRAM /
> FUNCTION_BLOCK / FUNCTION

Yes. I think we agreed with Mario that writing Module A like that is a Wrong Thing.

> The only reason why a routine such as a FUNCTION_BLOCK should ever access
> a point directly is if it is used to read a status variable. Declaring a
> variable aliased with a point any place is perfectly legal according to
> the standard but from an implementation perspective equivalent of
> shooting yourself in the foot. Yes you can do it but I choose not to.

Yes.

[tangent - parsing code]
> 1 > 2 (is this an 8 bit int comparison or 32 bit
> comparison?)

> I am looking at making the integer literal default to signed 16 bit
> integer unless the context indicates otherwise.

I'd vote for signed 32-bit integer, but other than that it sounds good.

[end tangent]

> >> For end-programmer written programs, it's the end-programmer's
> >> problem.

> >> For libraries, this will be just one of many problems we have to solve
> >> - IL doesn't lend itself all that fabulously to modularization, as far
> >> as I see.

> The difference between IL and ST is the internal code within the function
> block. IL and ST under the IEC spec still use the same FUNCTION_BLOCK and
> PROGRAM headers. ST when used correctly can be made very "modularisable".

OK, good. (I wasn't aware of that.) In that case, a library should take the point as one of its parameters and it's the calling program's problem to pass the correct point (or one of its own parameters).

> >> Whatever program is using the library will have to cope with that
> >> (provide actual points for the formal points used in the library).

> >> For pre-supplied programs-

> >>> This means the higher level language will have to contain 'macros' to
> >>> specify that the real name of a point should be obtained from the
> >>> config file.

> >> Yes, that's probably the best solution. It'll need those macros for
> >> tuning parameters, anyway (so that process constants can be read from
> >> the config).

> Contact me off list, I have some examples showing how this is done if you
> are interested.

No worries - I take it it's the problem of the language interpreter to handle this. We in the SMM just have to provide you with the functions...
(And explain how they work. Oops!)

> >>>> I'm for the "alias" syntax. That makes it clear what's going on.

> >>> Yes... agreed.

> Can someone please sort this out, I am just about to reach the area of
> the lexical parser that handles the alias requirements. Can I have some
> agreement so I can throw in the appropriate "C" code.

I think the aliases Mario and I are talking about and the aliases you are talking about are completely different things...

In C code, a point is referred to by a variable of type plc_pt. If you want an alias, you simply copy it into another variable of type plc_pt and you have it. If you are calling a function, you can simply pass it as an argument, and if desired you can return it.

Like this:

plc_pt xyzzy(plc_pt foo, plc_pt bar) {
plc_pt f = foo; /* f and foo now refer to the same point */
u32 i;

plc_set(f,1);
i = plc_get(foo);
/* i now has the value 1 [though see note] */

plugh(foo);

if (...)
return foo;
else
return bar;
}

Note: actually, it's possible that foo was a 0-bit point, in which case it can't store anything, obviously. But I assume 0-bit points will be unusual.

On the other hand, to obtain a point you call the plc_pt_by_name() function. This takes a string with the point name returns a handle to the
point (or an error). Point handles aren't particularly sensitive: nobody's keeping track of them, they don't need destruction, there are no hidden structures behind them.

I think you'd agree getting points willy-nilly is a recipe for disaster; in many cases, it may well be confined to a single "setup points" function. In a high-level language such as IL or ST, getting points would be implicit, with the compiler generating the appropriate calls automatically, probably with provision for config-override.

The IL/ST compiler may also provide such conveniences as disallowing setting of read-only points. (Setting read-only points is allowed by the SMM; all such changes are discarded at the next plc_update(). While this may be handy when a module needs to lie to itself about what was just
input, it's not necessarily a good idea.)

> >> We theoretically could have module-specific aliases, but it'd be hell
> >> to debug such a system. If there's demand for them, they could be
> >> "mod_alias".

> [*snip*] Arrggg!!!!

Exactly.

> >> Grouping points is a bit more difficult; in general, there is no
> >> guarantee that the points will be contiguous - therefore the code
> >> would have to have two variants, one for contiguous points and one for
> >> the general case. I'd be willing to grant the use of plc_pt_by_loc()
> >> to such code...

> >> Only the end-programmer, presumably after rigorous profiling, has the
> >> priviledge of guaranteeing contiguity of points (and even then the
> >> freedom is not complete - structs will always be contiguous).

> > I think the support for point grouping will be unnecessary if we
> > support structs.

> Don't remind me about structs, that is could a serious challenge to
> include into the ST translator.

Don't worry too much - I'm not even sure "struct" is a good word here, and anyway we're probably talking about something completely different.

> >>>> There may eventually be special syntaxes that declare a point and a
> >>>> bunch of subaliases in one line, for struct-like constructs.

> >>> Yes, good idea. This is what the PID module really needs.

> >> Exactly.

> <RANT>
> Why do you persist with this idea that you should be directly accessing
> points from control modules?

Note - We are using "point" to mean "a point in the shared map". Such a point may or may not correspond to a physical I/O point.

...
> The "structural problem" with the TDC-2000 is that every PID loop has
> dedicated inputs and outputs. To do anything interesting (such as
> cascaded control) required a screwdriver and wire to link two PID loops
> together.

> The current proposal sounds like you will require additional IO hardware
> to chain modules together. Not to mention the rainbow coloured rat nest

Actually, here the rat nest would be virtual, but you have a good point.

Perhaps we should abolish the discussion of structs/subpoints and simply require the PID module to collect its flags from separate points?

What do you think, Mario?

> This problem was addressed in later hardware where sepearate software
> modules (we call them points but they are more than a single value) are
> used for interfacing to physical IO and the control algorithims pull/push
> values from the interface modules.

This may be fairly similar to the structure of the PuffinPLC - the points we are talking about are in-memory. Some of them are interfaced to physical IO by I/O modules, some of them are used just to communicate between the logic engine and the MMI module, and so on.

(In fact, there's no requirement for a logic engine in a PuffinPLC. It is quite permissible to have just I/O and MMI, or to have two different kinds of I/O for a traffic cop.)

Hope I've cleared things up a bit... I'm afraid Mario and I haven't been keeping up with the docs very well, but what's in doc/smm is still all
valid, I think. (There's also a README file, but it's a bit low-level.)

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

M

#### Mario de Sousa

Jiri Baum wrote:

> [big snip...]

>
> [tangent - parsing code]
> > 1 > 2 (is this an 8 bit int comparison or 32 bit
> > comparison?)
>
> > I am looking at making the integer literal default to signed 16 bit
> > integer unless the context indicates otherwise.
>
> I'd vote for signed 32-bit integer, but other than that it sounds good.
>
> [end tangent]
>

Yes, I agree. The SMM is currently using points with a maximum of 32 bits.

> [...]

> > >>>> I'm for the "alias" syntax. That makes it clear what's going on.
>
> > >>> Yes... agreed.
>
> > Can someone please sort this out, I am just about to reach the area of
> > the lexical parser that handles the alias requirements. Can I have some
> > agreement so I can throw in the appropriate "C" code.
>
> I think the aliases Mario and I are talking about and the aliases you are
> talking about are completely different things...
>
> In C code, a point is referred to by a variable of type plc_pt. If you want
> an alias, you simply copy it into another variable of type plc_pt and you
> have it. If you are calling a function, you can simply pass it as an
> argument, and if desired you can return it.
>

Actually, its plc_pt_t

> [...]

> On the other hand, to obtain a point you call the plc_pt_by_name()
> function. This takes a string with the point name returns a handle to the
> point (or an error).

What Jiri and I were discussing is how to define in the config file that a named point is actually an alias to a previously defined point.

example config:
point P0 "P0 full name" owner_module at 10.0
point_alias P1 "P1 full name" P0

So in C code:
plc_pt_t p0, p1;

p0 = plc_get_pt_by_name("P0");
p1 = plc_get_pt_by_name("P1");

p0 and p1 would refer to the same point.

This takes care of the problem Jiri refered to on his previous mail, i.e. a module with a hard-coded point, to which no source code is available. Off course, only one copy of this module can run.

> > >> We theoretically could have module-specific aliases, but it'd be hell
> > >> to debug such a system. If there's demand for them, they could be
> > >> "mod_alias".
>
> > [*snip*] Arrggg!!!!
>
> Exactly.

We're all agreed here. This was simply a suggestion of how we could have that binary module with a hard coded point to run several copies.

We won't support this now, and hopefuly not in the future either.

> ...
> > The "structural problem" with the TDC-2000 is that every PID loop has
> > dedicated inputs and outputs. To do anything interesting (such as
> > cascaded control) required a screwdriver and wire to link two PID loops
> > together.
>
> > The current proposal sounds like you will require additional IO hardware
> > to chain modules together. Not to mention the rainbow coloured rat nest
>
> Actually, here the rat nest would be virtual, but you have a good point.
>
> Perhaps we should abolish the discussion of structs/subpoints and simply
> require the PID module to collect its flags from separate points?
>

Abolishing the structs/subpoints won't eliminate the virtual rat's nest. The virtual rat's nest will only go away if the dsp module uses internal/private memory for interconnecting several PID's, filters, ...
It is my opinion we shouldn't worry too much about this at the moment. I guess that in the future we will have some GUI driven program to generate the config file for us. The dsp module would have something similar to the
matlab/simulink interface, where you just draw lines between PID and filter blocks.

> What do you think, Mario?

For the sake of everybody that has just tuned in:
The structs/subpoints was to allow the dsp module to do only one plc_get() on a 32 bit point, in which each bit would be an independent flag. Each bit would be written to by other (possibly not all the same) modules that are dynamically configuring the PID module. So each individual bit would also have to be a named point so the PID-configuring modules could do a plc_set(...) on
a single bit.

This is just an optimization for now, though I believe that in the future someone else will also want this functionality. We can probably put it off until then.

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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

J

#### Jiri Baum

Jiri Baum:
> > In C code, a point is referred to by a variable of type plc_pt. If you
> > want an alias, you simply copy it into another variable of type plc_pt
> > and you have it. If you are calling a function, you can simply pass it
> > as an argument, and if desired you can return it.

Mario de Sousa wrote:
> Actually, its plc_pt_t

So it is. Sorry - I think it used to be plc_pt a long time ago.

> > [...]

> > ...
> > > The "structural problem" with the TDC-2000 is that every PID loop has
> > > dedicated inputs and outputs. To do anything interesting (such as
> > > cascaded control) required a screwdriver and wire to link two PID
> > > loops together.

> > > The current proposal sounds like you will require additional IO
> > > hardware to chain modules together. Not to mention the rainbow
> > > coloured rat nest of wire links.

> > Actually, here the rat nest would be virtual, but you have a good
> > point.

> > Perhaps we should abolish the discussion of structs/subpoints and
> > simply require the PID module to collect its flags from separate
> > points?

> Abolishing the structs/subpoints won't eliminate the virtual rat's nest.

Well, it will, because we simply say that a particular point is the output of PID 1 and the input of PID 2. (It need not correspond to a physical output or anything - though the MMI can display it.)

If PIDs' inputs and outputs were in a struct, we'd have to have a piece of code somewhere that'd do a plc_set(PID_2_input, plc_get(PID_1_output)). That's the "virtual rat nest" I was talking about.

So from that point of view, it's better *not* to have structs.

> For the sake of everybody that has just tuned in:

> The structs/subpoints was to allow the dsp module to do only one
> plc_get() on a 32 bit point, in which each bit would be an independent
> flag.
...
> We can probably put it off until then.

Yes - for now (and for design cleanliness) the DSP module should input independent flags using independent point handles.

Similarly, it should output independent status flags using independent point handles.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

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

J

#### Johan Bengtsson

<huge clip>

>> The "structural problem" with the TDC-2000 is that every PID loop has
>> dedicated inputs and outputs. To do anything interesting (such as
>> cascaded control) required a screwdriver and wire to link two PID loops
>> together.
>
>> The current proposal sounds like you will require additional IO hardware
>> to chain modules together. Not to mention the rainbow coloured rat nest
>
>Actually, here the rat nest would be virtual, but you have a good point.
>
>Perhaps we should abolish the discussion of structs/subpoints and simply
>require the PID module to collect its flags from separate points?
>

I think just connecting the signals to whatever signal aviliable is the right ting to do, makes cascading etc. a lot easier and is more like the way computers designed for doing primarily this kind of control.

<clip>

/Johan Bengtsson

----------------------------------------
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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