[Embedlets-developer] RE: VBB and PLC's

[Andrzej J. T. <an...@ch...>]

James responds:

> Good to see you back in form Andrzej

I do try! <grins>

> 1) I totally agree that a XML backend is what we are after. And that any
> graphical viewer is just a visualiser for that XML. 

Great minds think alike.  Or is that "fools seldome differ"? ;-)

> I would like to keep the XML as simple as we can to begin and
> grow it upwards from there but if we can come up with the rich version up
> front then I am happy with this also. 

I believe it should be kept as simple as possible as well, but I do think that it 
will become rather complex pretty quickly so we might as well be prepared for 
that.

< as a group we seem better at theory and abstraction than
> hands on application. SO the thinking was to keep it simple as possible
> and move upwards.

Not quite....just haven't fleshed out enough of the abstraction to start pumping 
code yet.

> 2) I don't agree about the PLC as 'not important' are you kidding? It is
> probably the biggest field of embedded engineering out there!? However I
> think there has been a little confusion, I am not suggesting PLC's run
> embeddlets - actually I am suggesting the other way around, that embedlets
> can run PLC code. 

OK...I misunderstood your comment.  This makes sense. There is no reason 
that an Embedlet couldn't be written to implement Ladder Logic (or any other 
language for that matter, but given the constraints of embedded devices, I 
doubt that an embedded script language interpreter makes much sense).

> Specifically, I want a Ladder Logic ==> Embedlets.xml
> translator so that java devices running the embedlets framework can run
> PLC code. 

This won't work.  The embedlets XML file will likely be just a config file that 
specifies the context for the embedlet component, and it's linkages (which 
events it consumes/produces, what JAPL device it talks to and the like).  The 
"application logic" of the embedlet would be written in Java.  So what you 
would need is a code generator that can read PLC code and generate Java 
code inside an Embedlet context.

> 3) Yes, I am considering making VBB 'open source' It has alot to offer,
> openVBB is pretty much an implementation of the Outpost like Container. It
> uses a java backend with most of what we have been talking about with java
> objects created by reflection and an event driven SignalProducer/Consumer
> wiring model which can handle both synchronous(clocked) and
> aysnchronous(change-response) logic operators and has a XML-SVG component
> representation to boot.

I don't have a problem with building the Graphical Construction tool using 
different technology than Java.  VB can be useful for such stuff, though 
introducing a second technology (besides Java) makes the project more 
complex and harder to staff up.

> 4) No the standard and reference implementation will be open source. I
> think there will be many commercial implementations of the standard and
> don't have a problem with that. Not all TCP/IP stacks are opensource yet
> they implement a standard!

True enough...though I think that we will end up with "real" Outpost containers 
for different platforms that are all open source and useable in a production 
environment (not just RI's).

I have no problem with people building commercial implementations based on 
the Outpost/Embedlet standard.  But that might be a while...we'ld need to see 
some decent adoption of the standard and the initial containers before much 
commercial activity began.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com