Thread: [Embedlets-developer] Re: VBB and PLC's
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-01-26 17:07:14
|
James: > a) To use Virtual Breadboard's openVBB framework as the (free) schematic > editor of the ladder logic diagrams If we were to use this as a GUI tool for the embedlet container, would you release the source code under a suitable open source license? If there is a commercial flavour (say paid extensions) I would oppose any such use. Embedlets are supposed to be open source. What's it written in? Probably VB or C from the installation specs. I'm not sure that limiting execution to a Windows platform is a good idea, and would hesitate to use two different languages in the embedlets project. Thanks for the offer though.... Regarding PLC's: > It might be a good place for embedlets to cut their teeth I'm nervous about this. PLC's are even more limited than PIC's. I think embedlets should consider such limited devices but that the place to cut the teeth is on TStik/JStamp type controllers first. > Demonstrate how the embedlet wiring concept can be used to develop > executable ladder logic diagrams. I see very little value in this challenge, since there is a good chance that the Embedlet container will not be suitable for PLC's. More on why I think that later today.... Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Ted K. <tk...@ya...> - 2003-01-27 04:03:57
|
James and Andrzej, > Regarding PLC's: > > > It might be a good place for embedlets to cut their teeth > > I'm nervous about this. PLC's are even more limited than PIC's. I think > embedlets should consider such limited devices but that the place to cut the > teeth is on TStik/JStamp type controllers first. I think that there is an elegant synthesis here. Embedlets are software components that are suppose to encapsulate platform independent *embedded logic* and we should not care how this logic is generated. When one considers what tools can be used to develop the logic that is present inside of Embedlets, the following possibilities immediately present themselves: Embedlet logic can be developed using: 1) Java. Highly skilled Java programmers can use Java to develop Embedlet logic. An example of this would be the ElevatorSystemController and ElevatorFloorController Embedlets. These should be developed by expert programmers with an intimate understanding of the problem domain. Since these are highly engineered components they will cost much to develop but then they can be sold to anyone who is building elevators. 2) PICBASIC. For people who are not skilled Java developers there is no reason why a PICBASIC interpreter Embedlet could not be created and then people who know how to program in PICBASIC can easily develop their own Embedlet logic. If Embedlets are capable of being graphically wired together using a wiring tool then these people will not even necessarily be aware that they are using Java at all. 3) LADDER LOGIC. If Embedlet logic can be developed in PICBASIC why not allow it to also be graphically developed using LADDER LOGIC? 4) ANY TOOL THAT PEOPLE WANT TO USE... The deeper that I dig into developing a solution to the Elevator challenge the more I am convinced that Embedlets are capable of elegantly accommodating an extremely diverse set of needs. Ted __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: Andrzej J. T. <an...@ch...> - 2003-01-27 15:56:30
|
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 |