[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HELP - pushing Inferno as a solution
- Subject: Re: HELP - pushing Inferno as a solution
- From: Roger Peppe <firstname.lastname@example.org>
i forwarded the two messages talking about ladder logic to a friend who's been working on ladder logic compilers, and this was his reply. rog. Date: Thu, 27 Mar 1997 11:56:04 GMT From: Steve_Kilbane@cegelecproj.co.uk Message-Id: <199703271156.LAA01401@phantom.cegelecproj.co.uk> Subject: Re: ladder logic and limbo Here's a response. Feel free to forward it to the list, although it's a bit rambly.. >From ClarkGR@aol.com > > >>> With all the new stuff out there, is my company specing the right > > hardware and software? For now, probably, although see below for language issues. > > Will we remain competitive with utilization of the > > Allen Bradley stuff? Certainly. AB, ABB, Siemens, etc. are industry standards, AFAIK, and aren't going to disappear any time soon. > > Should we give serious consideration to some of the > > newer technology? Yep, but your main issue will be with the user interfaces, rather than with the control side. That, and how you actually develop your applications. > > Could Inferno (and custom applications in Limbo) improve > > our performance, native, quite possibily, but there are trade-offs - see below. > > or perhaps lower our cost to the customers? well, that depends on how much you sink in the development budget first. > > Could Inferno > > provide a better foundation for the necessary integration work? Pass. If you're talking about different components of your control system talking together, then quite possibly. But then, there are a lot of developments going on in the automation arena that might get in your way. How do you feel like writing a FIP driver for Inferno? If you're talking about interfacing with controllers themselves, then I'd forget it. > > Are the AB > > controllers (and others in that market) so proprietary in design that nothing > > else would work with them? This is near enough the case. PLCs are extremely proprietary beasts. > > Would a new controller design be necessary. I'd say so, and that might scare your customers. > > Could Inferno provide controller manufacturers an opportunity to reduce the > > high cost of these devices? Will AB respond to this with an offer for joint > > venture with Lucent? (OK, maybe I'm getting carried away with that last > > one.) You're pushing the barrel out, aren't you? :-) I think that controller vendors would have to consider that one themselves. > > GOD ... I hope someone can tell me there really is > > something other than PLC5 "ladder logic" (wiring diagrams masquerading as > > code)!! There is, but it's still pretty sick: IEC1131 and its ilk. > > But of course, we must maintain many sites > > where there are no programmers on site. Plus, I imagine, supporting the existing non-programmers that you have. For those who don't know, here's the deal on PLCs. At the basic level, a PLC has a single program which is a list of instructions, which generally read data from one "table", modify it a bit, and store it in another "table" - tables being arrays of fixed size and simple type, usually something like 16-bit integers or reals. The instructions are in "ladder" code, because it's based on wiring diagrams, with power rails down either side, and wires going from one to the other, with coils, switches, that sort of thing. Loops, branches, subroutines, etc. aren't there, although you can "switch off" chunks of code, so there's the effect of a skip forward. That's basic ladder. Every vendor has their own variation, to add value in their own way. The PLC runs the program in a loop of defined interval - a "scan". Just before running the loop, it reads a bucket-load of data from inputs from plant equipment, and makes this available in tables. The program is run once, from top to bottom, and then the PLC copies another wodge of data from other tables to the outputs. Pause a little bit, then repeat. There are good parts to this system: - you don't need software engineers to write ladder code. old hardware engineers seem quite happy with it. - the process has a fixed, defined, max run-time - you can work this out in advance. - the memory usage is not only static, but decided by the engineer, not a compiler. The program deals only with table indices, no pointers. and the bad parts: - PLCs are usually controlling concurrent systems, but the people who program them don't know anything about concurrent system theory, and don't have the tools to program them if they did. - due to lack of procedures, if you want to do the same thing 1000 times, you write it 1000 times... - Because PLCs are such a small market in comparison to the rest of the computer industry, the software tools tend to lag quite heavily, and openess is nearly non-existent. There's a push to fix a lot of this. The IEC-1131 standard defines the PLC world "openly", and part 3 describes languages. There's a ladder variant, an assembler variant, something that looks a bit like Pascal, and two graphical languages that look like state machines and a IC wiring diagrams, respectively. These are all improvements over the current state of the art, but as languages go, they're pretty horrendous beasts. Clark's company should be looking at them because they're like ISO-9000 - you think it's lousy, but your customers want you to support it anyway. The problem with the IEC-1131 system is that they still interpret a PLC to be scan-based, which isn't going to do much good if you want to program your control system in limbo. You could take the route of producing your own controller, which runs Inferno. Your problem would be to sell it to your customers. Depending on who they are, they'll either just want a system that does the job, or they'll want one that's based on hardware they trust, which could sink your controller. More interestingly, it's not uncommon for a control system to be sold, including the source to it: the customer buys the rights to maintain and modify the system themselves, which means that they will want to understand the language its written in. Above all, it's the closed attitude of the PLC vendors that is the main problem. Having been involved in a project to produce IEC-1131-based development tools for a number of PLCs, I was amazed to discover that some vendors refuse to give out any interfacing information whatsoever. You either use their programming tools, or you use a different controller. In the end, it was the lack of interfacing specs that caused the project to die. That was a couple of years ago, which in this industry is one "forever", so things might be different now. All opinions are mine, and have no relation to those of my employer.