Re: IEC 61131-3 -> Almost fully implemented!

Hi,

We wrote a CNC program (a GUI to create programs and RT part
to run 
them) running under linux. And develop some IO boards of our
own.
We work with machine manufacturers to run a machine.
They want a PLC interface to program the machine's special
features 
(clamps, pumps, hydrolic etc.).

I skimmed MAT-PLC documentation. It looks I can write a
custom module to 
give access to CNC variables and external IO boards.
Here is what I have in my mind. Do you think it is
feasible?
- user writes a PLC program in IEC 61131-3 languages.
- somehow this program is converted in C (Possibly using
Beremiz 
Project? or MatPLC compiler)
- final program runs as a MatPLC module on our target
machine. It 
interacts with a MatPLC module, which I should write, to
access to the 
CNC variables, states, IO etc..

My main questions are as follows,
- Can MatPLC be used in a such a commercial project?
- Licence issues ?
- Reliability ?
- References of other commercial projects ?
- It may be better if the final PLC program is run in an
interpreter. So 
we could avoid cross compile issues.

Thanks in advance,
Oguz.

-- 
Oguz Dilmac
ARGE Bolumu

Bilko AS, R&D Department
====================================
Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2568
TR-34384 Okmeydani Istanbul Turkey
Tel : +90 212 220 07 40  Fax :   +90 212 210 47 01
e-mail : odilmacbilko-automation.com
web site : http://www.bilko-auto
mation.com



------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

Hello,

Oguz Dilmac:
> I skimmed MAT-PLC documentation. It looks I can write a
custom module to
> give access to CNC variables and external IO boards.

Yes.

> Here is what I have in my mind. Do you think it is
feasible?
> - user writes a PLC program in IEC 61131-3 languages.

Note that we only do ST and IL at the moment.

> - somehow this program is converted in C (Possibly
using Beremiz
> Project? or MatPLC compiler)
> - final program runs as a MatPLC module on our target
machine. It
> interacts with a MatPLC module, which I should write,
to access to the
> CNC variables, states, IO etc..

Makes sense.

> My main questions are as follows,
> - Can MatPLC be used in a such a commercial project?

Yes.

> - Licence issues ?

The project is under the GPL. The main requirement is that
you have to supply 
your clients with the source code for MatPLC (and anything
derived from it). 
There are some other conditions, but they're unlikely to be
show-stoppers...

> - Reliability ?

No formal studies, AFAIK.

> - References of other commercial projects ?

None that have come back to us... there are occasional posts
on the mailing 
list indicating that it is used, but nothing we can actually
forward as a 
reference. The last one I recall is a short sentence in
mid-March this year.

(Unless there's somebody lurking on the list who can come
forward?)

> - It may be better if the final PLC program is run in
an interpreter. So
> we could avoid cross compile issues.

There's no "in principle" reason an IEC 61131-3
interpreter wouldn't work, it 
just hasn't been written yet. The compiler is modular, so
possibly it could 
be extended to do this (by creating a "code
generation" phase that simply 
executes the program instead of generating code for it).

Mario? What do you think?


Jiri
-- 
Jiri Baum <jiribaum.com.au>                   http://www.baum.com.au/~
jiri

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

On Wednesday 05 September 2007 16:20, Jiri Baum wrote:
> Hello,
>
> Oguz Dilmac:
(...)
> > Here is what I have in my mind. Do you think it is
feasible?
> > - user writes a PLC program in IEC 61131-3
languages.
>
> Note that we only do ST and IL at the moment.

 The graphical editors have already been implemented.
However, since they are 
currently still being modified quite heavilly, they haven't
been copied back 
into the MatPLC roject. However, this code already exists,
and already works. 
All under GPL v2.
(...)
> > - It may be better if the final PLC program is run
in an interpreter. So
> > we could avoid cross compile issues.
>
> There's no "in principle" reason an IEC
61131-3 interpreter wouldn't work,
> it just hasn't been written yet. The compiler is
modular, so possibly it
> could be extended to do this (by creating a "code
generation" phase that
> simply executes the program instead of generating code
for it).
>
> Mario? What do you think?
>


 Yes, undoubtably. The IEC compiler is very modular, so
having it produce some 
other kind of output does not require it to be re-written
from scratch.

 Howerver, producing code that will be interpreted later
either means also 
writing the interpreter, or using an existing interpreter.
The first things 
that come to mind would be producing either Java or python
code, and then 
using the already existing interpreters for these
languages.

 We could also write our own IEC 61131-3 specific
interpreter, but that means 
much more work.


 Cheers,

		Mario.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

Hello,

Mario:
>  The graphical editors have already been implemented.
However, since they
> are currently still being modified quite heavilly, they
haven't been copied
> back into the MatPLC roject. However, this code already
exists, and already
> works. All under GPL v2.

Cool!

Jiri:
> > There's no "in principle" reason an IEC
61131-3 interpreter wouldn't
> > work, it just hasn't been written yet. The
compiler is modular, so
> > possibly it could be extended to do this (by
creating a "code generation"
> > phase that simply executes the program instead of
generating code for
> > it).

> > Mario? What do you think?
...
>  Howerver, producing code that will be interpreted
later either means also
> writing the interpreter, or using an existing
interpreter. 

I was thinking of making the Stage 4 execute the program
directly. Just do it, 
as they say in footwear advertisements. If you can generate
the code, you 
should be able to run it instead... (though I'm not familiar
with the 
internals, so maybe it would be more difficult than that).

Jiri
-- 
Jiri Baum <jiribaum.com.au>                   http://www.baum.com.au/~
jiri

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

On Wednesday 05 September 2007 17:19, Jiri Baum wrote:
> Hello,
>
> Mario:
> >  The graphical editors have already been
implemented. However, since they
> > are currently still being modified quite heavilly,
they haven't been
> > copied back into the MatPLC roject. However, this
code already exists,
> > and already works. All under GPL v2.
>
> Cool!
>
> Jiri:
> > > There's no "in principle" reason an
IEC 61131-3 interpreter wouldn't
> > > work, it just hasn't been written yet. The
compiler is modular, so
> > > possibly it could be extended to do this (by
creating a "code
> > > generation" phase that simply executes
the program instead of
> > > generating code for it).
> > >
> > > Mario? What do you think?
>
> ...
>
> >  Howerver, producing code that will be interpreted
later either means
> > also writing the interpreter, or using an existing
interpreter.
>
> I was thinking of making the Stage 4 execute the
program directly. Just do
> it, as they say in footwear advertisements. If you can
generate the code,
> you should be able to run it instead... (though I'm not
familiar with the
> internals, so maybe it would be more difficult than
that).
>


 I had never thought of that. 

 I guess it could probably be done, but execution would be
terribly slow.

 Implementing anything that requires a jump would probably
not be very 
eficient (the code is stored as a syntax tree at this
stage!), including 
loops in ST, etc... 

 Function and Function Block calls of the style
res := PID(in := in_var; out => out_var; P := 5);
 (i.e. in which the order of the parameters being passed is
not necessarily 
the order in which they were declared in the function
prototype, and some 
parameters are left to their default values, which may have
been defined in a 
definition of a user defined data type)
 would also be terribly ineficient.


 Probably not a good idea to spend time writing something
that will never be 
much good in terms of efficiency.


 Mind you, I am not a computer scientist (merely an
electrical engineer), so I 
could be missing something here. For example, I have no idea
how python 
interpreter is implemented.


 Cheers,

		Mario.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

Hello,

Jiri:
> > I was thinking of making the Stage 4 execute the
program directly. Just
> > do it, as they say in footwear advertisements. If
you can generate the
> > code, you should be able to run it instead...
(though I'm not familiar
> > with the internals, so maybe it would be more
difficult than that).

Mario:
>  I guess it could probably be done, but execution would
be terribly slow.

Hmm, that wouldn't be good...

>  Implementing anything that requires a jump would
probably not be very
> eficient (the code is stored as a syntax tree at this
stage!), including
> loops in ST, etc...

Well, you could construct an index of the jump labels and/or
put pointers into 
each jump pointing to the destination elsewhere in the tree.
The latter would 
require careful design so as not to end up with a spaghetti
data structure...

Similar optimisations could probably be done in other cases
(like the function 
calls you mention), and some of them might even help with
compilation, for 
optimisation of the emitted code and/or to speed up
compilation; but I don't 
know to what extent it would actually end up efficient for
interpretation.

>  Probably not a good idea to spend time writing
something that will never
> be much good in terms of efficiency.

Probably not, no. Although these days computers are pretty
fast, so unless 
it's *very* inefficient, it may still be useful. Also, once
it works, we can 
check with a profiler how to make it work fast, use that to
decide what to 
cache and/or pre-compute (as the above jump destinations).


Jiri
-- 
Jiri Baum <jiribaum.com.au>                   http://www.baum.com.au/~
jiri

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

Hi everyone,

Thanks for your quick responses and sorry my late reply. I
was out of 
the office to take care of a problem in one of the
customers.

Mario asked if our project is related with EMC. And if I can
contribute 
my time.
No, we are not related with EMC project. Infact, I only
checked it now. 
It seems a good one.
Due to our project's timing constraints, I don't want to
spend too much 
time. But I'd be happy if I can improve some (relatively
small 
) parts.

As I see, there is no ready to use interpreter. It has to be
developed 
and this can take some time.
I think I should stick with good old (and fast) C for now.

I'm planning to begin only with IEC compiler.
I think graphical editor is not ready to deploy to the
field. But as far 
as I understand, people in beremiz did a great job on
improving Mario's 
compiler and it's ready for field usage. Therefore I'll tell
the 
customers to write in ST or LD. Then this program will be
compiled to C. 
And then compiled to run on the target machine. I'll start
writing an 
interface once I understand the IO etc. definitions and
usage from this 
C code.
When graphical editors are ready too, it will be a seemless
transition 
from text only to a powerful graphical interface.

I donwloaded IEC compiler, beremiz itself and PlcOPEN editor
from 
Beremiz web page. But could'nt manage to run them. Is there
a quick 
start text? I'm a complete stranger for python.

Readme file in the IEC compiler directory suggests it's not
been updated 
since 2003. Is this the final improved compiler?
Are there any more documentation?

Best regards,
Oguz.


Edouard TISSERANT wrote:

> Dear Oguz,
>
>>> My main questions are as follows,
>>> - Can MatPLC be used in a such a commercial
project?
>>> - Licence issues ?
>>>     
>>
> Generated code is your own proprietary code with your
license. Runtime 
> libraries are LGPLv2 and GUI and development tools are
GPLv2.
>
> For runtime part, this mean you can statically link
SoftPLC and 
> necessary runtime libraries with your proprietary
existing code.
>
> GUI and development tools are either python modules,
dynamic libraries 
> or compiler, and 'statically linking' with proprietary
code have no 
> sense here.
>
>>> - Reliability ?
>>>     
>>
> Once first beta version available for the whole Beremiz
toolchain, we 
> will change our version control policy. At the same
time automated 
> regression tests will be set with our 'favorite'
hardware. Only the 
> code that pass all tests successfully will be
released.
>
> We also plan to pass most certifications available for
the standard we 
> implement : IEC-61131, PLCOpen, and CanOpen. Those
certifications are 
> very expensive, and we will need community contribution
for this.
>
>>> - References of other commercial projects ?
>>>     
>>
> Nothing official at that time for the Beremiz project.
You are welcome.
>
>>> - It may be better if the final PLC program is
run in an 
>>> interpreter. So
>>> we could avoid cross compile issues.
>>>     
>>
> You still have to cross compile your interpreter 
>
> IEC to C compiler works in a similar way the GCC works.
C-Code 
> generator is one of the backends. Another existing
backend is the IEC 
> code generator (iec2iec, made for test/debug purpose).
>
> Generating byte code is possible, not necessarily using
a JVM. It 
> could be possible to generate a byte code similar to
the one that 
> Siemens or 3S use.
>
> Writing a new code generator for the IEC compiler is
rather long, and 
> also imply a partial rewrite of the "IEC standard
function block 
> library" that become part of the interpreter in
the case of byte code. 
> I estimate this to max 0.5 man-year.
>
> Regards
>
> Edouard.
>
>
>


-- 
Oguz Dilmac
ARGE Bolumu

Bilko AS, R&D Department
====================================
Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2568
TR-34384 Okmeydani Istanbul Turkey
Tel : +90 212 220 07 40  Fax :   +90 212 210 47 01
e-mail : odilmacbilko-automation.com
web site : http://www.bilko-auto
mation.com



------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

Hi Oguz
> Due to our project's timing constraints, I don't want
to spend too 
> much time. But I'd be happy if I can improve some
(relatively small  
> ) parts.
Be assured that simply using those tools is a kind of
contribution :
- you will certainly help us to find bugs (sorry.)
- using those tools in your real world products gives
credibility to our 
project

You can also contribute donating or paying Lolitech for
training, 
support or specific developments. Be sure that the project
will really 
benefit from your investment.
> As I see, there is no ready to use interpreter. It has
to be developed 
> and this can take some time.
> I think I should stick with good old (and fast) C for
now.
As soon as your micro-controller can be targeted by a C
compiler you can 
redistribute, this should not be a problem.
> I'm planning to begin only with IEC compiler.
> I think graphical editor is not ready to deploy to the
field. But as 
> far as I understand, people in beremiz did a great job
on improving 
> Mario's compiler and it's ready for field usage.
Therefore I'll tell 
> the customers to write in ST or LD.
Do you mean ST and IL ?
> Then this program will be compiled to C. And then
compiled to run on 
> the target machine. I'll start writing an interface
once I understand 
> the IO etc. definitions and usage from this C code.
> When graphical editors are ready too, it will be a
seemless transition 
> from text only to a powerful graphical interface.
I think you could immediately reuse at least one part of the
PLCOpen 
Editor : the ST/IL text editor with syntax highlighting and

auto-completion.  It is rather stable and usable at this
time.

It is really easy to build a simple text editor based on
plcopeneditor 
python code. It looks like :
------------------------------
from TextViewer import TextViewer
from plcopen.structures import IEC_KEYWORDS

def ShowSTEditor():
        plc_file = "my_file.ST"
        new_dialog = wx.Frame(None)
        ST_viewer = TextViewer(new_dialog, None, None)
        ST_viewer.SetKeywords(IEC_KEYWORDS)
        text = file(plc_file).read()
        ST_viewer.SetText(text)
------------------------------

That's it ! (in that case, auto-completion do not work)

Another way to do would be to do a branch development of the
PLCOpen 
editor with graphical languages disabled. This way, your
users would 
also benefit from easy variable declaration, and PLCopen
format storage.
> I donwloaded IEC compiler, beremiz itself and PlcOPEN
editor from 
> Beremiz web page. But could'nt manage to run them. Is
there a quick 
> start text? I'm a complete stranger for python.
Beremiz is currently broken. It will be more stable next
week.

To run PLCOpen Editor, you must have python >= 2.4, and
wxPython >= 
2.6.3 && < 2.8 installed on your system
Simply run :
# cd plcopeneditor
# python PLCOpenEditor.py
Or to open the example directly :
# cd plcopeneditor
# python PLCOpenEditor.py examples/example.xml

To compile the iec2c compiler,
# cd matiec
# make

To test and run some generated code:
# cd plcopeneditor
# python PLCOpenEditor.py ../matiec/tests/STD_TEST.xml
This opens a standard library test. Please click on 
"File/Generate-program" and save as
../matiec/tests/STD_TEST.st
Now, let build a sample program that do just print located
variables on 
each PLC cycle (see matiec/tests/main.c)
# cd ../matiec/tests
# ./build.sh STD_TEST.st
Then you can run the generated test executable
# ./test
>
> Readme file in the IEC compiler directory suggests it's
not been 
> updated since 2003. Is this the final improved
compiler?
Yes this is the improved compiler. Readme file is the only
that have not 
been updated 
> Are there any more documentation?
At that time, the only way to get informed about the project
is to read 
code, or ask development team.

I'm pretty sure we can provide some of the logical bricks
you need, and 
we can help you to adapt them to your precise needs.
Planning a meeting 
would have sense. What is your project deadline ?

Regards

Edouard

-- 
LOLITech - TBI sarl
24, rue Pierre Evrat
88100 Saint-Dié des Vosges
tel: 03 29 52 95 67
fax: 03 29 58 93 16
edouard.tisserantlolitech.fr
<mailto:edouard.tisserantlolitech.fr>
http://www.lolitech.fr
	<http://www.lolitech.fr>



------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

Edouard TISSERANT wrote:

> Hi Oguz
>
>> Due to our project's timing constraints, I don't
want to spend too 
>> much time. But I'd be happy if I can improve some
(relatively small 
>>  ) parts.
>
> Be assured that simply using those tools is a kind of
contribution :
> - you will certainly help us to find bugs (sorry.)
> - using those tools in your real world products gives
credibility to 
> our project
>
> You can also contribute donating or paying Lolitech for
training, 
> support or specific developments. Be sure that the
project will really 
> benefit from your investment.
>
>> As I see, there is no ready to use interpreter. It
has to be 
>> developed and this can take some time.
>> I think I should stick with good old (and fast) C
for now.
>
> As soon as your micro-controller can be targeted by a C
compiler you 
> can redistribute, this should not be a problem.

We have two target systems. The first is an industrial PC
running 
RTLinux patched Linux, and the second is an ARM9 board
running RTAI 
patched Linux. C compiler is not a huge problem.

>> I'm planning to begin only with IEC compiler.
>> I think graphical editor is not ready to deploy to
the field. But as 
>> far as I understand, people in beremiz did a great
job on improving 
>> Mario's compiler and it's ready for field usage.
Therefore I'll tell 
>> the customers to write in ST or LD.
>
> Do you mean ST and IL ?

Sorry, you are right. Text based, Structured Text and
Instruction List 
languages. Probably ST will be used.

>> Then this program will be compiled to C. And then
compiled to run on 
>> the target machine. I'll start writing an interface
once I understand 
>> the IO etc. definitions and usage from this C
code.
>> When graphical editors are ready too, it will be a
seemless 
>> transition from text only to a powerful graphical
interface.
>
> I think you could immediately reuse at least one part
of the PLCOpen 
> Editor : the ST/IL text editor with syntax highlighting
and 
> auto-completion.  It is rather stable and usable at
this time.
>
> It is really easy to build a simple text editor based
on plcopeneditor 
> python code. It looks like :
> ------------------------------
> from TextViewer import TextViewer
> from plcopen.structures import IEC_KEYWORDS
>
> def ShowSTEditor():
>        plc_file = "my_file.ST"
>        new_dialog = wx.Frame(None)
>        ST_viewer = TextViewer(new_dialog, None, None)
>        ST_viewer.SetKeywords(IEC_KEYWORDS)
>        text = file(plc_file).read()
>        ST_viewer.SetText(text)
> ------------------------------
>
> That's it ! (in that case, auto-completion do not
work)


I'll try this.

>
> Another way to do would be to do a branch development
of the PLCOpen 
> editor with graphical languages disabled. This way,
your users would 
> also benefit from easy variable declaration, and
PLCopen format storage.
>
>> I donwloaded IEC compiler, beremiz itself and
PlcOPEN editor from 
>> Beremiz web page. But could'nt manage to run them.
Is there a quick 
>> start text? I'm a complete stranger for python.
>
> Beremiz is currently broken. It will be more stable
next week.
>
> To run PLCOpen Editor, you must have python >= 2.4,
and wxPython >= 
> 2.6.3 && < 2.8 installed on your system

I downloaded Python 2.5.1 but didn't aware of wxPython. I'll
look for it 
too.

> Simply run :
> # cd plcopeneditor
> # python PLCOpenEditor.py
> Or to open the example directly :
> # cd plcopeneditor
> # python PLCOpenEditor.py examples/example.xml
>
> To compile the iec2c compiler,
> # cd matiec
> # make
>
> To test and run some generated code:
> # cd plcopeneditor
> # python PLCOpenEditor.py ../matiec/tests/STD_TEST.xml
> This opens a standard library test. Please click on 
> "File/Generate-program" and save as
../matiec/tests/STD_TEST.st
> Now, let build a sample program that do just print
located variables 
> on each PLC cycle (see matiec/tests/main.c)
> # cd ../matiec/tests
> # ./build.sh STD_TEST.st
> Then you can run the generated test executable
> # ./test
>
>>
>> Readme file in the IEC compiler directory suggests
it's not been 
>> updated since 2003. Is this the final improved
compiler?
>
> Yes this is the improved compiler. Readme file is the
only that have 
> not been updated 
>
>> Are there any more documentation?
>
> At that time, the only way to get informed about the
project is to 
> read code, or ask development team.
>
> I'm pretty sure we can provide some of the logical
bricks you need, 
> and we can help you to adapt them to your precise
needs. Planning a 
> meeting would have sense. What is your project deadline
?
>
I have almost one month. It should be better finished at the
8th of 
october. Graphic languages may follow later.

Initially, I was thinking of letting the customer to write
their own C 
coded tasks and giving them an interface for accessing our
IO boards and 
variables. But the giving the ability of coding in a
standart PLC way 
seems more attractive.

Probably I wont have enough time to travel to France but
I'll talk to my 
boss. May be he can have that time.

Thanks for valuable info, I'll try to use these.
Best regards,
Oguz.

> Regards
>
> Edouard
>


-- 
Oguz Dilmac
ARGE Bolumu

Bilko AS, R&D Department
====================================
Perpa Ticaret Merkezi B Blok Kat 13 Nr. 2568
TR-34384 Okmeydani Istanbul Turkey
Tel : +90 212 220 07 40  Fax :   +90 212 210 47 01
e-mail : odilmacbilko-automation.com
web site : http://www.bilko-auto
mation.com



------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel

Hi MatPLC developers, 

Recently, I was browse the MatPLC website more carefully and
I found that 
the compatible IO Board is a device called Advantech
pcl812pg. 

My question is where I can find this Board? 

Thanks for all your help 


c u 

bye

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MAT-devel mailing list
MAT-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mat-devel