May be in the wrong place.

[Archonis 0]

This post may be in the wrong place but im looking for some info. I work as tech support on automation control systems (Automate pool stuff) I also work with alot of creastron programmers who intergrate "Smart Homes" With our stuff using RS232/485. As a hobby I write software in visual basic. ANYHOW, In about 4 more weeks I will have my GED and I want to goto college and take PLC systems. Im not sure what they can do but they seems like they would be fun to work with and it would be alot faster then taking hardware and software eng. We have a system called the Intellitouch by pentair water, (Google it) Can PLC be able to do what the intellitouch can? Are you able to kick on and off relays, use dry contacts to call code, and send data to a indoor panel? Does PLC systems have the logic to talk TCP/IP? Thanks

[leonuce 0]

What I would suggest yuo is get your GED first and then go to college and take some Electrical and Computer technologies classes and at the same time take some PLC training classes at any vocacional school. Colleges and universities usually do not offer PLC classes, they offer some automatization courses where they include PLC but they do not cover that much. You can also buy some PLC training courses from ebay or Alan-Bradley and train yourself. You do not need a college degree to become a PLC technician but a college degree is a big help. I have not experience using Intellitouch but with PLC you can do almost everything in automation field. On the other hand, TCP/IP is a communiation protocol used to connect computers, printers and other logic devices including PLC. Good luck.

[brettshelley 0]

Yes, this is possible...

[Archonis 0]

Thanks for the help guys. I will be finishing up my GED here soon. Im glad to here PLC systems are able to kick relays on and off and is able to talk TCP/IP, RS-232. I will have to look into taking some classes and post back here to let yall know how im doing. One more thing. Whats the price range? I know this could mean alot but a basic starting kit. Also are we able to program PLC systems using C# or Visual basic? My goal here is to make a automation control system for my pool using a touch screen and visual basic for the GUI. The GUI would talk to the PLC system eather by internet or RS485/232. The PLC system would take that command and move a CVA-24 valve or send 15 volts down to kick a relay on or off witch will tie into my pool light or pump. My spa side remote would be nothing more then a dry contact (one wire touchs ground for a sec) Anyhow, Thanks you guys been much help

[panic mode 246]

This is not hard to say. PLCs are meant to do control of any scale automated systems. They can have any number if I/O points (inputs and outputs) from very few to few thousand. Most of them are digital but there are analogs, high speed etc. Communication options available on each PLC and dependeing on model it will be at least one or two ports (usually mix of RS232/422/485 or Ethernet). Price range (just a rule of thumb): 80-200 for "smart relays" and very small PLCs (usually 6-10 I/O or so, some can have more or be expanded) 300-3000 for small PLCs (up to some 200 I/O or so) 5000 and more is "normal" PLC (I/O limit somewhere in 8-16 thousand I/O, they are always modular and actual price will depend on configuration - number and type of used I/O etc.) normal processor is in the $3000 range (but as always there are special versions like safety, motion etc. then there is bigger brother called DCS so basically sky is the limit). 16pt digital I/O cards are in the $200 range (32pt is about double), 4-8 analog chanels is in the $1000 range, each additional network card is in the $1-2k range etc. you do the math... this is why there are specialized solutions for certain (common) cases - to bring the cost down. i don't know about starter kits, never had one. they should be in the 500-1000 range for small PLCs. now what kind of pool automation we are talking about? how many I/O? (one pump with one or two button). what is common voltage for I/Os (PLCs tipically use 24VDC - OR an AC such as 120/240VAC depending on country but i'm sure you don't want to do those). I hope you know what are you doing, it's scary to read things like these in same post: a) experimenting with controls, "15 or 24V or whatever", "just connecting things to ground" b) pool (people in water) I'm thinking you don't want to make Sea-World in your back yard or control fountains in Vegas so you are probably after something really small, preferably with front end (could be as simple as few buttons - maybe as small as FP-e by Panasonic).

[paulengr 44]

VBA for a GUI is a pain in the rear. It's not bad but the Microsoftian bugs drive me up the wall. I get calls on basic HMI's (no Microsoft crud) maybe once a year because a key is worn out or they literally torched the thing. I get calls for PC related stuff 3-6 times per week. 95% of the time, it has nothing to do with the HMI...just another Microsoft bug crashed it. Err, excuse me. Another Microsoft FEATURE. In addition, VBA just loves to play well with others...NOT! Interfacing is another thing that it really, really doesn't want to do well. C# is even worse. If you want to do anything aside from interface to Microsoft SQL Server or other Microsoft server-based systems with C#, prepare for a serious uphill battle. I can't really think of any PLC that uses C# or VBA for a language. For one thing, neither one of them are "real time" in the classic sense...most people wouldn't want to have to reboot a PLC controlling a large machine with blades attached or large motors/hydraulics/pneumatics careening out of control because Windows decided to crash with a blue screen of death again. The whole idea is that you install a controller that has a life span of maybe 10-30 YEARS without a crash, EVER. This automatically removes ALL Microsoft platforms from the running, which are designed to be rebooted at least once per week. OK...you want something inexpensive. I'd highly suggest then taking one of two approaches. If your goal is to learn I/O interfacing, then buy an I/O board for the PC and do it all on the PC. There are several different ones available from B&B Electronics for this purpose. If you want to try doing it the "PLC-way", then get a standalone I/O card such as the ones from Acromag which speak Modbus and stick with Modbus protocol on your first time out. The protocol is so simple that you really don't need canned software to write your own interfacing...which is a good thing in this case. This approach will set you back about $500 or less. Everything will be in the PC world. Interfacing will be either RS-485 (for standalone cards) or PCI. If you want to go the PLC route, then first I'd highly suggest you get rid of the PC/PLC interface first thing. There are a couple choices here. First, you can go to automationdirect.com and take a look at one of their combination PLC/HMI's in a box. Same thing with ezautomation.com. A third option is to consider using an Allen Bradley Micrologix 1100. The neat thing about these little PLC's is that they have 10 inputs, 6 outputs, 2 analog inputs, and a programmable LCD screen all built into the PLC for around $500. The others will set you back about the same amount. AB hardware is bullet proof and you'll be learning the details of dealing with one of their most popular programming platforms along the way. The killer is that the SOFTWARE will cost about 4 times more than the PLC! I believe that they do have a "starter kit" though for another Micrologix for about the same amount of money. The downside is that the 1100 series is the only one with an LCD display built in. Finally, if you want to follow your original goal, then either go with the starter kit I mentioned from AB (it's listed as a pinned item on the Allen Bradley forum) or go with Omron. Omron PLC's are just about the right size for your intended project, they are a major product line, and they are very inexpensive little PLC's to work with. About the only thing you're not getting with any of these is "C# or Visual Basic" programming. There are six ways I know of to do anything that silly. First off, you can go with Beckhoff's software PLC. This thing does allow for just what you suggest. Supposedly it is armored up well enough to survive allowing Microsoft Windows to reboot itself while the software PLC stays intact. However, I've never worked with one on a real system for any length of time. I downloaded all the requisite demos and such at one time and came up with just one opinion: interesting. Second, you can go with softplc.com. These particular PLC's are highly programmable in very nonstandard ways including developing your own code in Java which can call/be called from the PLC side of things. You are basically getting an AB-knock off PLC that can interface to just about any hardware out there that runs on top of a real time version of Linux. Because of this, you get all the standard Linux stuff for free, and it includes a reasonably easy external programming interface as well. Third, at least Allen Bradley (and probably others) sells various "PC on a card" type things which allow you to have something of a PC resident on the PLC chassis. I'm not sure what the Contrologix version would be but on the PLC-5 platform you could use either a 1771-DMC or a 1771-BASIC module. I have gotten as far as studying these things in depth because both of them were in my plant a couple years ago. I've gotten rid of all of them except one DMC module. Be prepared...these things are not for the faint of heart. They are fairly straightforward to work with but they serve a niche market where the goal is to bring the power of a PC on board for some sort of specialized signal processing/control that a stock PLC just can't do easily. It's similar to dealing with motion controllers...they are a necessary evil for certain applications. Fourth, you can write the code on the PC side and just deal with all the handshaking mess. There is something akin to this in my plant. The final alloy additions for making molten iron (foundry operation) require some calculations based on the lab analysis of samples at various points in the system which are stored in a database. The enthalpy math to do the calculations is fairly nasty. Except for the direct database interface, this is all doable in the PLC. However the guy who did it chose to do it in the SCADA system since that system had to provide the database interface anyways. Fortunately the response time only has to be about 10-30 seconds and if it misses a cycle or two, it's not the end of the world. So, in this application, the term "real time" does fit. The way it works is that the PLC raises a "ready for an update" flag. The PC polls the flag. When it sees the flag go up, it reads the database, runs the calculations, and then raises a "data ready" flag back to the PLC. When the PC sees the update flag clear, then it clears the "data ready" flag and waits for the next cycle. All of this activity occurs through the SCADA system's "point" or "tag" database (depending on your terminology). The interfacing is taken care of by the SCADA. I'm not recommending this solution for your case because the SCADA software is vastly overpriced for the project. Fifth, and this may not be what you expected, most modern PLC's nowadays support several languages, including one called "structured text". This language doesn't really trace its roots to any particular PC language but it kind of vaguely reminds me in some ways of a mix of BASIC and Verilog. It was designed specifically more or less to allow traditional PC programmers to work with PLC's. Just look for the key words "structured text" when you go PLC shopping. This is an IEC 61131 standard language, so it is supposed to be identical from one vendor to another (and it generally is identical). All the languages you mentioned are vendor specific and highly nonstandard. Finally, you can skip the whole PLC/PC thing altogether and go with Verilog (C-based) or VHDL (Ada-based)....in other words, do it all in an FPGA. At this point in the world, you can do some amazing things. I've seen downloadable code in the internet that will directly drive an LCD screen. The I/O pins of the FPGA can almost be directly connected to the LCD panel without any extraneous hardware in between. I/O at sub-microsecond speeds is obviously not only doable but it's where this type of code lives...you will be working at hardware speeds. Costs can be anywhere from <$100 to $thousands depending on the software. Several vendors offer "starter kits" that include an FPGA already prewired onto a board with something similar to the terminal blocks that you'd be seeing with the PC/PLC solutions and a cut down version of their standard software package. Atmel in particular comes to mind. Once you develop your application, you can probably produce additional copies of it for <$50 depending on how much time and design work you spend on it. If you don't want to go quite to bare hardware level but still want to do something similar, Rabbit semiconductors, Parallax, and Micromint, make some pretty nice embedded hardware packages that are programmable in BASIC or C. This is the world of embedded systems. You will be working with extremely low end CPU's. They are very inexpensive and you can buy LCD screens, keypads, etc., premade, or make your own. They can frequently do all the interfacing you want in either direction. Embedded controllers sort of straddle the PLC/PC world. Head on over to mouser.com for a catalog as well as the vendors to get an idea of what's available in this category. The available hardware and software options are very deep. In the embedded world, the BASIC stamp from Parallax may be just what you are looking for. This sucker is barely a CPU. It comes on a board about the size of a large postage stamp. It has about 8 I/O pins with TTL-level (0/5V DC) interfacing. It has a connector on the stamp for a 9V battery and a small on board power regulator. You program it from a PC on a 4 pin connector using a very odd (even more odd than VB) version of BASIC. Stamps have several optional boards that you can attach including Bluetooth, Wifi, LCD screens, etc. If you want something with more power, consider either the Rabbit boards I mentioned or go up to the ultimate, the Linux-based Gumstix processors (www.gumstix.com). These are fully blown "Linux on a strip" systems with several expansion boards. They can even speak Ethernet. In this case, you've got the full power of whatever language you want (C, C++, Java, BASIC, etc.). You can either attach an LCD/touch screen to it (see the web site) or else you can just use an on board web server and do it all via a web browser. Think cell phone/web browser interfacing..."yeah, discussion over dinner sounds great...hold on, I'm just scheduling the spa heater so that it will be nice and cozy when we get there. I should shoot over to Netflix and download something to watch afterwards, too. We'll make it dinner and a movie."

[Nathan 7]

Paul - I'm certainly not going to match your 1900 word posts. Your advice on avenues for OP to learn are sound. About your "Microsoftian" rave, what gives? I'm not a big fan of VBA either. On the desktop support end, why are you running Windows if Linux is so much better? It's my impression that studies have resulted that large organizations, in practice, often times don't save money, time, and effort with Linux over Windows systems. This is true on the server and client end. In my experience as an admin, of both flavors, users can break either. It comes down to how well you've set up their system for remote administration, imaging, etc. About the programming, you have to get more specific - your paragraph is practically meaningless. But I absolutely agree with you on steering OP away from learning software programming languages to learn PLCs.

[Clay B. 1]

First off. Good luck. Lots of people get "in", not many stay. I agree with the post that the first thing you need is a strong electrical training program. If you do not understand what your programing then programing is useless. I do not mean you need to learn the componets of a PLC. But know if the circuit is AC or DC is really a plus. As for the project you were describing. What paulengr posted should help. You will probably have to do some research on your own to understand everything he went over but that is part of it also.

[Archonis 0]

Thanks for all that info, I got most of that on the first read over. Being a good programmer watching data and writing code is not a problem for me. Thanks for all the help. jimmy

[paulengr 44]

I'll save the Microsoft rant for the bottom. For "Desktop support"...agreed. You can't really beat a Windows/Office based system right now. Depending on the application, there are areas where a Linux based system blows anything Microsoft has to offer out of the water. Examples of software applications that are very good are Apache, PHP support, JBoss, Netbeans (or Eclipse), Open Office, Gnome, MySQL, Firefox, MythTV, the POSIX libraries, and Beowulf clusters. In fact, the Microsoft equivalents of all of these except arguably Open Office are not even close to the same level of quality, support, and reliability. Part of this is predicated on using a good Linux distribution. With Microsoft, there is only one distribution. With Linux, there are many, many distributions, some good and some really bad. Some of the better ones such as Gentoo can be on a single DVD. When you start up, you simply select what software you want and it downloads and installs the applications right over the internet. Even Microsoft application installation isn't that simple. Where a Linux/BSD system works is when you have good quality, stable hardware, and you need to deploy a system that "just works" without any strange glitches or crashes, and where Microsoft Office (desktop) support is not needed. This means servers running high performance or "commodity" based applications, such as E-mail servers, databases, web servers (and web-based applications), file servers, and SCADA systems. SCADA support for non-Windows environments right now really stinks with few exceptions so there's one simple reason to make the Windows/non-Windows decision. If you are intending on running Microsoft-based authentication servers, Microsoft Exchange servers, Microsoft SQL Server, and so forth, then the advantage is decidedly tilted towards Microsoft Windows. Just plan on living with a less stable server. I'm not particularly a fan of Linux. Or BSD. Or Microsoft Windows. Or whatever Apple is calling their operating system these days. I'm a maintenance/engineering guy. In my point of view, these are all more or less equivalent systems. Sort of like shopping for a new car. Each one has it's particular bells and whistles as well as issues. So I want to buy the best one for the application, regardless of the vendor. I'm not a "Ford" or "GM" or "Dodge" or "Toyota" guy. I have owned all 4 in the past at some point for various reasons. However, one of the basic principles of troubleshooting is root cause analysis. You can't do RCA with Microsoft Windows. There is a two step solution to all problems: (a) reboot the machine, and if that fails, (b) reinstall Windows. Can you imagine what would happen if every time a PLC crashed, the first response was to (a) reboot the PLC, and then (b) reinstall the firmware? And that if you didn't do this at least once every 7-30 days, your plant would suddenly lock up, potentially in a dangerous state? Never mind the fact that about once a year, you would be forced to essentially pay for new PLC's on every piece of equipment because without the latest and greatest firmware and hardware, you couldn't even run current stuff, never mind old equipment? Second, I'm not a "Ford" or "GM" or "Dodge" or "Toyota" guy. I buy whichever one provides the best product for the price at the time that I'm in the market. However, I wouldn't expect to buy a "car chip" for a Ford and expect to put it into a GM vehicle. But Windows users expect that the exact same hardware that works on Windows should work on Linux & Apple machines and totally ignore the lists of what hardware is recommended out there. If it's good enough for Microsoft, it's good enough for everyone, right? Bet you install Ford car chips in your GM vehicles, too. Out on the plant floor, again, the issue is one of stability. The primary reasons that SCADA and HMI software haven't dethroned hardware based operator interfaces is three fold. First, most SCADA vendors charge almost more for their software licenses than the hardware (Indusoft is changing that). Second, there is an expectation that uptimes are measured in years, not days. You can't have a machine careening out of control just because of a software problem on a routine (monthly) basis. And people involved in that side of the business fully expect to be able to apply root cause analysis. And if RCA says it's the HMI/SCADA, regardless of whether it's a hardware or software issue, you can bet that the equipment is getting ripped out and replaced with something more reliable or at best, relegated to a "supervisory" role (not direct machine control). So at that point since it performs a more or less redundant function, again, you're fighting an uphill cost battle. It doesn't matter whether the crash/bug is caused by the HMI software, the operating system, or the hardware...the end result is the same. As an example, I have roughly 25 Panelview STANDARD operator displays still sitting in my plant operating simply because AB chose lower grade hardware and runs a rather buggy version of their HMI software on top of Windows CE for their newer Panelview Plus operator panels. In spite of the fact that the panels are a good deal less expensive, the plant will spend far more time and money on debugging hardware and software problems almost every time we've tried to install one. The HMI/SCADA system has roughly the same problems and the same result. In this case, it's not the SCADA software that causes all the problems. It's clearly Windows, as far as I can tell whenever I attempt to do RCA on it. If it wasn't for all the additional advantages (charting, better graphics, plant/office interfacing), it would suffer the same fate (removed and replaced). Linux works great as for instance an RDP client. All our thin clients are actually running Linux off flash drives. The manufacturer (Neoware) said that they have an order of magnitude more calls for problems with Windows and a lot more stability problems. In short, Linux just works without any issues. I'm in the process of deciding now whether to try to continue on the current path and just upgrade to better hardware (hard drive free, "HMI on a jump drive" type configuration) or switch to a thin client system, where I have roughly the same identical hardware on the floor but I can reboot the "PC" any time. As to the "support" argument...it's weak at best. There are two separate issues here. First, the customer support issue. If you expect to be able to call someone and get your problems solved, good luck. Those customer nonsupport numbers are all the same. You call. They tell you in excrutiating detail how to reboot your machine. Then they walk you through reinstalling the OS, then all the software. Then finally they admit that there's a problem but can't help you. You go to "Level 2". Same process all over again. In the end, it must be "referred to engineering". After 2 weeks of "we're working on it" E-mails, the E-mails stop. Then about 6 months to a year after you've already switched to some alternative or worked around the problem, they issue a bug patch. And sometimes it works, sometimes not. This isn't support. This is called giving you a run around. By the way, you can get software with customer nonsupport numbers for Linux applications, too. All the ones I mentioned earlier have those numbers if you pay for a copy. The turnaround times on bug fixes though are generally shorter. Now, on to the problems with the programming interfaces. First, some general comments. I've lived with a VB-based environment for SCADA programming in the plant I'm at now for 3 years. I previously had experience way back in the first couple years of RS-View 32. So I've been around the block and I consider myself pretty adept at getting around in VB and VBA. Here's my beef with Microsoft's programming interfaces. With VB, the one shining light is the fact that it's the de facto programming language for Microsoft Office. It's somewhat like using the UNO interface under Open Office or the strange world of XPCom under Firefox. In all 3 of them, you can pretty much do anything but be prepared for something of an uphill battle. That's the good news. However, anything not supported under those interfaces natively becomes a serious uphill battle. For instance, it took me the better part of a day of searching the internet before I finally found something as simple as a TCP/IP driver that didn't cost about as much as installing full blown Office on every machine that it would be used on. If you try to develop on your own, you'll find that all the handy tools such as charting, TCP/IP drivers, and such, DISAPPEAR the moment that you try to create your own plugin for Office to support a VBA application. Or that you have to install Office on plant floor machines just to provide a simple charting function. Finally, there are many things that you "can't do". For instance, try to run Internet Explorer in "headless" mode (without a screen). Why would you want to do this? Because somebody wrote an interface to a web server that requires you to execute a command via the GET interface in HTTP. Sounds great until you try to schedule it to run without anybody logged in. I can do it with everyone else's web browser. Except that the same web server I'm referring to also chose to detect IE and to run ONLY on IE and nothing else, in spite of the fact that it's a JAVA based system! No names for you to guess which competition to Indusoft did this one. If Office is NOT installed, and you are programming in pure VB, be prepared for a few problems. Mostly, plan on spending about $1000 per machine to be able to deploy your software or more. There is no decent grid, nor any chart/trending interface that you don't pay for on each machine that it is deployed on. You can't even get a serial driver without loading every machine up with a licensed version of VB as well. Thanks all to ActiveX. So that's my beef with the basics of Microsoft's programming interface. Even in-house developed software can trivially cost more than a single license of Indusoft's entire HMI.

[Archonis 0]

You made some great points there and alot of good learnings but I have to dis-agree with you on a few things here. When you talk about programming I go CRAZY! 1) COM is not so hard to work. If you understand it then your good to go. Most get confused on pin out and change overs. (RS232 to 485) All incoming data will be in ascii so you would want to convert it to hex so you can work with it. A basic VB statment would be something like this. if 0x03 then whatever or dim indata as string. if indata = "0304083B5C6038B60000098364B76FF" *door is open or light is on show the image or make the change end if if indata = "FF746262983463256289473EE" *something else happen and it reported it back to the pc end if well enuff of that. second, what does vb have to do with office? Altho I do have to agree with you on the LINUX thing there being that its open source. maybe its that I have not worked with PLC systems so I have no clue how they think. but, in the computer work its eather on or off Once again, thanks for all the info. I cant wait for college in the next few weeks.

[Clay B. 1]

PC to PLC have all kinds of nasties. Most come from comunication. Something you will have to learn about a PLC is it runs a scan. that is how it excutes its program. PLC in a somewhat simplistic terms. There is more to it but below is the basics Start of Scan= Check Input image Process program= Here is where the PLC basically takes what it get from its Input register and figures out what it needs to do Update Output Image= Turn on the Outputs that need to be turned on, turn off the Outputs that need to be turned off..etc Housekeeping= Send your messages out your various com ports. Check your watch dog timer , do your check sum compare Go back to top PC in somewhat simplistic terms Wait for an event, act on the event But that is not really what Pauleng was refering to. What he is refering to is really time. In the the PLC world time is everything. PC world not so much. In the PC world if a process takes a few extra mil seconds to process no harm no foul. PLC varies by a few mil seconds and things go BOOM. When a PC locks up you may loose your high score you just made on your video game or loose that last block of data you where putting into your excel spread sheet. When a PLC locks up you know the first thing that will happen is all of your outputs are going off. And trust me when I say that is a real handy thing to know. Also PLCs have several built in safties to know when they have gone bonkers. Plus you have the ability to configure several things for just this type of issue. PCs are expected to last 2 to 5 years. PLCs are expected to last decades. PC to PLC interfaces have inherent risks period, no matter what software you use. Just look at it this way. Would you trust a PC with windows to control the gas and brake peddle in your car? What would you do if the PC locked up. Will the gas let off? Will the brake engage? How fast will the gas left off if it does? How hard will the brake engage? Me, I think I will stick with my foot. In an earlier post I said learn what your working with before you program. It is the best advise I can give. Do not just think about what will happen if everything goes right you have to also think about what is going to happen if everything or something goes wrong. In the PLC world a second is an eterinity. Do some research and you will see what drives Pauleng to write such a monster post.

[paulengr 44]

In a PLC, that "on or off" concept is even more tight since they work directly with real world hardware. In a PC, the correct phrase is "eather on or off, whenever you get around to it, assuming the OS hasn't crashed, there are no major CPU sucking or hard drive sucking programs running, and whatever viruses are running are not causing any major damage right now". That concept simply doesn't fly on a PLC. It HAS to be on or off, within a defined period of time. Or in a defined fault/error state. No in betweens, and no wishy-washy "best effort" concepts. There are distinct design differences stemming from a difference of concerns. In a PLC, time is usually measured in milliseconds. As in if something doesn't happen within a certain number of milliseconds, the machine could destroy something/someone or itself, or produce defects that nobody can seem to solve even from a momentary glitch, or produce hundreds of tons worth of scrap product. A PLC "model" is designed to operate for decades. As in there are still Allen Bradley PLC-2's from the 1970's functioning today and the owners are scared to death of changing them out for fear of what sorts of bugs could crop up. Every time before a program gets run (sometimes once per scan where scans are a few milliseconds), the program is checked for errors. If even one error shows up for any reason or any self-checks on the hardware fail, the program gets jettisoned. In a PC, time is measured in "user doesn't have to wait so long that they get too bored" units. If something takes an extra second or two (or minutes), no harm, no foul. An individual PC is built to run until the warranty expires plus maybe a couple years. By then, the OS will require even more processor resources and you can tell the user to "just upgrade" again. Any old code will work and there is frequently little to no error checking...hence part of the reason that system failures are all too common. It's probably not impossible to create a PLC virus but it probably isn't easy either. Those thought processes on the PC side are not only culturally alien in the PLC world but downright unsafe.

[ssommers 20]

I'd keep away from VB for the actual control screen. If you want to do some kind of remote monitoring, it may be ok, but you'll have a hefty investment in software that goes obsolete faster than your PC. A simple little HMI (Human Machine Interface) with a touchscreen that is purpose built for PLC control is often cheaper & easier to program. Check into Maple Systems Silver Series 504T. NAYY, but I am a happy customer. Congrats on going for your GED and may you find a good electrical training program!

[Archonis 0]

Thanks for all the support, Its hard to find a good place on the net with REAL users that are willing to help anyone. Thanks