System Architecture - Graphical Interface


Thread Starter



I am now working on graphical programming tools for the LPC, and I could also set them up to produce files for the PuffinPLC. It will take me a
few weeks to get them done. I can figure out the formats by looking at the CVS source, but I would appreciate it if somebody could write up a spec (Curt might be a good candidate). If you are interested let me know, otherwise tell me that C++ and Java should not be part of the Puffin project.


LinuxPLC mailing list
[email protected]

Curt Wuollet

Hi Hugh

I wasn't kidding about opening it up and GUI's are one of the areas where I have never opposed alternative tools. (Within reason :^))
But, to tell you the truth, I don't know what the solver is going to look like or what the output code of the tools would have to be. I have my own opinions, of course, but what I suggest is that you collaborate with Dave and Mario and Jiri and perhaps Dan and try to figure out just what the solver should work with ie. will we use a
common solver that runs the stuff output by the language tools or is each language going to output executable code to be ran as a
process or ?. I understand you are running an interpreter and Dave will output C and I think Dan would like to see something friendly
to states and transitions. This makes it look like each language will need to be standalone but it wouldn't hurt to brainstorm a little up front. Our competition allows combining FB with RLL, etc.
I really like the concept of a logic 4GL something like GE's "State Logic"(tm.) with explicit support for C modules so I don't have to solve fft's with relays and I can add dataset types, etc. Such things have not really played well in the automation marketbut that's why National Instruments is cleaning up, they didn't
start out with limited horizons.



LinuxPLC mailing list
[email protected]