Quo vadimus

J

Thread Starter

Jiri Baum

Hello, I showed the article draft to Petr (my father), just in case there's something all of us that have read it a dozen times are missing, and he really only made one comment: quo vadis - in what way do we mean to compete with PLCs? I'm not sure we're all that clear on that ourselves... Apparently it shows. On the one hand, PuffinPLC is currently heading toward being programmable like a PLC, but an industrial PC plus I/O hardware will end up being more expensive than a medium-class PLC and therefore non-competitive. On the other hand PuffinPLC could compete with the likes of Labview or Citec, which run on the same platform and therefore have the same restrictions, but development on that front is currently non-existent. So... quo vadimus? Personally, I think we should get ourselves a programming language or environment in the direction of Labview/Citec/whatever. Or perhaps modules to do SCADA. We still want stepladder and the IEC languages - partly for flexibility, partly so that the one solution can be used factory-wide - but only in the more advanced languages will we have a serious advantage over PLCs. Opinions? Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi, Hopefully some of the 'competitive marketing' points below will be of use to you. In general the first market I expect to be taken over is education. Right now the hardware/software vendors do try to reduce prices for schools. But the difference in price is so large that it is not possible to supply the latest and greatest to the students. But the PPLC will be free - and will run on 'obsolete' PCs - the parallel port will provide a nice IO card. This is a great place to start because - students will learn to use the PPLC - they will develop some modules - they will test the software in ways nobody in industry would ever consider. And, when they graduate, they will be comfortable suggesting it as a option for a controller. The second major market penetrated should be system integrators. This will be a great option for companies using PPLCs in small run product design - such as industrial dryers, etc. They will also be very attractive to developers doing unussual designs - notably network enabled applications and with features not currently offered in other controllers (how about a Palm pilot interface). Finally, major developers will offer this as an option for their hardware. - It is evolutionary/revolutionary - The Puffin PLC represents the next generation of controls, it doesn't compete directly because there is no equivalent system right now. The current systems are closed and programming always occurs through a given interface. For example, Labview, mentioned in Rufus' email, does allow C/C++ programming, but it still doesn't allow the users inside to change core functions. But, the PPLC it can be integrated with any software, such as databases, at the users whim. - Free - It will be easy to adopt because of price, just like the large companies tired of paying for Windows (IBM, Dell, etc...). - It will easy development of new controller products - By working on commodity hardware, the PC market will develop better hardware at a faster rate and lower cost thatn is possible by inhouse developers. So right now a uCsimm module is $US250 with enough power to compete with a $US1000 controller. - Competitive developers can get a headstart - Unlike proprietary systems that are developed in secret, the development code is open and downloadable. This means that companies and individuals that want to use it can do so well before a full release. - The users have a direct contact with developers - As with other open-source projects, users can influence development. Even more important, they can interact with the developers. How many times have you called a help desk knowing exactly what the problem is and not been able to get past the recent graduate asking you to check the grounding? - More powerful than most controllers - By using features found in Linux, the controller can embrace functions such as being a server (web, database, etc.) And, support multiple programming languages, from good-old-C to any of the dozens of other languages. Hugh _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Campbell, David (Ex AS17)

> Hugh Jack wrote: *snip* > But the PPLC will be free - and will run on 'obsolete' PCs - > the parallel port will provide a nice IO card. Could someone take a quick look at the lp driver in the kernel? If it still has my name on it then I will quickly through together the stuff required to make this a reality (complete with circuit board design if required). I need to check but the old brain dead parallel port is capable of 5 inputs and 9 outputs. The bi-directional version (with a little circuitry) is capable of a LOT more. Could people please check their local electronics shops for any kit form interfaces, here is one with 8 Inputs / 8 Outputs for about USD$30 (serial port, can be daisy chained). http://www.altronics.com.au/cat.asp?cat=11&grp=424&id=K+2850 For the parallel port (8I+8O, again approx USD$30) http://filemaker.webfactory.com.au/DFX/jaycar/FMPro?-db=products.fp3&-format =detail.htm&-lay=cgi&-sortfield=model%20%23&Category=KITS%20-%20COMPUTER&-re cid=39428&-token=12681066&-find= For USD$17 you can build your own stepper motor interface: http://www.altronics.com.au/cat.asp?cat=11&grp=424&id=K+2835 For USD$25 there is a kit for 24 I/O lines: http://filemaker.webfactory.com.au/DFX/jaycar/FMPro?-db=products.fp3&-format =detail.htm&-lay=cgi&-sortfield=model%20%23&Category=KITS%20-%20COMPUTER&-re cid=39402&-token=12681066&-find= David Campbell PS: Pricing is approximate, and soldering iron not included :) _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri's letter is making me stay up past my bedtime with this response: If all the PuffinPLC project was was a way to program standard PC-compatible hardware in a PLC compatible manner with PLC attributes and mentality, I would not be here. I think the ripples created once a full system (Development System, Target Platform, Program Language, I/O, and User Interface) are established are even more significant that the event. My quest started years ago, when I was looking for the opposite. I wanted PLC quality hardened I/O and all-in-one form factor (power/cpu/io), but programmable in higher level languages with higher level interfaces. I wanted multiple serial ports, hard drive access for journaling, and a peer to peer network so I could do distributed control. The actual mechanical control might be say, 8 inputs and 4 outputs, compatible with almost any of the little lunchbox plc's. Say $200-$300 ea. But as soon as we added a serial port, the PLC became $1200-1800. Add networking, raise to $2500+. Each. (and I think the passage of time has made those numbers shrink because I do remember numbers in the $5000 range) And that still had no operator interface (oops, did I forget to mention that?). Part of the problem is the equipment I build isn't merely a process that has to do the right thing at the right time, but there is a large data component which PLC's aren't really designed to handle. ------------------------------------------- At one point I was seriously implementing Steeplechase software with Profibus distributed I/O modules (sacrificing actual distributed logic). Profibus at 12 Mhz could update all the I/O in my machine in under 2ms. The logic solve was a screamer (flowchart language) and they were just fine-tuning their RLL language. It ran on a Windows NT PC box, so serial comms and networkability, and hard drive access was all there. As well as being able to run Windows programs alongside. It also had Intellution's FIX HMI at the time which was cool, too. The visualization tools and the logic solve editor shared the same I/O tag database, which was not a common thing in other similar systems of the time. One major downside was the cost of the software, based on individual "Run Time" licenses, was over $3000/machine if I recall correctly. which, for our machines, seemed a lot for someone from a programming background used to buying compilers but being able to copy my resulting code as many times as I chose. Not to mention the fact it exceeded the hardware cost. ----------------------------------------------------------- Some PuffinPLC ultimate goals are deal-breakers for some (on-the-fly changes, IEC 6113-1 programming languages) but have little interest for me. However, acceptance by PLC users will just lead to better, cheaper hardware for the platform. And I know it's already compatible with most office and desktop hardware, which has already gotten better and cheaper due to the PC. Being Linux, I know it will keep pace with hardware innovations. High speed Ethernet connectability is already in there. Multiple serial ports won't cost an arm and a leg. I'll be able to program in languages of my choice. RLL, C++, BASIC, Forth, Fortran, Pascal, ADA etc. (I am curious about Borland's Kylix) It's getting too late for me to remain coherent, goodnight... ( The point of which is, Jiri has a good point, that without SCADA and languages, PuffinPLC won't have the draw its going to need for acceptance over "old school") In a message dated 3/4/01 9:54:30 PM Eastern Standard Time, [email protected] writes: << Subj: LinuxPLC: Quo vadimus Date: 3/4/01 9:54:30 PM Eastern Standard Time From: [email protected] On the one hand, PuffinPLC is currently heading toward being programmable like a PLC, but an industrial PC plus I/O hardware will end up being more expensive than a medium-class PLC and therefore non-competitive. On the other hand PuffinPLC could compete with the likes of Labview or Citec, which run on the same platform and therefore have the same restrictions, but development on that front is currently non-existent. So... quo vadimus? Personally, I think we should get ourselves a programming language or environment in the direction of Labview/Citec/whatever. Or perhaps modules to do SCADA. We still want stepladder and the IEC languages - partly for flexibility, partly so that the one solution can be used factory-wide - but only in the more advanced languages will we have a serious advantage over PLCs. Opinions? _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Thread starter Similar threads Forum Replies Date
J LinuxPLC Project 0
Similar threads
parport (was: Quo vadimus)
Top