[Visual-devel] Re: [MAT-devel] visual PLC drivers

[Jiri B. <ji...@ba...>]

> >> I should like to suggest that you might use these functions to interface
> >> with matPLC. For VISUAL, I plan to modify PLC drivers in a way that they
> >> rely on library routines providing above described functionalty.
> >> This means also that I'm prepared to provide the protocols for the other
> >> PLC families supported by VISUAL in similar libraries. My problem is
> >> that I do not have different PLCs from each manufacturer to testwith.
> >
> >The other possibility would be to migrate all the drivers to one project
> > or the other, and interface the two together.
>
> I don't think so. What I tried to say in the above mentioned thread on
> control.com and what I tried in designing the interface of libnodave is to
> design it for general purpose useful to many more projects.

Yeah; ideally the MatPLC or VISUAL, as a library, would also be useful to
 many projects...

The idea behind migrating the drivers to one project would be that the
particular project would become the designated PLC driver collection. All
other projects that need to talk to PLCs would then interface to it.

An alternative would be to start a new project, design a new interface, and
 go from there; I believe Lynn Linse is working on that, but only started a
 month or two back, so it's going to be a while yet.

The MatPLC does provide a more than a plain interface to PLC data, but if you
just want to use it for that, there's not that much extra - mostly end-user
flexibility, where they can map data to different physical I/O (or even fixed
values) without you having to do anything to enable that.

> >For instance, if the drivers were
> >migrated to the MatPLC, the VISUAL server would link against the matplc
> >library instead of loading the PLC drivers.
>
> In VISUAL it is not THE library, but shared objects for each PLC type,
> because most users will not need more than one while the total number of
> supported PLCs may (hopefully) reach hundreds (Seeing the lists of other
> SCADA vendors...).

I understand. The main difference would be that rather than being loaded by
the VISUAL server directly, the driver (usually just one) would be running
alongside as a MatPLC module, providing data.

> >(The MatPLC points are named rather than having a dev/subdev/area/offset
> >structure,
>
> This structure doesn't reflect VISUAL's side, but is meant as a superset of
> the supported PLC's addressing scheme. In addition to these items, there
> are an area number and a transport method.

Yes. MatPLC takes the approach of user-meaningful variable names, which are
translated to actual device addresses as late as possible (in the PLC
driver).

> >Possibility three is the DAIS thing, which is pretty much the equivalent
> > of OPC, but it's a bit heavy-weight for our purposes. Eventually we'll
> > need DAIS anyway, but for communicating over the network, not for local
> > interface.
>
> I don't know that.

DAIS is basically the CORBA equivalent of OPC. It would be possible to use it
as the protocol for talking between a driver and MatPLC or VISUAL, but it
seems overkill to have an arms-length protocol like CORBA between two GPL'd
pieces of code...


Jiri
--
Jiri Baum <ji...@ba...>           http://www.csse.monash.edu.au/~jirib
  MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
MAT-devel mailing list
MAT...@li...
https://lists.sourceforge.net/lists/listinfo/mat-devel