RichWargo

Yes, indeed S7-200 PC Access is what used to be sold by MicroComputing. I am using it on a project to collect opacity data from a boiler via Ethernet to a CP243 on the S7-200. The only glitch, and it is a major one for me, is that if you are transferring the registers from the PLC to the PC (sampling) slower than 10 seconds between samples, PC Access doesn't recover if the Ethernet link goes down. The data quality gets set to "bad" as it should, but doesn't get reset to "good" when the link gets reestablished. If you sample quicker than 10 seconds, it works fine. I am in communication with Siemens Tech Support on this issue. Am using it with FasTrak Softworks' FTlogger (sample time 6 minutes) for regulatory opacity reporting. Otherwise, works fine.

Well, I did contact Charlottsville, and did get directed to download an SP file for CimME. Didn't address my problem and finally, through much downloading, did get vertical bars to display properly, so I stopped there and called it done. Quite frankly, I think GE in general and GEF in particular has descended into the black pits of apathy when it comes to customer problems. The personnel only seem to care about positioning themselves relative to the newest company initiative, be it Six Sigma, SII, or whatever. I suppose GE thinks it can generate sufficient sales just selling to itself.

Let me see if I understand this. You want to repeatedly fill bottles with a measured amount of a liquid. You want highly repeatable accuracy. One way would be to use a piston injector with a calibrated volume equal to your desired amount. As an example, check out the following: Oil-Rite new product I have no experience with the above referenced vendor, but provide this as an example. Another would be to use a small positive displacement flowmeter; then count off the pulses, closing a solenoid valve on target reached. You might try finding an on-line packaging or medical equipment magazine, and posting requests for more information there.

Had a funny happen to me. Existing 90/70 (model 772, I think). Finally got proper cabling from GE to connect QuickPanel (10.5" color). Only took 'em 3 tries. Am displaying vertical bars for motor speeds from six variable speed drives. Using Genius I/O, no issues getting values into PLC. Genius blocks are scaled 0 to 10000 for 0 to 100 percent, signed integers, so negative values are possible (and do happen). Define vertical bar scaled 0 to 10000 with 2 digit decimal (so shows 0.00 to 100.00 percent). Normally 0% at bottom and 100% at top. Sometimes, and it appears to happen randomly, the vertical bar scale will flip, so that 0.00% is at the top and 100.00 % is at the bottom. This occurs only when the QP is online and communicating. Also sometimes occurs even after I set display scale to -10.00% to 100% (give some room on the bottom end). Scratching head, won't bother GE with this, because they have enough trouble understanding light switches, much less something this complex. Besides, this will be quicker than calling them. I remember when calling A-B was painful and GE Charlottesville was wonderful, could get a hold of actual developers. Now, Charlottesville support is hideous, and A-B has improved immensely. Even though Cimplicity development is local (here in Albany NY.) I get whined at if I try to backdoor GE's system and contact the developers directly, even though I know a few of them personally.

I agree with Jim. E-stops should kill ALL the power, including control power, hence no lights. Safety issue. Would rather physically check all e-stops for a machine, than have stray voltages running around. I seem to recall someone made an E-stop that had a mechanical color change, i.e., a different color would be mechanically pressed against the button when the button was operated. That would be preferable to an electric light, LED or otherwise.

Generally, to conform with NEC, there must be a metal barrier between the high-voltage section and the low-voltage section. Think of it as an extra-wide enclosed cable tray. You can run high and low voltage wiring in the same cable tray, but must be segregated and separated by a grounded metal wall (to limit RFI). Most of the time the metal partition is created by using separate, but adjacent panels for the high-voltage and low-voltage stuff, with interconnecting low-voltage wiring through a grommeted hole, or via a large diameter conduit stub between the panels. But the two sides must be segregated and independently shielded. Will it cause RFI issues? Don't know, have to measure the actual RFI. Has the control system demonstrated any spurious behaviour that might be RFI related?

Are you a freelance programmer? What is your definition of freelance? I am employed by an engineering company, but could very easily be on my own (have done so in the past.) I am a registered control systems professional engineer in the state of New York, so I can provide engineering services to the public (and get sued for it.) I head up the control systems engineering department, but still do actual projects, some of which include PLC programming. I also am on call by several of my long-term clients for troubleshooting and diagnosing problems. If so do you supply (with the program): · Process descriptions Never, those are generally supplied to me by the process engineer (or me, in my role as process engineer.) · Flow charts Waste of time. Always out of date. Best is fully annotated logic and code. · I/O Lists Always. Essential part of project. Most projects I have rescued have gotten into trouble because I/O lists were not properly managed (kept accurate and disseminated to all potential users). · Test results Yep, if time and money are allocated by client. Always try to work through a test plan and document any and all deviations plus resolutions. Sometimes call it "working a punchlist". Do you write OEE friendly programs ? Yep, if time and money are allocated by client. Do you have / use an I/O protocol ? I/O protocols are vendor specific for the most part. I use whatever the client wants. On greenfield projects, I will work with the client to identify which vendors' products are best for them in terms of maintenance, support, operability. Are you a programmer employed by in the manufacturing environment ? See answer under first ("freelance") programmer. Does your industry have programming methodologies ? If so what are they? Methodologies per se, not that I am aware, but there has been some diffusion from other engineering fields and from computer programming that have somewhat melded and are sometimes used. Mostly, what we do is very focused and directed, and whatever techniques we use to accomplish are based on personal experience or training. Not a lot of formal methodologies. I would appreciate any assistance. Me too. Know how to do machine control code using Mitsubishi A-series? I took a look at it, but the architecture is so different from American PLCs, it's not worth my time learning.

Oh, and Jimbo? If PINGs are not routable, how can you ping an IP address not on your ISP's subnet? I can ping microsoft.com, but I am NOT on their subnet. Most firewall/routers can only be configured to route a TCP or UDP datagram to ONE specific machine on the intranet, so you could route PINGs to one machine, but not all.

Most ports will accept a connect from a telnet client. Frequently used to test port 80, which is HTTP port. If you do connect to a port not backed by a telnet server, you just talk in whatever the lingo is for the connected server application. I.E. if you telnet to port 80 and reach the HTTP server you would type in the GET statement as defined in the HTTP specification. You would get back the HTML for the web page that was requested. Can also do the same with mailserver ports, etc. Actually any port. So if you can just get a response from ANY server application on a machine, that means you can reach the machine. If you get a response from a specific port, it means that machine has a server app running against that port.

Oh yeah... HMIs.... Okay, now IMHO, the only logic the controller should be doing, (PLC or otherwise) should be concerned with the process ONLY. There should be no logic to support HMI features. The HMI should include time-based behaviours, such as "display this animation starting two seconds after this bit is set, and continue for five seconds or until the bit turns off, whichever comes first." The need to burden the PLC with extra logic and communication to support HMI features is nonsense. The PLC should do process logic ONLY, the HMI should do all logic relating to display elements. Better documentation of PLC-HMI linkages. I want a cross-reference facility that tells me all the uses of a particular contact, say, in an HMI project. Global search and replace. Use of master screens, a screen that has dummy linkages along with sets of lists associating the dummy links with real references. An example, a reactor screen for a facility that has 5 similar reactors. One master screen. and five lists, one for each reactor. Call up the screen for a reactor and poof, the master screen with the particular references for the specific reactor. Easier to keep current. Vendor-supplied diagnostic screens for all troubleshootable elements, CPUs, modules, I/O, etc. Tired of doing my own every time. Make the dang HMI generate automatically and keep current. Also tables of HMI screens. (directory). BTW, I don't use the pretty, fancy, USELESS graphic symbols. My clients want clear, concise screens, not those that look like they are out of "Factory Beautiful" and are inversely useful. 256 colors is more than enough. Unless you are integrating color video. Believe it or not, I am NOT gonna disparage using Microsoft Windows. As far as development goes, it is a very rich and powerful environment. Nobody else has come close. Linux is still too techish and fragmented. Too many different ways to do the same basic things; how many GUIs are there anyway? And all are inferior to Windows in terms of ease of development. I don't care how proud you are of your code. I have real problems to solve.

What would I like to see? An integrated development environment. I like the direction that CimplicityME has gone, integrating logic development and HMI development. Only wish it didn't have so many bugs and weird features. Support for ALL the IEC 61131-3 languages. Clean up the communications mess. Too many different cables and connectors. Ethernet is good, but by definition distance-limited. RS-422 is good for long distance communication. Anything else is a waste of time. Support for online monitoring/debugging. Yep, I know, potentially risky, but if you don't know what you are doing, then please have enough smarts to stay away from that feature. For those of us that are experienced, i.e., been bitten a few times and hence evolved caution, we should have the option of working online. Don't presume to think for us. Error Analysis and Optimization. I can't believe how many times I've looked at someone else's code and seen so many redundancies and errors. It's not rocket science, guys. Better analysis and optimization exists for much more complex computer languages. Hire some real software engineers and develop a useful compiler ferchrissake. All computer languages (and PLC languages ARE computer languages nowadays) do is tell the compiler what the developer wants to accomplish. Let the compiler figure out the best way, oh and tell the developer when he/she screws up. BUT, NO USE of speculative, out-of-order processors! These are NOT desktop computers, SAFETY should be first in mind. Get together and figure out ONE way of doing I/O wiring. I read Jim Rowell's article, http://www.mrplc.com/kb/index.php?page=ind...x_v2&id=44&c=38, and he is RIGHT on the mark. Figure out the ONE way of doing things SAFE, SAFE , SAFE! None of this "we'll give the customers what they want" crap. Most of your customers are ignorant of the safety aspects. Take a leadership role and push safety. As for me, I have better things to waste my time on than figuring out yet another wiring scheme. More use of modular connectors and cabling. Embedded OPC servers. Tired of tying up a computer to do OPC. Embed the dang server in the PLC. Do it as an add-on module if you need to. Store the annotation on the PLC with the code. Should all be ONE unit, indivisible with liberty... yah, I think you get the drift. Tired to sucking up OLD logic and having to figure out what everything is for. Oh, and make annotation MANDATORY for used contacts, coils, registers, etc. and require every rung to have a comment line. Again, I am so tired of trying to visualize what some lazy bast**d had in mind from naked unannotated code. Don't tell me you don't have the time to document. But then, I'm not above glaring at a client and telling him to wait the extra ten seconds. Amazing how many of them ask me back... (all of them.) dang, this is getting long.... but in retrospect, this is a great time to be working in the industry. I enjoy what I'm doing and hope the good times continue.

Anyone have any experience in working with the SoftPLC? From what I can tell, it's a fairly accurate emulation of an A-B PLC-5, but on an industrial computer. Supposedly runs about 70x faster than a PLC-5, depending on what you use for a processor. Programming untilities look a bit on the primative side, though... A client wants me to evaluate it for possible use, in place of normal PLCs, as it is much less expensive. Wondering what, if any, downsides there are to it.