http://hv.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=002HzT

Of all the control manufactures that I know of and have worked for the main concerns were in the scheduling/trending areas. These are the main areas of interface between the controller(s) and the MMI (Man Machine Interface)on a regular basis.

Aside from the built in boiler plate programming that is the general procedure for establishing the systems, it is possible, and common, to create specialty routines. Routines for counters (clocks) within counters for determining and controlling the timing for subtle changes in the control sequences. These programmed clocks at the sub-controller level will sometimes need to reference the system clock (controller clock), for the purpose of synchronization with the Schedules and Trends, or just to know what state they should be in.

All of the internal programming for every controller that I am aware of uses the two digit year convention. The system clock that you look, at on the front end, (MMI), is very rarely the clock used by the actual control system. It is used as a reference. The two components (controller, MMI) usually attempt to synchronize when the MMI is booted. Not all systems do this and some require manual updates to the controller clock. A system can actually be running on two different times and/or dates. Most control systems were designed this way so the MMI can be turned off when not being used to monitor, manually override, or otherwise manipulate the system. These three clocks can collide creating the buffer overflow that is mentioned in the post I am responding to if both systems are not using the same date convention.

I have seen systems run for weeks and months with critical errors that continue to accumulate and only slow the system, sometimes becoming unbelievably slow, before the whole breaks down. I have performed service calls on systems that the MMI has not even been turned on for who knows how long. Valves, actuators, safety systems, motors, dampers; bypassed because the operator was afraid of the computer, didnt take the time to learn the system, or did not have the budget to keep up with it. As long as the tenants were not to hot/cold and the fans were running everyone was happy. Compound the problem with the fact that many bigger facilities have multiple brands of control systems, some running on the same MMI, others with their own MMI, and still others as stand alone. We are talking systems here that control thousands of volts to a device, high pressures (boiler systems), gas burning devices, lighting systems (emergency and otherwise). Pressurized gasses that are poisonous when exposed to open flames, otherwise they just absorb/displace the oxygen in enclosed spaces and cause your heart to race etc It wont matter, chances are if you find yourself in that place, at the wrong time you will be dead anyway. Wont matter which organ failed. I know you get the picture. Point is, it can take longer to straighten out some of these nightmares than the original install took. They had a plan at least. Nobody has or will spend the money for that. Documentation has never been big in this industry either. Meanwhile, you are working, living, playing with a bomb and dont even know it.

I look around me now at the documentation associated with some of the systems I have worked with. 4" binders regarding programming so full the rings will not close and stuffed with tech notes and personal notes besides. Control systems designed loosely to be able to interface with a theoretical 2 million+ devices, including controllers, sub controllers and I/O devices. Most of which begin to lose integrity with only a fraction of their capacity filled. Never built one that large, and I dont know of one in existence. Even the ones that are specd out for at least 50% future expansion are programming stressed before they are complete, for the most part. Things are very complicated and convoluted. Competition between systems and manufactures very intense. Get the new gadget out to the market before the next guy has the chance to, ready or not. We can razzle them now and then dazzle them with the upgrade later.

I personally moved my family way out of town. Drive 2+ hours to and from work every day. Expected there to be way more "stuff" happen at the rollover, but understand too why more didnt. It isnt time yet!!

Feel better about being in that tall tall building? Dont take my word for this!! Ask your building manager to see the control system(s). It IS just a computer, nothing to be afraid of. Take a look at the technical books associated with the system. Ask about trends and schedules and how they work. Is it always hot/cold in your building? Is there to much air coming out of the diffuser and blowing things from your desk onto the floor all the time, or so little that you can hardly breath? Does that condition you are thinking about change if you are away from your building for say a vacation, holiday, long weekend? Maybe someone came and worked on the system while you were gone, or maybe a clock ticked, a threshold was met, a schedule date arrived, and the system is working just fine.

-- Ctrl Guy (out_of_town@in_the_woods.net), January 11, 2000

Answers

Ctrl Guy

Thanks for the post. I seem to share many of your experiences. None of them are what I would call confidence builders;)

-- PA Engineer (PA Engineer@longtimelurker.com), January 11, 2000.

Thank you for the firsthand info. Any speculation on a possible timeframe when some of these systems might break down unexpectedly and perhaps spectacularly?

-- J Wheel (motherof5@wellprepared.noregrets), January 12, 2000.

My dear Mr. Ctrl Guy,

Sir you have quite accurately described what I have been trying to get across in this forum for very nearly a year now.

We have still nearly a year's worth of extreem danger left. Before we pass the embedded systems possible failure dates. If you should add in the FACT! That there are times that a need (while constructing the systems) is found for having a date/time counter in a system. And that there where/are in feild modifications made to embedded systems.(Folks! All it takes is a sordering pencil, a hand full of picofared caps. and date counter chips. And you can make date sensitive controllers all day long.)

I thank you sir for pointing out so candiedly that NONE of the dates need be on the same time lines as the others it shares information with. This falls correctly in with having a failure, correcting it. Then after bringing the system back on line,. Only Have that same system again go down (on another part of it's subset), a day, a week or a month later.

Folks! Y2K ain't over yet! The Fat Lady will be coming to the center stage soon.

" I don't know why it failed! But she ain't Y2K boys"!

~~~~~~~~~~~~~~~~~~~~~~Shakey~~~~~~~~~~~~~~~

-- Shakey (in_a_buner@forty.feet), January 12, 2000.

Real Engineer

Well "Real Engineer", my recent heartburn actually has more to do with "flying blind" and a recent bankruptcy and buyout of a Canadian by a US company that has abandoned any support for their product since the GPS roll over. Give me a break. Custom-made Man-Machine Interfaces (MMI) and the the now more politically correct Human-Machine Interfaces (HMI) is the rave today. These generally are software GUI products. Educate yourself and quit trolling. You can start by visiting www.natinst.com for a primer. In fact anybody who would like to familarize themselves with data acquisition and control should visit this site as a good starting point.

Real Engineer, you are a troll.

-- PA Engineer (PA Engineer@longtimelurker.com), January 12, 2000.

"OOPS", pun intended. I see you deleted the troll.

The web reference in my last post is worth a visit for educational purposes. This is a good company with a nice web site. They are one of the founders of the MMI/HMI software industry.

-- PA Engineer (PA Engineer@longtimelurker.com), January 12, 2000.

Real Engineer,

I wish a lot of times that I didn't know about controls and embedded systems. I would probably be sleeping as well as you at night.

MMI was a convenient term for the moment to try and differentiate between specific devices in a built-up control system. If you prefer System Front End,  please feel free to substitute the term of your choice.

Just how many Staefa, Robertshaw/Siebe, Johnson, Honeywell  systems do you think are out there, installed years ago, or recently for that matter that are not in the very conditions that I described? Not that it is necessarily the control company/contractors fault entirely either. Like I said, these systems were bought and paid for and the Customers became primarily responsible from that point on. Training in the configuration or maintenance of them, given in 1 day, two week, and amounts in-between, courses dont take in all cases. Add to that the fact that complexity requires actually establishing the systems on an ongoing basis to retain enough proficiency to actually make useful modifications, what do you have? Breaking and broken systems!

Not taking away from most of the building engineers to much here. A lot of them know their mechanical systems to a very impressive degree. He is the guy in charge keeping it all together. What happens to the place when he gets the flu for two weeks? Will the kid just out of the local HVAC school know that this particular system will only take 12.5PSI of steam before it starts sprouting leaks all over. Darn, they said low pressure system could go to 15PSI no problem. Pipes, radiators, traps were all installed 40+years ago. Chemicals and corrosion take their toll. This or any other of a thousand things that a person knows about HIS building, that take time and experience to deal with.

What about that 600 ton recip chiller. All kinds of safeties built in to that baby. Standard package controls from the factory. Worked great when it was installed 15 yrs ago, as a stand alone system. Did the automated upgrade to the building awhile back. Had to bypass some of those safeties to get the new control package to work. Was able to just insert some control points in others so they are not really bypassed. Just layered now. Was that installed parallel or series? Cant remember. If I am wrong though and one safety trips the other may still be providing the signal needed to allow the system to keep running. Even with a catastrophic failure eminent. Bad things happen to good chillers when they are not shut down in the proper sequence, pressures allowed to equalize correctly. Only a few hundred pounds of refrigerant in there. No biggie.

Is that chiller next to a gas fired unit that may be running to provide heat to another part of the building? Or maybe the whole thing is a package multi-zone unit providing heat to 5 zones and the cooling was going to the other 3, maybe a computer room. They require cooling 24/7 even if it is 20 below outside those big boxes need that cool air. Refrigerant leaks and open flames dont usually work out well. Bad problem, or disaster?

Yea, there are rules and laws about the locations and proximitys of pieces of equipment with each other. There is even inspections by the boatload to make sure things are done right. Have you ever broke a rule? Only 5mph over the limit. Not really a break, just a bending, right?

I did not mean to make the initial post sound as extreme as it came out. I am pretty blunt about things that matter. This, I think matters. Yea, I wish that I did not know anything about controls or control systems, at all.

-- Ctrl guy (out_of_town@in_the_woods.net), January 12, 2000.