Curt Wuollet:
> Anyway, as soon as the board arrives, I'll start on a first pass IO
> process. The configuration for the IO and the config for the mm will
> have to be aware of each other so we can go from a name to a pin.

Well, the IO configuration goes from the physical I/O to a name. The MM configuration goes from a name to a MM location. The only place where they
meet is at the name, which has to be the same.

> As I understand it now, I'll be getting inputs byte wide and getting a
> handle for each bit. It would be handy to implement word handles. I
> suppose I could just get a pointer and write words anyway.

If the IO is conceptually word-oriented (analogue or integer or character), you can get a word handle. However, if it's just eight bits that you happen to read together, then you should use bit handles, so that they are not necessarily contiguous in the MM.


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

 

Jiri Baum wrote:

> Well, the IO configuration goes from the physical I/O to a name. The MM
> configuration goes from a name to a MM location. The only place where they
> meet is at the name, which has to be the same.

Yes, that would be the tie and I'll need the set associated with a particular device. These assignments should probably occur at the same time because the user would expect that. Ideas? Sounds like we're back to a setup and configuration utility. Actually, to the user, only the name and pin are important. The map will be transparent to them.

> > As I understand it now, I'll be getting inputs byte wide and getting a
> > handle for each bit. It would be handy to implement word handles. I
> > suppose I could just get a pointer and write words anyway.
>
> If the IO is conceptually word-oriented (analogue or integer or character),
> you can get a word handle. However, if it's just eight bits that you happen
> to read together, then you should use bit handles, so that they are not
> necessarily contiguous in the MM.

True, although it would be nice if I didn't have to do 48 lookups and assignments. I'll have to think on that a bit. Nothing clever comes to mind at the moment. Actually if our first victim supported analog we would need to do both.



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

 

About two weeks back...

> > Curt Wuollet:
> > > As I understand it now, I'll be getting inputs byte wide and getting
> > > a handle for each bit. It would be handy to implement word handles. I
> > > suppose I could just get a pointer and write words anyway.

Jiri Baum:
> > If the IO is conceptually word-oriented (analogue or integer or
> > character), you can get a word handle. However, if it's just eight bits
> > that you happen to read together, then you should use bit handles, so
> > that they are not necessarily contiguous in the MM.

Curt Wuollet:
> True, although it would be nice if I didn't have to do 48 lookups and
> assignments. I'll have to think on that a bit. Nothing clever comes to
> mind at the moment.

Well, you can't really do anything clever, because in "traffic cop" installations you just can't have everything contiguous.

You could theoretically have conditional clever things, but at great cost in code complexity.

> Actually if our first victim supported analog we would need to do both.

Of course. The 1-bit-wide code was just so that there's *something* that works, even if it doesn't yet do everything.

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