Is there a standard for HMI alarm/fault messages?

Taht cylinder should have a tag, no? Why not tag number and then a description?
Also, I wouldn't be ashamed of using error codes on alarms Error 32 - XYV-302 - inconsistent feedback sounds good. Having the number and a table with a more in depth description/troubleshooting guide would be best.
 
Ideally, entering 104 and touching a button will pop up a diagnostic screen that gives a fuller description of the fault as well as a checklist of suggested remedies or the same document that you would consult.

Of which no customer wants to pay for....the sky's the limit...I've done hmis with imbedded schematics and user manuals and every io point shown on a picture representation of the hardware. And found A) no customer wants to pay for that and B) Noone even uses it...most operators and maintenance personnel don't have time to read...they want to go bang on something with a hammer.
 
Robertmee,
That seems to me to be overgeneralization.
If you are going to create alarm text, it doesn't take much additional time to include an alarm ID code in the text. With that in place how much extra time is required to include a Word document in your HMI as long as you're using an HMI that supports something like that.
It is also something that a maintenance technician who wants to move up in the organization could implement to demonstrate his skill set.
 
Just from my experience it takes time to generate that word doc and Noone will read it.
 
I like the ones that have the Tag/Address.

Example: Cylinder Under Travel M0

Here is some of mine I have been adding. Its Mitsubishi PLC so M is internal relay.

Alarm Ex.jpg
 
Side tangent here...

1. Customer requests alarms for tons of alarms for even the smallest issue
2. Customer complains about constant nuisance alarms
OR
3. Operators get tired of listening to the alarm horn and remove it from the cabinet and are oblivious to actually important alarms.

Seriously though, the more info in the alarm description the better. Ideally make the description in a PLC/HMI string that can be easily changed without having to use development software.
 
You may find these IEC standards interesting:

IEC 61508 - Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems
IEC 61511 - Functional safety - Safety instrumented systems for the process industry sector
IEC 62682 - Management of alarms systems for the process industries
 
S01 Horz Cyl Not Home - I:xxx (Switch not on, but should be)
S01 Horz Cyl Home Sw Error - I:xxx (Switch on, but shouldn't be)
S01 Horz Cyl Not Work - I:xxx
S01 Horz Cyl Work Sw Error - I:xxx

Abbreviate where possible, keep a similar structure so you can copy and paste and just replace the device and IO.
 
Time and date. Duh !
Alarm number. Each alarm must have a unique number.
Reference(s) to the hardware. I.e. =F3+W1-Q1 being a pneumatic cylinder. =F3+W1-B1 being a sensor on the cylinder.
Alarm description. Do not describe what you think is wrong, because you cannot know that when you setup the alarm. Describe what triggers the alarm.
So this could be an alarm:
"2017-04-19 12:49:21. Alarm #335. Cylinder is activated (=F3+W1-Q1), end position sensor does not activate (=F3+W1-B1)."
 
I also prefer supplying as much information in the alarm message as possible, a simple advance-return motion will have these faults as a minimum:

#001: Motion Advance Overtime Fault - I000PRS expected ON
#002: Motion Advance Overtime Fault - I001PRS expected OFF
#003: Motion Return Overtime Fault - I000PRS expected OFF
#004: Motion Return Overtime Fault - I001PRS expected ON
#005: Motion Sensor Fault - I000PRS & I001PRS both ON

Its not uncommon to have a fault that indicates a sensor input was lost after it indicated that it was already made.

More information to the maintenance folk means fewer phone calls after the machine has been commissioned.
 
I'm not sure of any standards, but I follow Don Norman's suggestions in his book The Design of Everyday Things.

1. Cut out unnecessary feedback. Like others have said, maintenance typically doesn't want to read and will disconnect audible alarms/visual cues if they're always complaining to operators

2. Have your alarms/messages/warnings/whatever contribute to the operators RCA of the issue. OkiePC made a good point of giving a little detail about where the fault is. I say take this a step further. For example....

If you have an overextend/failed to extend fault, take a look and see if there's an easy fix to prevent the operator/equipment from causing this error. Can you place a limit on an input to prevent this error? If not, point the op to where the error is and earn bonus points for telling them how to fix it or what caused it.

If you can't design a prevention of the alarm into the system, then at least make the alarm somewhat intelligent. A concise description and fix that is like a skirt, "long enough to cover the essentials, but short enough to maintain interest." Source: PLCTalk.net user

Here's a decent summary of feedback, with overuse of alarms being touched on page 12/13. http://www.jnd.org/dn.mss/Norman-overautomation.pdf
 

Similar Topics

Hi Experts; Any friends know where from i download the DEMO IFIX Ver 4.5? Regards
Replies
0
Views
1,742
I have programmed servos from a handful of variety of manufacturers and series. Each time I used a PLC without motion functions. I have not worked...
Replies
9
Views
646
Hello, I'm am engineer for a plastic manufacturer. We swapped out a oem motor with one of equivalent nameplate stats made by marathon on our roll...
Replies
3
Views
474
I am trying to implement a sfift-by-wire on a vehicle and for that I am using a standard servo motor...
Replies
0
Views
309
Had an interesting experience this morning. An old Panelview 600, 2711-K6C5X series B to be precise, comes up as error 32. Unfortunately it...
Replies
0
Views
195
Back
Top Bottom