Netmaster PLC and FBDK

[rach...@gmail.com]

Hi for all
I am trying to create simple java application with FBDK to upload it
in a Netmaster PLC.

The application is very easy (send a data from PC to the PLC and
receive it again), at this moment, it is just to learn how we can make
this application.

I made this application between tow PC as a system application. As I
know the system configuration cannot be saved as a java.

Can somebody suggest me how can I start making this application?
I would welcome any advice you can give me.

Regards

Rachid

[christian]

Download via ftp the fbrt.jar to the netmaster device.

- Btw. a netmaster is not a PLC. It's an embedded java controller.

execute via telnet:
java -classpath lib-files -r -w fb.rt.RMT_DEV -p packages to add -s
61499 &
-r ... restart the java virtual machine
-w ....
-s ... socket
-& ... return to command line

e.g.
java -classpath fbrt_new.jar:elsist.jar:adp.jar:Handhaben.jar:enas.jar
-r -w fb.rt.RMT_DEV -p
events;net;elsist;math;Handhaben;adp;lsAUT;Enas; -s 61499 &


Kind regards,
Christian

[Eccles]

Hi Christian and all,

I see that there are SNAP and TStik versions of the Netmaster.

1. Apart from the obvious differences in processor and memory, is
there a clear chocie between the two for the purpose of experimenting
with FBDK?

2. The web page <http://www.jstik.com/compare.htm> list a number of
embedded Java products. Does anyone have experience with any of the
"high-performance" products running FBRT?

Kind regards,
Neil

[Jim Christensen]

Based on my experience with both processors (but not with Netmaster
per se), I would recommend SNAP. It's faster and closer to standard
(CLDC) Java runtimes than TINI. I'd still be prototyping with SNAPs,
but I fried both of mine a couple of years ago with a bad power supply
regulator. You probably won't have that problem with Netmaster.

I don't know whether the current version of fbrt,jar will work with
Netmaster; you would certainly want to strip out the fb.rt.hmi
classes, plus some of the other special-purpose packages such as
fb.rt.mach, fb.rt.mva, etc. Plus you would need SIFBs to interface to
the Netmaster's I/O APIs.
- Jim C

[Jim Christensen]

For Netmaster SIFBs, see http://www.eit.uni-kl.de/frey/papers/PDF/TR012004.pdf
.
- Jim C

On Nov 8, 10:29 am, Jim Christensen <james.h.christen...@gmail.com>
wrote:

[James Caska]

So, its seems there really is nothing out there that can run the (rockwell) fbrt on an embedded platform without considerable work and since this is not an open-source runtime it is very hard to port.

 

In the http://www.holobloc.com/papers/kitara07.pdf page 3 there is a lovely picture of the 'The Industrial Automation Value-Add Chain' Its' a stack from Device Vendors (level1), Machine Vendors(level2), System Integrators(level3), Industrial Enterprises(level4). The FBRT is sort of level3,level4 from what I can tell.

 

I consider myself a Device Vendor, level1, and I want to implement a FBRT

 

I have

- A java enabled micro

- A TCP/IP Stack

- A suite of tools to help me

 

BUT! I want to bootstrap myself because there is so much terminology flying around and especially the use of 'C' type naming conventions is driving me crazy - RMT_DEV , SIFBs, .. what does it mean. How about SpecialInterfaceFunctionBlock etc so I can figure out what I am talking about.

 

I want to do an absolute minimum implementation of a FBRT and build from there. Firstly, is this the right place for this conversion?

 

Unlike the fbrt which pretty much only talks to itself, my primary concern is to put an embedded fbrt into the remote device and attach it to other implementations, like the fbrt. So I need to be able to export the external function block interface in a way that other function block platforms can understand. I also need to be able to implement the minimum communication external facing function block.

 

So take my earlier example of a light. I would have the external function block interface with ON/OFF and the internal SIFB that can switch a port. OK, so say I implement this external function block interface as a Server, what steps should I take to be able to turn off the light from FBDK. One way is to use the FBDK to implement the matching CLIENT and manually enter the IP Address and functions manually. Another way is to generate some compatible XML from my tool that can imported into FBDK. The ideal way would be to point to the IP address of my device and get back a function block in FBDK automatically.

 

From what I can tell, when it boils down to it from an external point of view, 61499, is really just a packet formatting protocol for exchanging typed data and events but I haven't dug deep enough to figure out how it all fits toghether.

 

Any suggestions on the steps forward for creating a minimum fbrt that can interoperate with higher levels ie fbdk and other 61499 tools?

 

Cheers,

James

 

 

 

 

 

---

From: Jim Christensen <james.h.c...@gmail.com>
To: FBDK <fb...@googlegroups.com>
Sent: Saturday, November 8, 2008 4:29:45 PM
Subject: Re: Netmaster PLC and FBDK

[christian]

Have a look at the following article

Design and Implementation of Heterogeneous Distributed Controllers
According to the IEC 61499 Standard - A Case Study
Hirsch, M.; Gerber, C.; Hanisch, H.-M.; Vyatkin, V.
Industrial Informatics, 2007 5th IEEE International Conference on
Volume 2, Issue , 23-27 June 2007 Page(s):829 - 834
Digital Object Identifier 10.1109/INDIN.2007.4384881
Summary:This paper addresses solutions on integration and reuse of
heterogeneous distributed controllers. In particular it shows the way
to integrate the emerging IEC 61499 standard into the established IEC
61131 automation frameworks. It is illustrated on example of a modular
manufacturing cell with distributed control units, how to realize
distribution of heterogeneous controllers using the IEC 61499 standard
and how to integrate these controllers into the plant formerly
controlled by distributed PLCs. Therefore, methodologies and patterns
for the design of distributed controllers and their implementation
variants are introduced. In addition, the paper describes the details
of a higher level communication protocol used to implement interaction
between the modules. A framework for the simulation of IEC 61499
applications is also introduced.

Furthermore, you fill find inside the book of Vyatkin, V. a chapter
about creating and implementing SIFB for netmaster. This approach is a
bit old-fashioned and has to be updated to the new
NSystI2cHardwareAccess.class provided by Elsist. It's a trivial task
if you read carefully the article, the book chapter and the
dokumentation of the given java class.

Kind regards,
Christian

[Eccles]

As always, Christian, you are a gold mine of information. Thank you!

Incidentally, I have been chatting with Imsys, and they have a really
cool new Java OEM module - just a processor and switching power
convertor on a mezanine board with a socket underneath. I have asked
the sales rep if he knows if it is capable of running FRBT. Stay
tuned.

NH

[James Caska]

Yes, thanks Christian. Looks like I need that book.

 

If I get this figured out I will be releasing a muvium based module, single chip java enabled PIC18F97J60 ethernet device with Ethernet JACK + power over ethernet option. This I already have, I just want to add a FB runtime to allow it embed function blocks. Will be cool.

 

Cheers,

James

 

---

From: Eccles <higgins...@bigpond.com>
To: FBDK <fb...@googlegroups.com>
Sent: Tuesday, November 11, 2008 11:56:21 AM
Subject: Re: Embedded Runtime

[Eccles]

Hi James,

Java enablement of the hardware will not solve all your problems in
one fell swoop. I don't know much about the muvium module or the
PIC18F97J60 platforms, but at first sight, they look a bit too
lightweight for non-trivial commercial applications.

Although FBDK is a great tool for experimentation and proofs of
concept, the associated licence restrictions and tool limitations make
it problematic for commercial applications (although I understand this
has been done, at least in one case). Implementing it on any platform
will (IMHO) require you to become intimately familiar with the "under
the bonnet" implementation requirements, as described in the Standard.

You are right that from an external point of view, it's about
understanding the packet contents and interchanges (this, after all,
is the definition of protocol compliance). IEC 61499 doesn't actually
standardise these, although there is (to my knowledge) only one
"profile" in general use, namely the "Compliance Profile for
Feasibility Demonstrations" published at www.holobloc.com. This says
quite a lot about the maturity and acceptance of IEC 61499 in the
marketplace - it's early days yet.

Having said all that, if you are successful in your endeavours, please
let us know ... I (and I'm sure many others too) would revel in having
access to a truly economical, bare-bones IEC 61499 platform.

Incidentally, have you looked at the open source IEC 61499 runtime at
www.fordiac.org, or the commercial IsaGraf libraries from ICS
Triplex?

Kind regards,
Neil

On Nov 11, 10:54 pm, James Caska <jamesca...@yahoo.com.au> wrote:
> Yes, thanks Christian. Looks like I need that book.
>
> If I get this figured out I will be releasing a muvium based module, single chip java enabled PIC18F97J60 ethernet device with Ethernet JACK + power over ethernet option. This I already have, I just want to add a FB runtime to allow it embed function blocks. Will be cool.
>
> Cheers,
> James
>
>  
>
> ________________________________

> From: Eccles <higgins-dem...@bigpond.com>

> > Christian- Hide quoted text -
>
> - Show quoted text -

[James Caska]

Neil,

 

IEC 61499 is in a chicken before the egg or egg before the chicken paradox. I can see very clearly that it is truly very early days for the standard. This is highlighted by the last few emails discussing just how difficult it is to deploy the fbdk on existing platforms.  I think the FBDK is causing some confusion in this area as it is being position 'as 61499' when its just one way of doing it. Rockwells licensing limitations make it very difficult to move it forward.

 

>"under the bonnet" implementation requirements,

 

I am the author of the muvium ahead of time compiler, www.muvium.com, and virtualbreadboard simulation, www.virtualbreadboard.com products. The TCP/IP stack i have developed in java to support 18F97J60 ( <$4 ) and RealTek NIC and others. I think you would be very suprised with what can be done :-) 

 

In any case I have my eye on 'smart sensors/actuators' making it cost effective to bundle function block capabilities directly into the endpoints effectively bypassing the PLC and connecting them all to a PC based FBRT. Won't work for every single application due to the communication overhead that some bespoke plc busses are faster for, but it will work for many others. So literally I want to put the functionblock into the light :-) Hence this reduces the demands on individual function block processors and creates a more fully distributed system.

 

>Incidentally, have you looked at the open source IEC 61499 runtime at
>www.fordiac.org, or the commercial IsaGraf libraries from ICS

 

Not yet, building a todo list - read book, review open source libraries,... I think though what I am shooting for is not a fully compliant system but a very narrow compliance based on the communications protocols I want to support for achieving my goal. 'conditional compliance?'' I have been using wireshark to review the TCP/IP/UDB packets from the FBDK and its doesn't seem all complex at least from that perspective.  I am trying to boil it all down to the simplest terms ( so I can understand them LOL )

 

I can certainly implement the packet protocols but the broader challenge is how to I plug my smart devices into the PC IEC 61499 runtimes like the FBRT. This is why I have asked questions like a WebService Disco discovery mechanism. BTW. It may exist - and i will find out when I read the book but thats what I really want. That is, I want to be able to have a discovery port on my devices which publish a XML capabilities description that can be rendered as a function block. Then you could do simple things like scan a range of IP addresses pinging the discovery port to get back all the available function block interfaces and then start wiring them up.

 

Will keep you informed

 

Cheers,

James

 

 

 

---

From: Eccles <higgins...@bigpond.com>
To: FBDK <fb...@googlegroups.com>

Sent: Wednesday, November 12, 2008 3:51:02 AM
Subject: Re: Embedded Runtime

[Eccles]

( Blush! )Well, uh ... what can I say ... "Well done" on your
achievements to date, and keep going!

Please, please do keep us informed.

Cheers,
Neil

On Nov 12, 6:07 pm, James Caska <jamesca...@yahoo.com.au> wrote:
> Neil,
>
> IEC 61499 is in a chicken before the egg or egg before the chicken paradox. I can see very clearly that it is truly very early days for the standard. This is highlighted by the last few emails discussing just how difficult it is to deploy the fbdk on existing platforms. I think the FBDK is causing some confusion in this area as it is being position 'as 61499' when its just one way of doing it. Rockwells licensing limitations make it very difficult to move it forward.
>
> >"under the bonnet" implementation requirements,
>

> I am the author of the muvium ahead of time compiler,www.muvium.com, and virtualbreadboard simulation,www.virtualbreadboard.comproducts. The TCP/IP stack i have developed in java to support 18F97J60 ( <$4 ) and RealTek NIC and others. I think you would be very suprised with what can be done :-)

>
> In any case I have my eye on 'smart sensors/actuators' making it cost effective to bundle function block capabilities directly into the endpoints effectively bypassing the PLC and connecting them all to a PC based FBRT. Won't work for every single application due to the communication overhead that some bespoke plc busses are faster for, but it will work for many others. So literally I want to put the functionblock into the light :-) Hence this reduces the demands on individual function block processors and creates a more fully distributed system.
>
> >Incidentally, have you looked at the open source IEC 61499 runtime at
> >www.fordiac.org, or the commercial IsaGraf libraries from ICS
>
> Not yet, building a todo list - read book, review open source libraries,... I think though what I am shooting for is not a fully compliant system but a very narrow compliance based on the communications protocols I want to support for achieving my goal. 'conditional compliance?'' I have been using wireshark to review the TCP/IP/UDB packets from the FBDK and its doesn't seem all complex at least from that perspective. I am trying to boil it all down to the simplest terms ( so I can understand them LOL )
>
> I can certainly implement the packet protocols but the broader challenge is how to I plug my smart devices into the PC IEC 61499 runtimes like the FBRT. This is why I have asked questions like a WebService Disco discovery mechanism. BTW. It may exist - and i will find out when I read the book but thats what I really want. That is, I want to be able to have a discovery port on my devices which publish a XML capabilities description that can be rendered as a function block. Then you could do simple things like scan a range of IP addresses pinging the discovery port to get back all the available function block interfaces and then start wiring them up.
>
> Will keep you informed
>
> Cheers,
> James
>
>
>
> ________________________________

> From: Eccles <higgins-dem...@bigpond.com>
> To: FBDK <fb...@googlegroups.com>

> Sent: Wednesday, November 12, 2008 3:51:02 AM
> Subject: Re: Embedded Runtime
>
> Hi James,
>
> Java enablement of the hardware will not solve all your problems in
> one fell swoop. I don't know much about the muvium module or the
> PIC18F97J60 platforms, but at first sight, they look a bit too
> lightweight for non-trivial commercial applications.
>
> Although FBDK is a great tool for experimentation and proofs of
> concept, the associated licence restrictions and tool limitations make
> it problematic for commercial applications (although I understand this
> has been done, at least in one case). Implementing it on any platform
> will (IMHO) require you to become intimately familiar with the "under
> the bonnet" implementation requirements, as described in the Standard.
>
> You are right that from an external point of view, it's about
> understanding the packet contents and interchanges (this, after all,
> is the definition of protocol compliance). IEC 61499 doesn't actually
> standardise these, although there is (to my knowledge) only one
> "profile" in general use, namely the "Compliance Profile for

> Feasibility Demonstrations" published atwww.holobloc.com. This says

> quite a lot about the maturity and acceptance of IEC 61499 in the
> marketplace - it's early days yet.
>
> Having said all that, if you are successful in your endeavours, please
> let us know ... I (and I'm sure many others too) would revel in having
> access to a truly economical, bare-bones IEC 61499 platform.
>

> Incidentally, have you looked at the open source IEC 61499 runtime atwww.fordiac.org, or the commercial IsaGraf libraries from ICS

[Alois]

Hi,

>
> Not yet, building a todo list - read book, review open source libraries,... I think though what I am shooting for is not a fully compliant system but a very narrow compliance based on the communications protocols I want to support for achieving my goal. 'conditional compliance?'' I have been using wireshark to review the TCP/IP/UDB packets from the FBDK and its doesn't seem all complex at least from that perspective.  I am trying to boil it all down to the simplest terms ( so I can understand them LOL )

I would recommend to read the compliance profile for feasibility
demonstrations there the TCP UDP packets and format is explained. Much
easier than to use wireshark :-)


By the way. The first comercial applications are running based on
4DIAC (www.fordiac.org) done by the company nxtControl. If you have
time and are "near" the German city Nuremberg you might want to come
to the SPS/IPC/DRIVES trade fair. This is the biggest trade fair on
PLCs and related technology. in Hall 7A Booth 416 you will find
nxtControl and one part of the nxtControl Boot is reserved for 4DIAC
where Profactor and ACIN (myself) will show and explain this open
source initiative. Looking forward to see you their and have
interesting discussions.

Alois

[James Caska]

HI,

 

>I would recommend to read the compliance profile for feasibility
>demonstrations there the TCP UDP packets and format is explained. Much
>easier than to use wireshark :-)

 

I agree - thats what I am after but I couldn't find it easily so I just peeked at the packets :-)

 

> (www.fordiac.org) done by the company nxtControl.

 

I had a look at the website earlier but couldn't find any actual hardware.spec's , how to buy etc. Maybe I am just not looking very hard

>If you have time and are "near" the German city Nuremberg

 

I am Australian but I reside in the netherlands right now so this not impossible. What are the dates? Do you have a link for details, location etc.

 

Thanks!

James

 

---

From: Alois <al...@gmx.at>
To: FBDK <fb...@googlegroups.com>
Sent: Wednesday, November 12, 2008 12:37:48 PM
Subject: Re: Embedded Runtime

[James Caska]

 >Incidentally, have you looked at the open source IEC 61499 runtime at
 >www.fordiac.org, or the commercial IsaGraf libraries from ICS

Ok, so having had a quick look at this implementation this is basically what I expected to have to implement except in java. So that may be a good head start.

 

I see you Alois as one of the Authors of this implementation. Is there a seperate list for commenting on the forte runtime implementation?

 

Cheers,

James

---

From: Alois <al...@gmx.at>
To: FBDK <fb...@googlegroups.com>

Sent: Wednesday, November 12, 2008 12:37:48 PM
Subject: Re: Embedded Runtime

[Alois]

Hi,

> I had a look at the website earlier but couldn't find any actual hardware.spec's , how to buy etc. Maybe I am just not looking very hard

4DIAC is open source so nothing you need to buy. you can use it side
by side with FBRT and FBDK if you wish so.

> I am Australian but I reside in the netherlands right now so this not impossible. What are the dates? Do you have a link for details, location etc.

The fair is from Nov. 25th to Nov. 27th. Here you can find more
details on the location and the dates: http://www.mesago.de/en/SPS/main.htm

AFAIK ISaGRAF will also be there.

Alois

[Alois]

Hi,

first of all sorry Jim for cross-posting here on 4DIAC as a user of
both I thought people could be interested in also 4DIAC.

> I see you Alois as one of the Authors of this implementation. Is there a seperate list for commenting on the forte runtime implementation?

At the 4DIAC page there are Forums for discussions, questions, bug
reports, feature requests etc.

So please direct your questions on 4DIAC there.

Best Regards,
Alois

[christian]

btw. you can find the Martin-Luther-University at Hall 8

Hall 8 - 629

Kind regards,
Christian

[James Christensen]

No problems with a little 4DIAC here. Anything that increases use of
61499 is good for FBDK. Any inputs on other tools or runtimes also
welcome.
--
Best regards,
Jim Christensen

[Eccles]

If I might continue the off-FBDK discussion a little longer (the 4DIAC
forums do not appear to be very active).

Alois: I am trying to understand the choice of ARM7 as one of the
first supported platforms for FORTE. Everything about ARM7 says
"big" (architecturally). If you look around for ARM modules for
embedded control, there's not much on offer. Modules that are
available seem to target consumer applications, not control.

I was expecting the target to be something much more focussed on price/
performance, such as Atmel AVR32 or even just AVR (I still think the
PIC is underdone, although maybe that's just a personal bias, having
been tormented by its segmented memory/no stack architecture).

I can understand why a "big" processor might be seen as desirable for
a Java-based implementation, but what size does a processor have to
be, and what minimal OS services are required, to support a native
implementation like FORTE?

On Nov 14, 12:45 am, "James Christensen"

> > Alois- Hide quoted text -

[Alois]

Hi,

On Nov 19, 2:01 am, Eccles <higgins-dem...@bigpond.com> wrote:
> If I might continue the off-FBDK discussion a little longer (the 4DIAC
> forums do not appear to be very active).

This is exactly the reason why they are not active :-) The 4DIAC
forums have a very fest response rate. However most people currently
working on 4DIAC are located in Austria and we work in several
projects together so we meet on a regularly basis. So a lot of the
communication is going on behind the scenes.
I would be glad if you could use the forum as this would show the
interest for it.

Regarding the arm7:
We used this one as we had it in one project and the port was done
very fast and it was stable. I have it running on smaller 16Bit
Controller (IPC@CHIP from the company Beck, which is an i186).
However, this port had to use a very old compiler which is not freely
available. It is rather hard to get it running on this controller.
Therefore we did not open source it. For the next major release (0.4)
which is planed for the beginning of next year we will add the support
for the real-time operating system eCos and as new platform the Lego
Mindstroms NXT controller (this is also an arm7).
Our current goal is to have platforms the can be used rather fast and
work nearly out of the box.

Smaller controller should be possible. In this case maybe some work is
necessary. I have a student who is working on using FORTE without an
operating system which should also be possible. However than you would
have limited real-time capabilities.

For using a full featured FORTE on a controller the operating system
should provide
* Multithreading support
* For FBDK compliant communication TCP and UDP stacks
* timer support (can be typically done in a thread if no timers are
available see for example the pc platform)

In general I would be interested in having FORTE on smaller
controllers but currently I have no controllers at hand.

Cheers
Alois

[James Caska]

>I was expecting the target to be something much more focussed on price/
performance, such as Atmel AVR32 or even just AVR (I still think the
PIC is underdone,

 

I think then you will enjoy the muvium java implementation of a 61499 runtime. Single chip ethernet 18F97J60 Microchip PIC. Actually I *use* the PIC's memeory segmentation to my advantage in my java implementation and since you are using java it doesn't matter whats under the hood.. I do like the AVR and ARM7 though and have done some work to port to these devices also.

 

I promise to report something more you can play with soon.

 

Cheers,

James

 

 

---

From: Eccles <higgins...@bigpond.com>
To: FBDK <fb...@googlegroups.com>
Sent: Wednesday, November 19, 2008 2:01:15 AM
Subject: Re: Embedded Runtime

[Eccles]

Thank you for staying so positive, James.

As a person with some hardware knowledge but sadly devoid of
programming skills, I will be delighted to be proved wrong :-)

Cheers,
Neil

[James Caska]

>As a person with some hardware knowledge but sadly devoid of

>programming skills,I will be delighted to be proved wrong  :-)

 

Perfect, what is your specific interest in 61499 - can you give an example of something you would like to apply it to.

---

From: Eccles <higgins...@bigpond.com>
To: FBDK <fb...@googlegroups.com>

Sent: Thursday, November 20, 2008 2:49:35 AM
Subject: Re: Embedded Runtime