Post by thread:[OT] - Your fav' method Distributed controllers ?

At 11:22 03/03/99 +1030, Glenville T. Sawyer wrote: > Hi there, before starting a very bad OT thread, if you want to reply to me >directly - this may be preferable as far as the list is concerned. i don't know -- i start on the list, because i think this is a rather pic-related topic. i've done most my control jobs so far in a centralized form, both in larger scale, as a whole production unit (pretty much in the way you described it: several plcs doing some minor real time logic processing, but most of the data got fed back to the main computer which did then most of the control), or in smaller scale, say within one controller, using bigger, expandable micros like the 8051 or z(1)80 families with all kinds of memory mapping and peripherals. for a project with tight power requirements i started using pics and got familiar with them. and now i find myself (almost :) at the beginning of a project i certainly would've done (and many others would do it also) with something like an 8051 and tons of address mapping for peripherals. certainly doable, but using an i2c bus and some 80 "smart peripherals" consisting mostly of pics with some simple i/o stuff around makes the system a lot easier to handle, for example expansion (just put a couple more peripherals on the bus) or layout (basically only power and the i2c bus needed for the peripherals, of course apart from the special i/o each of them handles). it might be that in some cases it is an advantage having all the code centralized in one place (especially for updates during debugging of the system, since you never know in which part of the whole system your bugs are :). but in general i'd think you can make the stuff much more robust and easier to debug if you put a small controller in small functional units, so that the communication traffic gets minimized to "intelligent" commands rather than transferring pure sensor/actuator data. this can diminish communication to a high degree, which i think is rather important. eg. the case i mentioned above: some 1000 inputs have to be scanned and changes to each one detected in max. 100ms. not a big deal in any case, but putting modules with 32 inputs each on an i2c bus, which only send a message when there is a change on their inputs (which is a rare occurence) changes this from a system that's all the time scanning hundreds of inputs like crazy or a system that has its system bus all over the place into a system that sleeps most of the time and only starts acting when there actually is something to do and receives only simple (and slow) serial communication. and the scanning that still has to be done is only pretty localized -- which is something i like especially about this approach. and it's flexible: need 10ms max. detection time? got it, just put each of the peripherals micros to sleep for a shorter time. the system and its design needs no change. i think this reduction in interaction, from wildly and blindly scanning inputs/actuating outputs to more application-specific, condensed data (in this example: the controller doesn't have to get the input state of each input in 100ms, it only gets the information "input x has switched on", which is in the terms i think and the customer thinks) is something that eases system development a great deal and helps building robust, fault-tolerant systems -- because it's easier to build each unit in itself "safe" than to make a big, complex real time program system safe. my example might not be the best, but it illustrates what i mean by communication reduction and "smart" communication. i think this is a very interesting approach for most control applications, especially distributed ones like the case you mentioned, and with the growing number of small flash micros with in-system programming, the centralized code advantage gets less important. of course, often this is implemented exactly this way with combinations of plcs and computers, but there are probably a host of cases where this approach is too expensive and it makes sense to use a central (small) micro with a number of (small) "smart peripherals". and it might well be that some of these peripherals are "smarter," ie. more complex than the central controller. ge

Glenville T. Sawyer - South Australia (48 Y.O - using Win-98, "EPE Pic-Tutor" programmer etc etc). Theatre, Concert Lighting, Special Effects, Props. & more ! Embedded Control systems for Theatrical & other Applications http://gsawyer.mtx.net/ If you remember this a couple of weeks ago .. > Hi there, before starting a very bad OT thread, if you want to reply to me >directly - this may be preferable as far as the list is concerned. > Subject : Fav' method of Process control....... I did not "survey" the results to a database, but for the benefit of those readers that ARE interested.. Roughly 85% stated that they preferred to have "local" intelligence - that is a PIC or other micro-controller taking care of "Sub-Functions" and only communicating flow or problem / modify information to-from a central CPU. The reasons included.. To ensure that "problem" resolution was treated as a local event unless it was likely to have an effect upon the rest of the production stream, if the "fault" can be cleared locally, then no need to use up Main CPU - and serial comms time to remotely analyse it, sufficient to let the Main know that event "X" happened at "Y".. UNLESS the "fault" was such that the "line" would need to be slowed or (Arghhh) Stopped ! The other "thought camp" was that the "central" should have total control over all of the required functions / actions on the production "line", the reasons for this were to allow for "predictive" processing - in other words a "look-ahead" functionality, that given the right software adaptation, could be used to prepared alternative strategies for future problem resolution. (not specifically an "AI" program), but flagging or alerts useful for the maintenance or programming staff to make changes to the overall running software. These results tie in with the responses I gained by talking to other engineers involved in similar production areas / issues. Thanks for your (collective) input, and for verifying what I personally regard as "best method" in these types of situation. P.S we finished off the clients machine end of last week (using their rules - well after all THEY are paying the bills - Dual CPU'd P-450's - Air-Conned enclosures 115K serial data comms over RS485 and written in Linux). Regards, Glenville.