article in Industrial Computing

G

Greg Goodman

> Is this still secret? Not anymore :^) We'd hoped to be ready for initial release at about the same time the article came out, but other commitments have delayed our efforts. We're not sure exactly when it will be, but we're aiming for mid-summer. We'll keep the PuffinPLC and Automation list readers posted. > Since it's public now, how about filling us in? For several years, a colleague and I have been working (as time and other commitments permit) on an open source scada/controls package for our own use. It's largely complete, and we're working to get it to the point where it's usable out of the box. We're also working on some basic documentation, so you don't have to read gobs of source code to figure out how to make it work. > Will Puffin SCADA interact with us? Sure. The SCADA system wasn't designed around the LPLC, but it also wasn't designed for any other particular PLC (or even any particular I/O model), so there's no reason they can't talk. And it's all open source, so there is significant potential for tighter integration. I expect a significant amount of cross-posting between the PLC and SCADA mailing lists as we discuss how and to what degree the two packages can interact. Regards, Greg _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
D

David Nimmons

How bout a link to the SCADA mailing list. Thanks. > Will Puffin SCADA interact with us? Sure. The SCADA system wasn't designed around the LPLC, but it also wasn't designed for any other particular PLC (or even any particular I/O model), so there's no reason they can't talk. And it's all open source, so there is significant potential for tighter integration. I expect a significant amount of cross-posting between the PLC and SCADA mailing lists as we discuss how and to what degree the two packages can interact. Regards, Greg _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Greg

Thanks for the article and the pointer.
Too bad the leadtime didn't allow for the changes.


Regards

cww

--
Free Tools!: Machine Automation Tools (LinuxPLC) Free, Truly Open,and Publicly
Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation and ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business and Automation to Linux.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Juan and Greg:

It seems Juan is starting to write the beginnings of a SCADA. Greg seems to be more advanced. Wouldn't it be better if you could work
togehter on the project?

Jiri: It seems that soon we will be needing top level directories in
the cvs...
/plc
/scada
/ape

This is if the authors of these projects are willing to make it a single project, and not three independent projects? Would we be better off by having three projects instead?

Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa
[email protected]
----------------------------------------------------------------------------

The box said it requires Windows 95 or better, so I installed Linux

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Yes, it would.
I'm not sure what the deal is with this but they have been invited. Perhaps there are philosophical differences. Perhaps they simply
want to do it themselves. Perhaps they want to retain a product identity. It's been kinda low profile and I think perhaps they prefer the association with Control.com.

Hey Greg, care to comment?

Regards

cww

--
Free Tools!: Machine Automation Tools (LinuxPLC) Free, Truly Open,and Publicly
Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation and ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business and Automation to Linux.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Mario:
> Jiri: It seems that soon we will be needing top level directories in the
> cvs...
> /plc
> /scada
> /ape

APE probably belongs in the logic directory (logic/ape); as far as I understand it, it's a programming environment just like a ladder editor or an iec 61131 translator. (Richard, if I misunderstood what the APE will do, please let me know - that's the general impression I got, but I never used TI APT so I'm not entirely sure.)

The scada will consist of various modules, but again they run against the same core and can be put into the logic, mmi and io directories as
appropriate, or a new directory can be made if there's a class of modules that doesn't fit into any of these.


Any reason why they should be completely separate?

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Juan Carlos Orozco

Jiri Baum wrote:
>
> Mario:
> > Jiri: It seems that soon we will be needing top level directories in the
> > cvs...
> > /plc
> > /scada
> > /ape
>
> APE probably belongs in the logic directory (logic/ape); as far as I
> understand it, it's a programming environment just like a ladder editor or
> an iec 61131 translator. (Richard, if I misunderstood what the
> APE will do,
> please let me know - that's the general impression I got, but I never used
> TI APT so I'm not entirely sure.)
>
> The scada will consist of various modules, but again they run against the
> same core and can be put into the logic, mmi and io directories as
> appropriate, or a new directory can be made if there's a class of modules
> that doesn't fit into any of these.
>
> Any reason why they should be completely separate?

I will try to upload my project as soon as possible even if it is not finished, this way I can work at home and at the office (when time aloud). I want to avoid more speculation about this program. I prefer that any one who is interested can take a look at it actually working. My module is for the moment specifically programmed to work with LinuxPLC, therefore for now there is no reason to make it a separate project.

Mario had a concern about my project and Greg's project overlapping. I originally was not willing to make the GUI from zero, and I asked Greg, at
that time he had no GUI editor besides the Tcl interface. Greg has been very kind in offering me his help with this interface, I want him to look at this code and tell me if there is synergy between his project and my project. By the way my project is for now only a GUI editor that can read or write to the LinuxPLC I/O, it is not a complete scada. Greg project seems to be a
complete scada except the GUI editor at that time (about 4 weeks ago).

I am using the next directories in my machine:

/demo/basic_gtk/ (for the chaser demo GUI)
/demo/basic_dsp_gtk/ (for the basic_dsp demo GUI)
/mmi/hmi_gtk/ (for the HMI interpreter code)

Are this OK. Otherwise please make a suggestion.

Regards,

Juan Carlos Orozco

ACElab Industrial Automation
[email protected]
www.ace-lab.com

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top