Menu
▾
▴
qscada-developers — Developers Mailing List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(32) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(7) |
Feb
(3) |
Mar
(17) |
Apr
(3) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jovan K. <cho...@gm...> - 2006-11-17 01:23:35
|
Hi, On 11/16/06, wireless <wir...@ta...> wrote: > Well, that's very similar to what I had in mind: > > I would use (2) time fields: > > [parameter, timestamp, skew] > > Where the timestamp is the one closest to the first element (i.e. the > RTU) and the skew is the delay(difference) in that first timestamp > and the next device that can generate an (NTP) timestamp. So between two > systems, it's virtually the same parameters, because you can add > timestamp and skew to get the second timestamp value. Really good concept. That way we can measure the time delays of the parameter data when travelling through devices until it gets to the QScada server. There is a small problem: Not all field devices (RTUs etc.) keep track of time. The time of the measurement depends of the device that reads that information. All the other times are relative to that time. So if the first device, the one that reads the informaton doesn't have a clock, who will timestamp that information? The first device on the road that has a clock, or the QScada server? The method that I proposed (t_occured an d t_arrived) is based on the experiences that I have from working on development of SCADA systems. So if the device that read that parameter doesn't have a clock only the t_arrived parameter is filled. I personally like James' method more because time delays between devices can be measured, but the drawback is that every device in the system has to track the time (have a clock). GREETZ, Jovan |
|
From: Jovan K. <cho...@gm...> - 2006-11-17 00:55:22
|
Hi, On 11/16/06, wireless <wir...@ta...> wrote: > Jovan, > > WE agree again! (this is quite scary for me).... Ok, from now on what ever you say I'll take the opposite side :) > But, my question is what do you do when the "big boys" > Do not develop compatibility with Qscada? Reverse engineering > their proprietary portocols, even with a limited measure of success, > will motivate them. I'm sorry, but I do not see Rockwell, Siemens, > etc etc jumping on the Qscada bandwagon, as most have purchased > part or all of companies that have their own SCADA products. > Reverse engineering protocols provides that nudge some may need. > If not, potential users of Qscada, will have an alternative. Good point. I'll check (already found) some existing FLOSS projects of Scada systems for PLC drivers (tested and ready to use). I'll also dig http://forums.mrplc.com for docs and reverse engineered protocols (they had loads of that stuff). We should always have in mind that some companies want "out of the box" solutions and always buy everything from one vendor. Sad, but true :( > If the (legacy) Scada server to PLC communiations involve many > proprietary protocols, migration away from that (vendor's)Scada server > platform can be a lot of work, and preclude many from the effort. That > is why we'll need to suppport these legacy (proprietary) protocols > in QScada. If not this approach, then tell me what is our plan to > attract (migrate) folks from their legacy scada setup to QScada? No, you're wrong (read this yes you're right :) We have to support as much protocols as we can. There are some people somewhere in the world that have already done reverse engineering and rewritten the protocols so we just have to ask them for help. > If we do not have compatibility with the "big boys" on their proprietary > (plc) protocols, migration from other commercial SCADA offerings to > Qscada, may take a long time. Most protocols are "clear text" and > therefore straightforward to reverse engineer.... We do it all the time, > but, as you have elluded, maintaining such code, is time consuming.... As I said before. We can reverse engineer ourselfs or to wait somebody else to do it and all we should do would be writing the protocol by his/hers docmentation, or even easier, change the code that they have written to comform our needs. GREETZ, Jovan |
|
From: Jovan K. <cho...@gm...> - 2006-11-17 00:02:18
|
On 11/16/06, wireless <wir...@ta...> wrote: > Besides I thought we had agreed on C/C++, QT, and Java? > Any other languages? XHTML, PHP, JavaScript + XML (AJAX) for web based scada clients, can't think of anything else at the moment. What will the others say? :) GREETZ, Jovan |
|
From: wireless <wir...@ta...> - 2006-11-16 21:04:36
|
Hello Everyone, >From linuxdevices here is an interesting article: Gaff added, "Wind River is particularly pleased that because of Target Management's successful release, device software developers now have an open source framework and a set of views for managing remote embedded systems from Eclipse. Wind River plans to adopt the Target Management technology in our next release of Wind River Workbench." I'm no fan of WindRiver, but this aticle is worth reading: http://www.linuxdevices.com/news/NS4284084732.html Any my questions is which IDE are developers of QScada going to use? Once we nail down the desired languages to support, I'd be most curious as to which, if any, IDE folks will be using to develop and maintain the Qscada code_base? If not Eclipse then which IDE? Or are we going to just use a variety of command line tools and traditional unix/C coding approaches? Every one using their how toolchest of IDEs and scripts? CVS vs SVN http://www.joestump.net/913108051/subversion-vs-cvs-review.html curious as to other's thoughts on IDEs and code repository management ideas. James |
|
From: wireless <wir...@ta...> - 2006-11-16 19:48:21
|
Jovan Kostovski wrote: >>Besides, we both agree on pushing the RT needs as close to the >>remote hardware as possible. > > Yes that's right. In some situations we can solve the RT problem by adding > two timestamps to the data, one would be the time that the event has occured > set by the RTU, and the other would be the time when it has arrived on > QScada server, > set by the QScada server. That way we'll have the exact time when the event > has occured and when it was registered/logged by QScada. Well, that's very similar to what I had in mind: I would use (2) time fields: [parameter, timestamp, skew] Where the timestamp is the one closest to the first element (i.e. the RTU) and the skew is the delay(difference) in that first timestamp and the next device that can generate an (NTP) timestamp. So between two systems, it's virtually the same parameters, because you can add timestamp and skew to get the second timestamp value. However, if there are more that 2 devices running NTP between he final scada server and the first element (RTU in this example) then you use skew as a cummulative function of the maximum or total delay. That way you keep your RT data to just 2 fields of time (original timestamp and skew) . But if you are having problems and need to debug, then we should have a debug options where all of the timestamps between the final Qscada server and the RTU are kept. For example if somebody has 2 Qscada servers and 2 plc, in ordinary RT mode you'd see date like this [parameter, timestamp-0, skew] in debug mode, you'd see [parameter, timestamp-0, 0] [parameter, timestamp-1, skew-0.1] [parameter, timestamp-2, skew-1,2] [parameter, timestamp-3, skew-2,3] or [parameter, timestamp-0, skew-2,3] depending if you want to subtract or add the skew value.... skew is normally an accumulated value but can be expanded via a link list or other such construct, when needed (debug mode). ???? James |
|
From: wireless <wir...@ta...> - 2006-11-16 17:43:38
|
Jovan Kostovski wrote: >>Those companies that do not get on board with Qscada will >>have their "proprietary portocols" reverse engineerd so they will be >>compatible without consent/control of their destiny..... > We don't have to reverse engineer those protocols. If we do that we > can not garantee that the protocol is working correctly. > I think the best way is those proprietary protocols to be written by > the companies themselves and to be given to us as compiled > plugins that can be added to QScada. > A concept similar to what NVidia is doing with the Linux drivers for > their graphic cards. Jovan, WE agree again! (this is quite scary for me).... But, my question is what do you do when the "big boys" Do not develop compatibility with Qscada? Reverse engineering their proprietary portocols, even with a limited measure of success, will motivate them. I'm sorry, but I do not see Rockwell, Siemens, etc etc jumping on the Qscada bandwagon, as most have purchased part or all of companies that have their own SCADA products. Reverse engineering protocols provides that nudge some may need. If not, potential users of Qscada, will have an alternative. What I do is used proprietary protocols(when the customers insists) between the PLC and a limited amount of equipment. I then used ModbusTCP to communicate with the SCADA server. If one designs a controls network like that, migration from one Scada server to another is very straightforward. If the (legacy) Scada server to PLC communiations involve many proprietary protocols, migration away from that (vendor's)Scada server platform can be a lot of work, and preclude many from the effort. That is why we'll need to suppport these legacy (proprietary) protocols in QScada. If not this approach, then tell me what is our plan to attract (migrate) folks from their legacy scada setup to QScada? If we do not have compatibility with the "big boys" on their proprietary (plc) protocols, migration from other commercial SCADA offerings to Qscada, may take a long time. Most protocols are "clear text" and therefore straightforward to reverse engineer.... We do it all the time, but, as you have elluded, maintaining such code, is time consuming.... thoughts? James |
|
From: wireless <wir...@ta...> - 2006-11-16 17:25:03
|
>>Qscada is a new encouraging project that will sure >>help a lot. > > We hope it will. Spread the news and find more > people to join us ;) > > GREETZ, Jovan > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Qscada-developers mailing list > Qsc...@li... > https://lists.sourceforge.net/lists/listinfo/qscada-developers > Jovan Kostovski wrote: > Hi All, > > On 11/15/06, Ivan Vavrecka <iva...@ya...> wrote: > >>I am a new suscriber, not a programmer, just looking >>for some general knowledge about these topics. > > Hello Ivan, welcome aboard. > It's nice to have you here. It doesn't metter if you're programmer > or not, we need some people to remind us of some similar > useful projects and promote usage of QScada as well. ;) As much as possible, we should look at other project. At the very least we can see what good ideas they have. > >>...PyOPC is a framework for rapidly creating OPC >>XML-DA compliant clients and servers....A Python >>Framework for the OPC XML-DA 1.0 Standard... > We are planning to use XML-RPC for QScada so it will probably be implementation > of OPC-XDA to conform the trends and standars in authomation control. Got any links on this? > Bindings means more delays :( > We can use python for some parts of QScada that are not > time critical, but for the OPC servers/clients I think that's > bad idea. > > As I saw in these two tutorials: > http://www.cs.usfca.edu/~afedosov/qttut/ > http://www-128.ibm.com/developerworks/linux/library/l-qt/ > > PyQt is used to connect a python script to a Qt GUI. The really neat thing about Gentoo is that both are supported: eix pyQT * dev-python/PyQt Available versions: 3.14.1-r1 3.14.1-r2 [M]3.17 Installed: 3.14.1-r1 Homepage: http://www.riverbankcomputing.co.uk/pyqt/ Description: PyQt is a set of Python bindings for the Qt toolkit. * dev-python/PyQt4 Available versions: ~4.0 ~4.1 Installed: none Homepage: http://www.riverbankcomputing.co.uk/pyqt/ Description: PyQt is a set of Python bindings for the Qt toolkit. > So once again I'm against using python in QScada, > but the majority desides :) > I'm an assembler/state-machine/ansi_C type, so I'm going to vote with Jovan. Besides I thought we had agreed on C/C++, QT, and Java? Any other languages? Gentoo just released KDE 3.5.5 which includes support for 1.4 and 1.5 with dynamic switching of JVM. Java 1.6 will be released in December : http://www.gentoo.org/news/en/gwn/20061016-newsletter.xml James |
|
From: Iain B. <ia...@ne...> - 2006-11-16 00:31:09
|
On Wed, 2006-11-15 at 10:25 +0100, Jovan Kostovski wrote: > On 11/15/06, Iain Buchanan <ia...@ne...> wrote: > > Jovan and James, did you two CC Fernando in your replies? I don't think > > he's on this ml yet. His email address is > > <fr...@le...> > > Hm.... > I was thinking to cc but I thought he's on the list 'cos i saw that we > have 5 subscribers. silly me :) > I've just forwarded my message. Actually, I think he is on the list. Apologies if anyone has received things twice :) cya, -- Iain Buchanan <iaindb at netspace dot net dot au> polygon: Dead parrot. |
|
From: Jovan K. <cho...@gm...> - 2006-11-16 00:25:47
|
Hi, Great to hear from you Paolo. On 11/15/06, wireless <wir...@ta...> wrote: > On anther note, I rather like Jovan quite a lot. He's very up_tempo > and crazy_maniacs like myself need a good rudder, now and then. Thanks for the complinents :) > Besides, we both agree on pushing the RT needs as close to the > remote hardware as possible. Yes that's right. In some situations we can solve the RT problem by adding two timestamps to the data, one would be the time that the event has occured set by the RTU, and the other would be the time when it has arrived on QScada server, set by the QScada server. That way we'll have the exact time when the event has occured and when it was registered/logged by QScada. > Besides, on the Qscada server end, I'm leaning more to > "openmosix" as a cluster, to provide High Availabilty for QScada. good point > Those companies that do not get on board with Qscada will > have their "proprietary portocols" reverse engineerd so they will be > compatible without consent/control of their destiny..... We don't have to reverse engineer those protocols. If we do that we can not garantee that the protocol is working correctly. I think the best way is those proprietary protocols to be written by the companies themselves and to be given to us as compiled plugins that can be added to QScada. A concept similar to what NVidia is doing with the Linux drivers for their graphic cards. GREETZ, Jovan |
|
From: Jovan K. <cho...@gm...> - 2006-11-15 23:54:36
|
Hi All, On 11/15/06, Ivan Vavrecka <iva...@ya...> wrote: > I am a new suscriber, not a programmer, just looking > for some general knowledge about these topics. It's nice to have you here. It doesn't metter if you're programmer or not, we need some people to remind us of some similar useful projects and promote usage of QScada as well. ;) > ...PyOPC is a framework for rapidly creating OPC > XML-DA compliant clients and servers....A Python > Framework for the OPC XML-DA 1.0 Standard... I've just read the docs for PyOPC, seems fine to me, but i don't know if we should introduce another programming language in our project. I think it would be better if we are using one programming language and avoid forcing heterogeneous system (I'm thinking of prog. langs). On the other hand our project will depend on another which can be bad sometimes. What will happen if the PyOPC project is not upgraded in time when new OPC specification is published? We'll have to do it our own, so someone of us will have to work on PyOPC as well. The third thing is the python programming language it self, its nature. It is a script language, and it takes longer time to execute (through the python iterpreter). Because of that, we can experience some delays in message sending/receiving which can cause some problems in responese times and if we are dealing with processes whose process paremeters (measurements, alarms...) change very fast and fast response from the SCADA operator is needed. In real life SCADA systems where the SCADA center and the remote plant are on different locations connected with some kind of network, wired or wireless (radio, wifi) there are delays because of the communication. Think of a radio link in bad weather conditions... Delays will varay and we will only know some maxiumum delay that is the limitb of what we call good communocation. We must not introduce some not necessary extra delays because of the structure of the system and the nature of script programming languages. But these things doesn't stop us to use some good ideas from PyOPC. I've written one seminar paper on OPC when I was at college, about 15 pages. I'll translate it to english and send it here so we can all be familiar with the concepts used in OPC. The unpatient can check: http://www.opcfoundation.org - the organization that takes care of OPC standards http://www.matrikon.com - company that has many examples of OPC clients/servers mostly for M$ windowz http://www.opcconnect.com/ - links to OPC software solutions We are planning to use XML-RPC for QScada so it will probably be implementation of OPC-XDA to conform the trends and standars in authomation control. > I also found full compabillity of qt designer with > phyton. Yes I know, pyQT library. I've never used it though. "PyQt is a set of Python bindings for Trolltech's Qt application framework and runs on all platforms supported by Qt including Windows, MacOS/X and Linux. There are two sets of bindings: PyQt v4 supports Qt v4; and the older PyQt v3 supports Qt v3 and earlier. The bindings are implemented as a set of Python modules and contain over 300 classes and nearly 6,000 functions and methods." Copy/Paste from http://www.riverbankcomputing.co.uk/pyqt/ the developers of PyQT. Bindings means more delays :( We can use python for some parts of QScada that are not time critical, but for the OPC servers/clients I think that's bad idea. As I saw in these two tutorials: http://www.cs.usfca.edu/~afedosov/qttut/ http://www-128.ibm.com/developerworks/linux/library/l-qt/ PyQt is used to connect a python script to a Qt GUI. So once again I'm against using python in QScada, but the majority desides :) > Qscada is a new encouraging project that will sure > help a lot. We hope it will. Spread the news and find more people to join us ;) GREETZ, Jovan |
|
From: Ivan V. <iva...@ya...> - 2006-11-15 21:22:01
|
Hi Jovan, Hi all, I am a new suscriber, not a programmer, just looking for some general knowledge about these topics. Learning the geek dialect i found that there is available for download a new utility, ...PyOPC is a framework for rapidly creating OPC XML-DA compliant clients and servers....A Python Framework for the OPC XML-DA 1.0 Standard... http://pyopc.sourceforge.net/docs/html/index.html Peeping into its documentation i found it quite encouraging, I also found full compabillity of qt designer with phyton. My guess is that we will soon have some more news about this. ...your comments ? My goal is to encourage some migration alternatives, from propietary to free or open source SCADA solutions. Qscada is a new encouraging project that will sure help a lot. Best wishes, Ivan --- Jovan Kostovski <cho...@gm...> e scribió: > > 3.- Is there any good OPC for Linux? I saw a lot > of it for Windows, but > > I don't want to use it in a production enviroment > and I prefer to use > > the XML-DA protocol versus COM/DCOM ;) > > Yes there are some OPC clients/servers for Linux but > most of them are > really expensive. They are using the DCOM for Linux > library > http://www2.softwareag.com/corporate/products/entirex/ > or they > implement only OPC XML-DA. > For more info on opc for linux check: > http://www.opcconnect.com/tooltech.php > > My main idea of the project is a dedicated machine > with Linux getting > > information from all the plant PLCs and store all > the sensors values in > > a database (postgresql or MySQL), then the SCADA > GUI will communicate > > with the DB and show the information to the user. > > If you only need to display the values of the > sensors (read-only, no > commands or data send back to the PLCs) my > suggestion is to write a > program that will communicate with the PLCs and > store the data in a > database, and to setup php based web page that will > display the data. > > GREETZ, Jovan __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ |
|
From: wireless <wir...@ta...> - 2006-11-15 17:08:54
|
Paolo Sereno wrote: > Hi James, > back in Italy, but still busy. > I=B4m here even if it seems I=B4m diseppeared. > Thanks for your help and effort > take care > paolo Hello Paolo, It's always good to hear from you. Hang in there. Things will get better for you and all of us. You and yours are in my prayers and I hope you work everything out. On a brighter note, every time I talk to somebody about Qscada, they think it is a wonderful idea. We just need to get it to a point where we have some simple hardware on the net for folks to see and control. AT that point, I think it will explode with excitement as a project. In my opinion, I think it's good for you to 'hang back' and let the indians hash out quite a lot. That way, you can enter the debates at a later stage, as 'father wisdom' once the emotional spew is spent and folks are ready to get to work. On anther note, I rather like Jovan quite a lot. He's very up_tempo and crazy_maniacs like myself need a good rudder, now and then. Besides, we both agree on pushing the RT needs as close to the remote hardware as possible. That is the RT needs to be satisfied on the processor that is the closest to the field hardware. Whether it's a pc running qscada on a small control network, or a plc that has 3 processors between itself (the field plc) and final qscada server, RT requirements should be on the (micro)processor closest to the final (controlled) elements. But, we can support both scenarios and everybody will be happy. I've spent lots of time on RT issues with pc(servers) and it's not where I want to spend my time. Besides, on the Qscada server end, I'm leaning more to "openmosix" as a cluster, to provide High Availabilty for QScada. Supporting this "dual modality" of RT will allow vendors with products such as PLC with pid cards to be excited about Qscada. This is a very important point too. If we keep Qscada attractive to commercial companies, eventually all but the largest will get on board with Qscada. Those companies that do not get on board with Qscada will have their "proprietary portocols" reverse engineerd so they will be compatible without consent/control of their destiny..... If we support an architecture that allows one to mix and match both commercial offering and Qscada,(down to running pid loops) on a qscada machine in lieu of commercial plcs, then Qscada will allow for easy transition for utilities and companies, by allowing them to initially just replace their legacy scada server with Qscada. Last, I want you to know that I pray for people. It's part of my fundamental beliefs, so, If you are hurting or need a friend or want somebody to pray for you and yours, just let me know.... Our faith is the only thing that separates us from the animal kingdom....... Keep the faith, always your pal, James |
|
From: Jovan K. <cho...@gm...> - 2006-11-15 09:25:06
|
On 11/15/06, Iain Buchanan <ia...@ne...> wrote: > Jovan and James, did you two CC Fernando in your replies? I don't think > he's on this ml yet. His email address is > <fr...@le...> Hm.... I was thinking to cc but I thought he's on the list 'cos i saw that we have 5 subscribers. silly me :) I've just forwarded my message. Jovan |
|
From: wireless <wir...@ta...> - 2006-11-15 03:54:58
|
Iain Buchanan wrote: > Jovan and James, did you two CC Fernando in your replies? I don't think > he's on this ml yet. His email address is > <fr...@le...> > > cya, Good catch. I just forwarded it to him. James |
|
From: Iain B. <ia...@ne...> - 2006-11-15 01:46:19
|
Jovan and James, did you two CC Fernando in your replies? I don't think he's on this ml yet. His email address is <fr...@le...> cya, -- Iain Buchanan <iaindb at netspace dot net dot au> What if everything is an illusion and nothing exists? In that case, I definitely overpaid for my carpet. -- Woody Allen, "Without Feathers" |
|
From: Iain B. <ia...@ne...> - 2006-11-15 01:42:48
|
On Tue, 2006-11-14 at 13:20 -0500, wireless wrote: > Hello Everyone, > > > http://www.stateworks.com/active/content/en/home/view_newsletter.php?id=26 > > This is pushing a vendor solution,but I do agree with the state machine > approach to controls. Especially if you are going to migrate > from one plc(dcs) to another or from a plc to an embedded linux system > runing pid code, or from a plc to qscada etc etc.... Coming from the other side (I started writing state machines and control systems code in C and C++) I've recently started using IEC 61131-3, and I can't comprehend how anybody could like ladder logic! It is a suffocating language! Sure, it may be "easier" for an "old" hardware-control systems engineer to pick up, but at what cost? [answer to rhetorical question: the cost is the limitations of what you can do with ladder, and how long it takes you to do anything!] I tried some of my earlier IEC 61131-3 programs in each of ladder (LD), structured text (ST) (a kind of pascal-like language); Continuous Function Charts (CFC); Function Block Diagram (FBD); and a bit of Sequential Function Charts (SFC) as mentioned in the above article. This is what I found: LD was the hardest to program in - some elements of my specifications took hundreds of lines of ladder, and there is no easy way of reading through such monolithic code. (There's no empty lines, and comment blocks like a textual programming language). SFC is great for making simple state machines, especially when managers / customers specify a particular state machine, but don't want to see all the code behind it. However, SFC has to rely on the others for doing the work. CFC is probably the best "Graphical" language in IEC 61131-3. It approaches the all-great all-powerful G+ graphical programming language developed by LabView (this is by far the best graphical programming language I have ever seen). It's great for writing a graphical spec which the customer can agree on, then implementing is the same form. As an example, attached is a spec that I wrote with a customer, and the final implementation in IEC 61131-3. Customers get excited when they see the implementation looking like their spec - and it has advantages for the programmer too - if there are functional errors, we can go back to the spec and say "it's performing the way you specified", and prove it by showing them the implementation. It would be near-impossible to get a non-programming customer to agree to c++ code as a specification. FBD seems to be a bad mix of LD and CFC. Your limited to ladder like steps, without the freedom of CFC, but at least you can use more complicated structures than LD. and finally, ST, or structured text, is by far the easiest for implementing comms and the "guts" of the program. Anything difficult is done here! And the outcome is often the most compact. I disagree with the stateworks claim that "building any complex system requiring several cooperating state machines ... with the means offered by the SFC notation is theoretically and practically just impossible." given that you can and must call on the other languages in IEC 61131-3 to supplement your state machines. Anyway, that was a fun little exercise. Hope you find my thoughts interesting, on with work! ... -- Iain Buchanan <iaindb at netspace dot net dot au> What no spouse of a writer can ever understand is that a writer is working when he's staring out the window. |
|
From: Jovan K. <cho...@gm...> - 2006-11-15 00:56:28
|
Hi All, > From: Fernando Rodr=EDguez Sela <fr...@le...> > ... as soon as I finish with this I'll try to help you in some areas > of your project if it doesn't takes a lot of time (because I'm very > busy now) - If you need help in some area write me and I'll try to help > you ;) Great to hear that you are interested in QScada. Welcome onboard :) > 1.- Is there any OMROM or SIEMENS emulator to test the SCADA > communications with it? Well, as James wrote you can check that link for emulators, but by my experience in almost 100% of the projects that involve communication with external devices the hardest thing, where most problems come from is to assure good communication without errors. Even if the program works great on the emulator you can never be sure that it will work good in the "real life". I see that you don't have PLC to play arround, so my suggestion is to call the company and ask them to gi= ve you one PLC and one piece of every type of sensor that is used so you can = test your enviorment in lab. > 2.- Is there any library to communicate with OMROM (hostlink) and > SIEMENS (profibus?) in Linux? (no problem if it a commercial solution) Here are some links: http://plc.sourceforge.net/ - list of links for open source projects on automation control http://visual.sourceforge.net/ - web based (java applets) scada/hmi open source project. It has support for variaty of PLCs http://www.mrplc.com - forum on PLCs (Allen Bradly, GE, Omron, Mitsubishi). Omron protocols are torn appart :) > 3.- Is there any good OPC for Linux? I saw a lot of it for Windows, but > I don't want to use it in a production enviroment and I prefer to use > the XML-DA protocol versus COM/DCOM ;) Yes there are some OPC clients/servers for Linux but most of them are really expensive. They are using the DCOM for Linux library http://www2.softwareag.com/corporate/products/entirex/ or they implement only OPC XML-DA. For more info on opc for linux check: http://www.opcconnect.com/tooltech.ph= p > My main idea of the project is a dedicated machine with Linux getting > information from all the plant PLCs and store all the sensors values in > a database (postgresql or MySQL), then the SCADA GUI will communicate > with the DB and show the information to the user. If you only need to display the values of the sensors (read-only, no commands or data send back to the PLCs) my suggestion is to write a program that will communicate with the PLCs and store the data in a database, and to setup php based web page that will display the data. GREETZ, Jovan |
|
From: wireless <wir...@ta...> - 2006-11-14 18:21:11
|
Hello Everyone, http://www.stateworks.com/active/content/en/home/view_newsletter.php?id=26 This is pushing a vendor solution,but I do agree with the state machine approach to controls. Especially if you are going to migrate from one plc(dcs) to another or from a plc to an embedded linux system runing pid code, or from a plc to qscada etc etc.... enjoy, James |
|
From: wireless <wir...@ta...> - 2006-11-14 17:12:40
|
Jovan Kostovski wrote: > Hi, > > HATS DOWN for you James. > So many great ideas. > > > >>On 11/10/06, wireless <wir...@ta...> wrote: >>Jovan: have you guys what tools/languages we should all install, to >>work on Qscada? I need this info to begin recruiting coders and >>testers. > > > At first glance we need: > > 1. C/C++ I/O programming (serial port, parallel port, usb, IR ...) > 2. C/C++ for industrial protocol programming (Modbus, CANBus, some PLC > protocols...) > 3. C/C++ Linux Kernel programming - for drivers for external devices > (microcontrollers, PLCs...) > 4. C/C++ QT GUI designers for design time and runtime GUI (examination > of some scada systems is must: WonderWare Intouch and alike) > 5. C/C++ QT widget programmers for widget libraries. We must create a > template for the widget > 6. C/C++ network and network security programmers > 7. Web programmers (AJAX, XML, PHP, XHTML) for web based clients > 8. Some pople with knowledge of linux embedded systems (RTAI, RTLinux...) > 9. Database developers MySQL and PostgeSQL > > That's all that I can think of for now. Good list Jovan. Maybe Iain can parse these email messsages for such information and put in the web pages to attract folks? > I'll have to do better > analysis. I hope I'll do > that by the and of the week, but first we have to disccuss about the structure > (building blocks) of QScada. Yes, I getting ready to take some time off from work. QScada is going to receive the majoring of my time.... Once I finish the draft(very crude) for hardware issues, I'll send it to the group. At that point, I'll be ready to discuss organization and the building blocks. Look for an ugly first draft soon. I'm not spending anytime on making it pretty, only content. We can develop a template document for all future documents to use. That wany somebody can just fire up openoffice and a template, stick content into it, and present it back to the group......? Likewise, if you include revision numbers, others can check out the docs add material for discussion and then the group(leader?) can make the final edits? It's be iterative. >>we need a software oriented person (Jovan?) > > Hey! I want to play with wires to :) > It's fine by me if I'll be the software guy, but I'll > play with hardware too ;) Once the architecure is finished, there will be lots of hardware, and wires for all to play with. Once we figure out the configuration and make it secure, I'm quite certain other will build hardware playgrounds too.... > > > >>I'll be the hardware guy >>building an online playground for folks to hang out and articulate >>QScada with actual hardware I'm not going to be the only hardware guy. It's just I have a facilty and much equipment already. What I build will become available for us to use, attract new members and eventually, others will be encourage to put up 'online labs' too. It's just expensive..... > This is great idea. I see that you have good equpemnt. > You should setup a QScada server and the clients will access > remotely. It would be nice if there are cameras for every actuator so > that the real life effects can be seen. The camera can send > series of consequtive pictures or live stream video. The prblem > would be colision in controls (two or more clients are accessing > the same device) Yes, Yes, we are very big on H.264 here. As soon as possible, when Iain has an ebuild ready, I'll be the first to test install QScada(?).... Portage overlay? I have some good links on creating ebuilds.....but, they are easy to find with google. >>we can put up QScada for google funding it as a 'Summer of Code' opportunity. > > Another one! > That's all for now. > Be well, Jovan James |
|
From: wireless <wir...@ta...> - 2006-11-14 16:30:41
|
Iain Buchanan wrote: > Hi all, >=20 > here is an email from Fernando, with some questions and comments. He > found out about us by surfing the web, and I thought you might be > interested, or able to give him some help. I've responded already. >=20 > -------- Forwarded Message -------- > From: Fernando Rodr=C3=ADguez Sela <fr...@le...> > To: ia...@us..., qt...@us... > Subject: About SCADA > Date: Thu, 02 Nov 2006 21:29:38 +0100 >=20 > Hello, >=20 > I'm a Spanish developer who is working in a SCADA environment for an=20 > Spanish chemical company and I'm developing it with QT4 under Linux. >=20 > Surfing in the web I found your project which it's very similar to mine= =20 > ;) ... as soon as I finish with this I'll try to help you in some areas= =20 > of your project if it doesn't takes a lot of time (because I'm very=20 > busy now) - If you need help in some area write me and I'll try to help= =20 > you ;) >=20 Hello Fernando, Yes you and our band of developers have much in interest with developing a robust and secure Scada solution that can act as both a DCS and a traditional Scada_Server with PLCs acting remotely in real time with those hardware components that need RT performance. However, we are at the architectural stage of developing a framework that emcompasses many technologies. Once that is finished we'll splitter into groups with leaders that develop the various aspects of Qscada. Paolo (our beloved leader and paternal figure, <just kidding>) sees a QT4 centric scada system with both RT and best effort capabilities. His early work on Scada can be seen here [1] > Also, I want to make a little question about my project ... It's the=20 > first time I work with PLCs so I'm a "Rockie" in this area :D ... My=20 > main questions are: >=20 > 1.- Is there any OMROM or SIEMENS emulator to test the SCADA=20 > communications with it?=20 This may help [2]. I usually just 'reverse engineer the protocols' but, that is quite a lot of work. Our hope and belief is that once we have finished the rough drafts we can beging to reverse engineer many if not most of the proprietary that are pushed by "vendor_lockin" merchants. I myself strongly prefer modbusTCP and have intentions to ad RT (deterministic) capabilities to modbusTCP. WE're all a bunch of practicing controls engineers hear, so I'm sure you'll experience a diverse opinions, within QScada. Our goal is to develop and open and flexible frame work that eventually attracts the major PLC vendors. ModbusTCP is the most used controls protocol to date, because OMRON put in the the public domain. > 2.- Is there any library to communicate with OMROM (hostlink) and=20 > SIEMENS (profibus?) in Linux? (no problem if it a commercial solution) > 3.- Is there any good OPC for Linux? I saw a lot of it for Windows, but= =20 > I don't want to use it in a production enviroment and I prefer to use=20 > the XML-DA protocol versus COM/DCOM ;) Here's a link that we should put in a resource web page (grin) that I think Jovan turned us on to, that may help you: [2] Fieldbus is an attempt to obfustricate CAN bus into something that appears to be better but is actually a weak/flawed implementation of CAN bus into the proprietary Fieldbus: [4] [5] The company I work for has several folks that are "embedded systems" devlopers, so we build products for companies..... > My main idea of the project is a dedicated machine with Linux getting=20 > information from all the plant PLCs and store all the sensors values in= =20 > a database (postgresql or MySQL), then the SCADA GUI will communicate=20 > with the DB and show the information to the user. Amazingly, we agree! If you are builing a large system with atomic transaction needs, you may have to go with Postgresql. We are looking for a DATABASE leader to fluff out that area of specifications. We want to support both mysql and postgresql as database solutions for QScada. > My problems now are in getting information from the SCADA because I am=20 > very far from the company so I need an emulator or something similar or= =20 > buy a developed environment. QScada, when deployed will allow for secure transmission across the internet. Granted you loose RT capbitilies across the net, but I believe all RT requirements should be pushed to a microprocessor or plc as close to the actual hardware, as possible. That said In a small, localized environment, Qscada can be RT compliant, and in a larger environemnt one would use many QSscada servers with localized RT performance, reporting back to a cluster[6,7,8] of QScada servers that maintain the historical databases and serve up eye_candy for the operators and other such folks. We are proposing several security models. I like the SElinux approach, for many reasons (robust activity within the larger Gentoo Linux Community and since is was founded be the NSA, American based companies and goverment agencies are eagerly anticipating new SCADA offerings, centric around SElinux.[3] Emulators are an expensive way to maintain compatibility and capability. If a proprietary protocol is reverse engineered and the details spread widely across the net, those vendors will have little choice but to 'embrace' any number of open standards, because their customers will use what's available, especially if it is cost effective..... The proprietary nature of these vendor based protocols, is the weak link in all things related to SCADA. Join us? If you do, we become stronger and more capable every time an engineer or developer joins our ranks! Maybe after you company learns more about the group, they will be excited to have a 'team'? After all our best scenario is if companies sponser an employee to participate in Qscada to that it solves their needs and we diversify QScada. You would be most welcome. Your employer would be encourage, to send us ideas, comments and let us empower you Fernando, via QScada. My aspirations for QScada is that operating companies and utilities get behind QScada and help us develop this open-source family of tools and technolgies, known as QScada into a robust tool for all of their needs. >=20 > Thanks, > Fernando. sincerely, James [1] http://www.qt4lab.org/qt4lab/index.htm [2] http://www.soft-control.fr/downloads.php?&lang=3Den&PHPSESSID=3Db4f1b52ff= 75c34392f88957ee0f4ff41 [3] http://www.nsa.gov/selinux/ [4]http://www.lynuxworks.com/board-support/tews/tpmc901.php [5]http://ethernet.industrial-networking.com/articles/articledisplay.asp?= id=3D193 [6]http://openmosix.sourceforge.net/community.html [7]http://gentoo-wiki.com/HOWTO_Install_Mythtv_With_Diskless_Workstations= _in_an_OpenMosix_Cluster [8]http://openmosix.snarc.org/wakka.php?wiki=3DHomePage6 |
|
From: Iain B. <ia...@ne...> - 2006-11-14 00:03:33
|
Hi all,
here is an email from Fernando, with some questions and comments. He
found out about us by surfing the web, and I thought you might be
interested, or able to give him some help. I've responded already.
-------- Forwarded Message --------
From: Fernando Rodr=C3=ADguez Sela <fr...@le...>
To: ia...@us..., qt...@us...
Subject: About SCADA
Date: Thu, 02 Nov 2006 21:29:38 +0100
Hello,
I'm a Spanish developer who is working in a SCADA environment for an=20
Spanish chemical company and I'm developing it with QT4 under Linux.
Surfing in the web I found your project which it's very similar to mine=20
;) ... as soon as I finish with this I'll try to help you in some areas=20
of your project if it doesn't takes a lot of time (because I'm very=20
busy now) - If you need help in some area write me and I'll try to help=20
you ;)
Also, I want to make a little question about my project ... It's the=20
first time I work with PLCs so I'm a "Rockie" in this area :D ... My=20
main questions are:
1.- Is there any OMROM or SIEMENS emulator to test the SCADA=20
communications with it?
2.- Is there any library to communicate with OMROM (hostlink) and=20
SIEMENS (profibus?) in Linux? (no problem if it a commercial solution)
3.- Is there any good OPC for Linux? I saw a lot of it for Windows, but=20
I don't want to use it in a production enviroment and I prefer to use=20
the XML-DA protocol versus COM/DCOM ;)
My main idea of the project is a dedicated machine with Linux getting=20
information from all the plant PLCs and store all the sensors values in=20
a database (postgresql or MySQL), then the SCADA GUI will communicate=20
with the DB and show the information to the user.
My problems now are in getting information from the SCADA because I am=20
very far from the company so I need an emulator or something similar or=20
buy a developed environment.
Thanks,
Fernando.
--=20
Iain Buchanan <iaindb at netspace dot net dot au>
signal(i, SIG_DFL); /* crunch, crunch, crunch */
-- Larry Wall in doarg.c from the perl source code
|
|
From: Jovan K. <cho...@gm...> - 2006-11-13 23:21:24
|
Hi, HATS DOWN for you James. So many great ideas. > On 11/10/06, wireless <wir...@ta...> wrote: > Jovan: have you guys what tools/languages we should all install, to > work on Qscada? I need this info to begin recruiting coders and > testers. At first glance we need: 1. C/C++ I/O programming (serial port, parallel port, usb, IR ...) 2. C/C++ for industrial protocol programming (Modbus, CANBus, some PLC protocols...) 3. C/C++ Linux Kernel programming - for drivers for external devices (microcontrollers, PLCs...) 4. C/C++ QT GUI designers for design time and runtime GUI (examination of some scada systems is must: WonderWare Intouch and alike) 5. C/C++ QT widget programmers for widget libraries. We must create a template for the widget 6. C/C++ network and network security programmers 7. Web programmers (AJAX, XML, PHP, XHTML) for web based clients 8. Some pople with knowledge of linux embedded systems (RTAI, RTLinux...) 9. Database developers MySQL and PostgeSQL That's all that I can think of for now. I'll have to do better analysis. I hope I'll do that by the and of the week, but first we have to disccuss about the structure (building blocks) of QScada. > we need a software oriented person (Jovan?) Hey! I want to play with wires to :) It's fine by me if I'll be the software guy, but I'll play with hardware too ;) > I'll be the hardware guy > building an online playground for folks to hang out and articulate > QScada with actual hardware This is great idea. I see that you have good equpemnt. You should setup a QScada server and the clients will access remotely. It would be nice if there are cameras for every actuator so that the real life effects can be seen. The camera can send series of consequtive pictures or live stream video. The prblem would be colision in controls (two or more clients are accessing the same device) > we can put up QScada for google funding it as a 'Summer of Code' opportunity. Another one! That's all for now. Be well, Jovan |
|
From: Paolo S. <pao...@ya...> - 2006-11-13 12:31:51
|
Hi James,=0Aback in Italy, but still busy.=0AI=B4m here even if it seems I= =B4m diseppeared.=0AThanks for your help and effort=0Atake care=0Apaolo=0A= =0A=0A----- Messaggio originale -----=0ADa: wireless <wireless@tampabay.rr.= com>=0AA: qsc...@li...=0AInviato: Venerd=EC 10 n= ovembre 2006, 22:14:49=0AOggetto: [Qscada-developers] Exciting news=0A=0AHe= llo Everyone,=0A=0A=0A=0AJovan: have you guys what tools/languages we shou= ld all install, to=0Awork on Qscada? I need this info to begin recruiting= coders and=0Atesters. I have been invited to speak at a=0Alocal group that= refers to themselves as 'the 2600 club'. Mostly=0Akids and older (adult) k= ids that love linux. Hopefully there is=0Aand interest in controlling hardw= are and One of=0Amy ideas is to get embedded developers on board that are = familiar=0Aor willing to learn about embedded micro-controllers to we can i= mplement=0Aplc type functions on micros including but not limited to full= =0APID controls.=0A=0AIf you guys are ready, I'm going to propose to these = guys, who are=0Ainterested in accessing and controlling remote hardware, co= nsider=0AQScada, as a project of interest. Since Paolo is quite busy at the= =0Acurrent time, we need a software oriented person (Jovan?) to=0Akinda spe= ar head where we are going. I think iain is the admin=0Aand consumerate gen= too guru (grin) and I'll be the hardware guy=0Abuilding an online playgroun= d for folks to hang out and articulate=0AQScada with actual hardware=0A=0AI= hope to motivate the local (Tampabay) linux talent into this venture,=0Acu= lling through the masses and finding a few that capable. If we get=0AQScada= to a point and have a core team contributing, we can put=0Aup QScada for g= oogle funding it as a 'Summer of Code' opportunity.=0AOnce we have somethin= g to show, I'm going to start looking for=0Afunding, so some of the 'softwa= re guys' can focus on QScada on=0Aa serious basis.=0A=0A=0AI'm still bogged= down on the document I'm trying to develop, but it's=0Amore due to a lack = of time not lack of ideas. Hopefully, It'll be=0Adone next week as I have a= few days of slack time to finish the=0Afirst draft.=0A=0AOn another note, = I'll be getting a fiber drop from Verizon, in the next=0A30 days, so I have= to get (2) dns servers up and get ready to install.=0AIt'll be a multi meg= abit per second drop with about 5 usable(published/=0Aroutable IP address) = dedicated to QScada.=0AI'm leaning towards (3) hardened systems with SElin= ux(on Gentoo) and=0Aiptables/netfilter on the firewall and DJBDNS on the (= 2) dns servers.=0AHaving actual hardware for folks to remotely access to de= velop code on=0Aembedded linux controllers as well as PLCs, should be an at= traction.=0A=0AHere's a list of what I've accumulated so far:=0A=0A19"rack,= din rails large UPS=0A=0A(2) ethernet flat hubs, one unmanaged switch.=0A(= 2) Lantronix serial(232/485) to modbusTCP (ethernet) converters=0A(2) Newpo= rt serial(232/485) to modbusTCP (ethernet) converters=0A(2) Cyclades TS100 = serial(232/485) to modbusTCP (ethernet) converters=0A(1) Automation Direct = PLC 05 with 4 ch of analog I/O=0A(4) 24VDC power supplies=0A(2) bench power= supplies (current/voltage adjustable)=0A(6) video cameras (usb, ntsc, ethe= rnet)=0A(1) H.264 encoder (could use help getting the backend linux=0Abased= software to compile under gentoo (c/c++) sources=0A(1) TS-5500 (ethernet= ) running a 2.4 embedded linux kernel=0Ahas an AMD elan SC520 processor.=0A= http://www.embeddedarm.com/epc/ts5500-spec-h.html=0A(1) microchip MPlab ICD= 2 and a pikdev 18F456 chip w/ ethernet=0A(1) 8 port digi serial port expans= ion board.=0A(1) atmel AT91 dev board=0A(4) old 586 pcs we can used as embe= dded x86 based controllers.=0Awith serial and parallel ports , ethernet and= hard drives.=0A(suggestions on which kernel/rtos/linux to put on these=0Am= achines is welcome)=0A(1) usb-serial converter=0Ahttp://www.ftdichip.com/Pr= oducts/EvaluationKits/USB-Serial.htm=0A(1) CF writer, smart media writer an= d various support hardware.=0A=0AOn thing I'm looking for is a pci or pc-ca= rd based oscilloscope card=0Athat runs under gentoo, so we can capture wave= forms and display them=0Aover the net or convert them to an image so we can= send them to=0Ahardware oriented folks.=0A=0AI also have access to a prett= y nice logic analyzer, but cannot dedicated=0Ait to the project, only gain = sporadic access on off hours.=0A=0AI have a few discretionary dollars for a= dditional equipment purchases=0Aas warranted. Any soft of PLC's we can cobb= le together out of old PC's=0Aor purchase used PLCS would be keen. I need t= o start collecting sensors,=0Asuch as temperature, pressure, voltage, curre= nt, etc etc to have=0Ato interface to the water cannon.=0A=0AI'm also going= to rework my well equipment (pumps, water softener,=0Achlorine pump, UV li= ght) and 24VDC valve control so that it can be=0Amonitored over the interne= t with something that is qscada but looks like=0Athis demo:=0Ahttp://server= .scadabase.com/demo.html# (click the demo link) very cool!=0A=0A=0AI'm read= y to setup a development net for QScada, any and all=0Aideas are welcome.= =0A=0A=0A=0A=0A=0A---------------------------------------------------------= ----------------=0AUsing Tomcat but need to do more? Need to support web se= rvices, security?=0AGet stuff done quickly with pre-integrated technology t= o make your job easier=0ADownload IBM WebSphere Application Server v.1.0.1 = based on Apache Geronimo=0Ahttp://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D= 120709&bid=3D263057&dat=3D121642=0A________________________________________= _______=0AQscada-developers mailing list=0AQ...@li...urcefo= rge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/qscada-developers=0A= =0A=0A=0A=0A__________________________________________________=0ADo You Yah= oo!?=0APoco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da= tanto spazio gratuito per i tuoi file e i messaggi =0Ahttp://mail.yahoo.it= |
|
From: wireless <wir...@ta...> - 2006-11-10 21:15:07
|
Hello Everyone, Jovan: have you guys what tools/languages we should all install, to work on Qscada? I need this info to begin recruiting coders and testers. I have been invited to speak at a local group that refers to themselves as 'the 2600 club'. Mostly kids and older (adult) kids that love linux. Hopefully there is and interest in controlling hardware and One of my ideas is to get embedded developers on board that are familiar or willing to learn about embedded micro-controllers to we can implement plc type functions on micros including but not limited to full PID controls. If you guys are ready, I'm going to propose to these guys, who are interested in accessing and controlling remote hardware, consider QScada, as a project of interest. Since Paolo is quite busy at the current time, we need a software oriented person (Jovan?) to kinda spear head where we are going. I think iain is the admin and consumerate gentoo guru (grin) and I'll be the hardware guy building an online playground for folks to hang out and articulate QScada with actual hardware I hope to motivate the local (Tampabay) linux talent into this venture, culling through the masses and finding a few that capable. If we get QScada to a point and have a core team contributing, we can put up QScada for google funding it as a 'Summer of Code' opportunity. Once we have something to show, I'm going to start looking for funding, so some of the 'software guys' can focus on QScada on a serious basis. I'm still bogged down on the document I'm trying to develop, but it's more due to a lack of time not lack of ideas. Hopefully, It'll be done next week as I have a few days of slack time to finish the first draft. On another note, I'll be getting a fiber drop from Verizon, in the next 30 days, so I have to get (2) dns servers up and get ready to install. It'll be a multi megabit per second drop with about 5 usable(published/ routable IP address) dedicated to QScada. I'm leaning towards (3) hardened systems with SElinux(on Gentoo) and iptables/netfilter on the firewall and DJBDNS on the (2) dns servers. Having actual hardware for folks to remotely access to develop code on embedded linux controllers as well as PLCs, should be an attraction. Here's a list of what I've accumulated so far: 19"rack, din rails large UPS (2) ethernet flat hubs, one unmanaged switch. (2) Lantronix serial(232/485) to modbusTCP (ethernet) converters (2) Newport serial(232/485) to modbusTCP (ethernet) converters (2) Cyclades TS100 serial(232/485) to modbusTCP (ethernet) converters (1) Automation Direct PLC 05 with 4 ch of analog I/O (4) 24VDC power supplies (2) bench power supplies (current/voltage adjustable) (6) video cameras (usb, ntsc, ethernet) (1) H.264 encoder (could use help getting the backend linux based software to compile under gentoo (c/c++) sources (1) TS-5500 (ethernet) running a 2.4 embedded linux kernel has an AMD elan SC520 processor. http://www.embeddedarm.com/epc/ts5500-spec-h.html (1) microchip MPlab ICD2 and a pikdev 18F456 chip w/ ethernet (1) 8 port digi serial port expansion board. (1) atmel AT91 dev board (4) old 586 pcs we can used as embedded x86 based controllers. with serial and parallel ports , ethernet and hard drives. (suggestions on which kernel/rtos/linux to put on these machines is welcome) (1) usb-serial converter http://www.ftdichip.com/Products/EvaluationKits/USB-Serial.htm (1) CF writer, smart media writer and various support hardware. On thing I'm looking for is a pci or pc-card based oscilloscope card that runs under gentoo, so we can capture waveforms and display them over the net or convert them to an image so we can send them to hardware oriented folks. I also have access to a pretty nice logic analyzer, but cannot dedicated it to the project, only gain sporadic access on off hours. I have a few discretionary dollars for additional equipment purchases as warranted. Any soft of PLC's we can cobble together out of old PC's or purchase used PLCS would be keen. I need to start collecting sensors, such as temperature, pressure, voltage, current, etc etc to have to interface to the water cannon. I'm also going to rework my well equipment (pumps, water softener, chlorine pump, UV light) and 24VDC valve control so that it can be monitored over the internet with something that is qscada but looks like this demo: http://server.scadabase.com/demo.html# (click the demo link) very cool! I'm ready to setup a development net for QScada, any and all ideas are welcome. |
|
From: Jovan K. <cho...@gm...> - 2006-10-26 17:18:43
|
On 10/26/06, wireless <wir...@ta...> wrote: > QT is another area where I could use > a good book && examples to get a feel for QT.... Suggestions? Here is the download link for the best book on QT "C++ GUI programming with QT 4" torrent file http://www.ebookshare.net/2006/07/23/prentice-hall-ptr-c-plus-plus-gui-programming-with-qt-4-jun-2006-ebook-bbl/ If you buy a paper copy you'll get CD with all the examples Another great source is Trolls doc site: http://doc.trolltech.com/ then choose the version that you wanna see, 4.2 is the latest. Forums: Qt Centre, http://qtcentre.org Qt Forum, http://qtforum.org GREETZ, Jovan |
