Sign in to follow this  
Followers 0
PdL

N.C. or N.O. abbreviation for outputs ?

21 posts in this topic

Hi all, For a monitoring system I need to centralize some emergency inputs and outputs states. For the inputs I can make the light states clear by commenting them input N.C. As for outputs, is there a uniform abbreviation or short for this ? I can comment them with output normally off but I would like to use a short term because I have reserved some space for it. N.O. for Normally On and N.O. for Normally Off does tend to confuse a bit

Share this post


Link to post
Share on other sites
IMHO, N.O. = Normally Open. Compare N.C. But if I would make the comments myself, it would be "slutande" or "brytande". Comments in Swedish are a lot easier to understand for me!

Share this post


Link to post
Share on other sites
I don't know what type of monitoring system you are talking about, but I have found most people like color codes more than symbols. I have a diagnostics web server that use red for inputs that are on or the state that should be payed attention to (catches the eye) and blue for inputs that are off (blue goes nicely with the layout of the page and they don't pay as much attention to them)

Share this post


Link to post
Share on other sites
It's for a SCADA system monitoring an HVAC plant. There are some emergency inputs to close zones of dampers, and we have to control some outputs to report zones that are all opened. You're right using colours is good, but my experience is that it's always questionable what the colour is indicating. To prevent people misinterpreting the indications I want to make it more clear. Still trying to figure out a good layout but right now I have something like this, as you see I can say the inputs signals are N.C., and the output signals are normally on. I'm probably making this far too difficult for myself, I was just wondering. I think I'll leave it to something like this, but if you have other suggestions you're welcome. Thanks

Share this post


Link to post
Share on other sites
Rather than use the terms NO and NC in this case, I would pick some other description. Maybe "Normal state is ON" or "Expected state is OFF" or "OFF when faulted". My reasoning is that NO and and NC can also define how a sensor is wired and using those terms might cause confusion, especially to a person trained in industrial electrical systems. Also, as you have already recognized, they don't really convey the meaning you intend when applied to outputs.

Share this post


Link to post
Share on other sites
Well, this is what is a bit tricky about it. From the HVAC system point of view, if the input signal to close the dampers lowers, it's a fault. But from the safety view of the overall system (it's on a ship) it is a safe situation. So, to say "normal state is on" isn't really appropriate. I will see if I can combine some statements that make it clear from both points of view. It's something that returns every system I do, I'm always struggling with this. In the past we have had some discussions with people from Lloyds who audit the safety on board and they pointed out that we were indicating opened dampers with green lights, as they wanted to see it the other way around, green for closed.

Share this post


Link to post
Share on other sites
I know this isn't what you are looking for but here are some things I figured I would throw out there. I use symbols like this to clarify the severity of messages I am sending

Share this post


Link to post
Share on other sites
This is one of the production summary pages. Notice at the bottom the symbols are used to show what type of message it is. Sorry for the air brush. Had to do that to keep from going through an act of congress to post

Share this post


Link to post
Share on other sites
This is one of the diagnostics pages. I guess I'm not really clear on direction of outputs either but no one has complained. Again sorry for the air brush

Share this post


Link to post
Share on other sites
Just figured I would give you some other ideas. Feel free to give you opinions on them. I'm always looking for ways to improve them

Share this post


Link to post
Share on other sites
Totally different kind of cake but I like the icons, I use them also for alarms. Are you running these HTML on a integrated webserver in your controls ? We are having some webbased controls developed too. Thanks for your input so far. Perhaps I'll post my final layout as well.

Share this post


Link to post
Share on other sites
After some copy/paste here's a rough idea on the layout. Any comments welcome

Share this post


Link to post
Share on other sites
Yes, it is a 1756-Eweb module but it actually obtains data from both Mitsubishi and AB devices. I could probably make it communicate with other brands as well but that is the two that are connected to the network I guess you could say it is similar to RsView and other software like it without the tag and multiple computer cost. It works with any computer that can run Internet Explorer 6.0. I never could get it to work with Netscape very well. I just implemented a Wireless Palm Pilot system to connect to it a few months ago. Still working out the bugs in it but pretty much it’s just like Star Trek. The guy just whips out his Palm Pilot by the machine and without hooking cables in is able to diagnose the problem with the machine. This particular one communicates with about 200 devices which is large on my scale. It can diagnose simple things to why a machine is not running, a switch hung, open and short circuits, etc. It does data logging of production over the last month (one of those pages are posted) including averages and alerting people to good and bad days of production. It also emails the proper person if there is a major problem with a machine and emails the management to record production days just to make them grin. It also has some pages that pinpoint bottle necks in processes and even operators that are hung over on Monday. I don’t know if this Web Enabled technology is just a fade or is here to stay but I love it and people seem to like the idea of not having to have special software. Plus the training time is much lower since all they really need to know how to do is use Internet Explorer.

Share this post


Link to post
Share on other sites
I'm impressed man that's awesome Hope to get on the road with our project soon too. Going OT now but heck its the lounge. You certainly are right with the advantages, being able to control and monitor from any system on the internet, interfacing with third parties, I love it. I wonder, how user friendly is the "developing" environment, are you just ramming HTML code or is there some customised software to do this ? We are having this device customised to our needs. It comes with a design kit to develop the HTML pages. It's really a nifty little device, featuring a Modbus TCP client (or master if you will) and a RTU slave, our version also talks a in house developed UDP protocol to a controller with a 2 wire network (power/data) with max 200 slaves, and stores all data in the modbus mapping registers. We now use an Modbus TCP OPC server to retrieve all data on a PC with SCADA but we are going to integrate the SCADA in the webserver for the obvious reasons.

Share this post


Link to post
Share on other sites
I like your image but still like colors. Looks like in your example the current states off all points are there correct operating conditionl Maybe you could make the buttons red when in there incorrect operating position ( when an input is off or an output is on) Another thing just from input I have got here on mine, most people wanted it layed out in more of a worksheet fashion. Pretty much in the left columns would be your input/output descripters. Across the top would be the fire panel numbers or vice versa. This way when they look across or down a row or column they can see that all Output Staircases are go or everything for Firepanel IIIA is good. Plus if layed out good you can get rid of the redundant descriptions for you Inputs and Outputs. Here is a very crude example of what I am talking about

Share this post


Link to post
Share on other sites
Well that's what I was trying to explain. Neither of both signal states are real alarm situations, it's more to just visualise the actual input / output state rather than the consequenses of the signals. The columns is a good idea. I always tend to work out one panel and then copy the rest hence this layout but I will see if I can make it a bit more sorted in rows/columns style. Phew, what such a simple question can stir up.... It's just great to get some feedback cause when you're programming non stop sometimes you miss the refreshing view from another point. To be continued.

Share this post


Link to post
Share on other sites
It depends on your definition of “ramming” is. I definitely rammed my head against the desk for several months since I was strictly a Plc programmer when I started and hated computers. Actually I still hate computers. But there is a method to it. I use VB.Net to write most of the Html code. Yes there are better things to write Html with and hopefully one day I will get something. From there I pretty much use 3 methods 1. If a device supports CIP messaging such as Ethernet/IP, Devicenet, and Controlnet (I’ve never used controlnet) you can issue CIP commands from the web page through the 1756-Eweb. 2. Some devices (not many at this time but growing) will respond to html commands and send data back 3. But the main way I get data into the web server (remember this is a plant wide system) is there is a 1756-L55 processor in the rack. Any data that is being logged or processed in anyway uses this method. From there it is just getting any other device to communicate with 1756-L55 which isn’t as hard as people make it out to be. From method 3 the Eweb module gives you two ways to render the Plc tags. 1. Write normal html but put an asp extension on it. This tells the Eweb module to fill in the Plc tags. Then where ever you want a machine value put <%ReadLogixTag(“1,0”,MyTag,”DINT”);%>. The “1,0” being the path to the Processor, MyTag being whatever tag you want to read, and DINT being the data type of the tag and the Eweb will do the rest. 2. But my preferred method is to use the Xml. This allows you to really manipulate data but is much harder to learn. Method 1 gives you static data similar to MrPlc. The Xml method allows you to stream information to a web page just like you normal HMI would. The screen captures I posted are purely Xml. The only thing I use Method 1 for now is the Palm Pilots because I am having problems getting the Xml to work with them. Their live data is just constant screen refreshes right now and they look awful with the whole screen suddenly flashing.

Share this post


Link to post
Share on other sites
I know what you mean. Which brings up one bad point about using Internet Exploer. Anyone can view it. And when you get a lot on none techical people viewing your pages and they will really give you a different point of view on how data should be displayed. But most of them do pay the bills so it's not bad to impress them

Share this post


Link to post
Share on other sites
Here are some of my palm pages. I opened them in Internet Explorer to do the screen captures but this is pretty much what they look like. They are functional but as you can see they need a lot of cosmetic work

Share this post


Link to post
Share on other sites
Just a thought here, the screens seem to be targetted for the user, right? Do they need to know about input / output state, or just device state? What I'm thinking is you could have, for inputs, just the name of the device being monitored (staircase or staircase sensor) and status (ok / tripped) The same thing for outputs (staircase, open / closed). You should definitely line up all the OK state indicators. In your last example, inputs are ok on the right and outputs ok are on the left.

Share this post


Link to post
Share on other sites
I've worked on it in the mean time and will post a screen later. Larry, our job is to monitor the close zone inputs which come from the fire system, control the dampers and control the closed outputs which go to the fire system. So there isn't really a device or sensor state, it's pure signalling.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0