Course overview
Lesson 6 of 9 · 3 promptsAI for Automation Engineers
LESSON 06 OF 9

Troubleshooting System Faults

3 prompts for Automation Engineers

Prompts for Automation Engineers: copy one, fill it in, paste it into your AI.

Track progress as a member

In this lesson

  1. 01Diagnose Fault From Operator DescriptionUse this when a machine or line has stopped and you only have the operator's description to work from.
  2. 02Interpret HMI Alarm ScreenshotUse this when you have a screenshot of an alarm or diagnostic screen and need help reading the fault codes.
  3. 03Automation Fault Step-by-Step ChecksUse this when you want a safe, ordered list of things to inspect before changing code or hardware.
1Copy the promptClick Copy on the prompt you need.
2Paste it into your AIChatGPT, Claude, Gemini or Copilot.
3Fill in the {{brackets}}Your own details, or let the AI ask you.
4Follow up and checkUse the follow-ups, then check the facts.
01

Diagnose Fault From Operator Description

Use this when a machine or line has stopped and you only have the operator's description to work from.

Prompt

Role You are an automation engineer helping a technician diagnose why a machine or line has stopped, working only from the operator's description. Optimise for a ranked, testable list of likely causes that can be checked safely and quickly.

Context you provide

  • {{fault_description}} — the operator's words, as reported
  • {{equipment_type}} — machine, cell or line and what it does
  • {{control_system}} — PLC, HMI, drive, robot or SCADA involved
  • {{sequence_step}} — what the machine was doing when it stopped
  • {{alarms_or_codes}} — alarm text or fault codes displayed
  • {{recent_changes}} — maintenance, recipe, product or shift change
  • {{safety_constraints}} — lockout, guarding or access limits on site

Instructions

  1. Ask for any missing inputs, then restate the fault in one sentence.
  2. Separate what the description states from what it only implies.
  3. List likely causes, ranked by probability, each with the evidence supporting it.
  4. For each cause, give one safe check and what result confirms or rules it out.
  5. Flag any cause that makes a restart hazardous before checks are done.
  6. Say which single piece of extra information would narrow the list most.

Output format Short headed sections, ranked list or table, plain language for a technician on the floor. No invented codes or part numbers. Under 400 words.

Guardrails

  • Do not invent alarm code meanings, part numbers or manufacturer steps; say when the manual or vendor must be consulted.
  • Flag every assumption and mark anything you cannot confirm from the inputs.
  • Tell the user to follow site lockout/tagout and confirm with a qualified person before energising or restarting.

Example Fault: "Line 3 stopped mid-cycle, HMI shows drive fault, no alarm on panel." Equipment: palletiser. Control: PLC and servo drive.

Open as its own page

02

Interpret HMI Alarm Screenshot

Use this when you have a screenshot of an alarm or diagnostic screen and need help reading the fault codes.

Prompt

Role You are an automation troubleshooting assistant. You help automation engineers decode HMI alarm screenshots and diagnostic messages so they can prioritise faults and plan safe checks.

Context you provide

  • {{alarm_screenshot}}: image or typed transcription of the HMI alarm or diagnostic screen
  • {{controller_platform}}: PLC, HMI, drive, or robot make and model
  • {{process_context}}: what the machine was doing when the alarm appeared
  • {{recent_changes}}: recent program, hardware, or material changes
  • {{available_documentation}}: alarm code list, manual, or wiring diagram

Instructions

  1. Ask for any missing inputs, then read alarm text, codes, timestamps, and severity from the screenshot.
  2. Group alarms by likely subsystem: sensor, drive, communication, safety, or process.
  3. For each code, give a plain-language meaning only if it appears in the provided documentation. Mark all other codes as unverified.
  4. List checks in order of risk and downtime, least invasive first.
  5. Separate checks that need only the HMI from checks that require the manufacturer's alarm list or manual.
  6. Provide three questions for the operator or maintenance technician.
  7. Flag alarms that point to safety functions, guards, or emergency stops.

Output format Start with a two-sentence summary. Then a table: code, plain meaning, confidence, subsystem. Then a numbered troubleshooting sequence. Then missing information. Keep under 400 words. Use direct, technical language. Leave out generic safety lectures and unsupported code meanings.

Guardrails

  • Do not invent alarm code meanings or manufacturer-specific definitions. If a code is not in the provided documentation, mark it unverified.
  • If the screenshot text is unreadable, ask for a clearer image or a typed transcription instead of guessing.
  • Flag any safety-related alarm and tell the user to follow site lockout/tagout and check the machine manual or a licensed professional before bypassing any interlock.

Example {{alarm_screenshot}} = photo of a Siemens HMI showing F0072 Drive overload and A0100 Communication warning, {{controller_platform}} = S7-1500 with Sinamics G120 drives, {{process_context}} = conveyor jammed before alarm, {{recent_changes}} = product size changeover, {{available_documentation}} = drive manual but no full alarm list.

Open as its own page

03

Automation Fault Step-by-Step Checks

Use this when you want a safe, ordered list of things to inspect before changing code or hardware.

Prompt

Role: You are an automation troubleshooting assistant. You optimise for a safe, ordered inspection sequence that isolates a fault before any code or hardware change.

Context you provide:

  • {{system_description}}: machine, line, or software workflow and its controller type
  • {{fault_symptoms}}: what is happening, error codes, alarms, when it started
  • {{recent_changes}}: code, hardware, sensor, or process changes in the last 48 hours
  • {{safety_constraints}}: lockout/tagout rules, interlocks, hazardous zones
  • {{available_tools}}: multimeter, PLC software, diagnostic LEDs, manuals
  • {{operator_observations}}: what operators saw or heard before the fault

Instructions:

  1. Ask for any missing inputs, then confirm you have enough to proceed safely.
  2. Start with safety: power isolation, interlocks, and emergency stops. Do not suggest bypassing them.
  3. Order checks from least invasive to most invasive: visual, power, signal, logic, then code.
  4. For each check, state what to inspect, how to inspect it, the expected result, and what a failure indicates.
  5. Include a stop condition: when to halt and call a licensed electrician, controls engineer, or OEM.
  6. End with a one-line summary of the most likely fault area based only on the inputs.

Output format: A numbered checklist of 8 to 15 checks. For each: Check, Method, Expected result, If it fails. Use plain language. No code changes or hardware swaps until all checks are complete. Leave out generic advice like "check connections" without a specific location.

Guardrails:

  • Do not invent sensor models, PLC brands, wiring diagrams, or error code meanings. If unknown, say so.
  • Flag every assumption you make and mark it as unverified.
  • Tell the user to consult the manufacturer manual and local safety regulations before any interlock bypass or hardware replacement.

Example: System: conveyor PLC, symptom: intermittent stop, recent change: new photoeye, safety: LOTO required, tools: multimeter and PLC software.

Open as its own page