Markus

I want you to act as an experienced drives technician. A variable frequency drive tripped. Drive: Drive make, model and firmware if known. Fault code and text on the keypad: Fault code and text. Motor: kW or HP, volts, FLA, rpm. Load: conveyor. When it happens: on start, at full speed, on stop, random.

1. Explain what this fault means in everyday words and what the drive measured to trip it. If you do not know this exact code for this model, say so, give the most likely meaning based on the text, and tell me which manual section to confirm it in. Do not invent parameter numbers.
2. List likely causes ranked by how common they are for this load and this timing.
3. Give the checks in order, starting with the ones that need no tools or downtime (fault history, DC bus and output current at trip, recent parameter changes), then meter checks, then checks that need the motor uncoupled. For each: what to check, how, and what reading points to which cause.
4. List the drive parameters worth reading and recording (accel/decel time, current limit, motor data, carrier frequency, braking), described by function, not by a parameter number you are unsure of.
5. Say what NOT to do, for example resetting repeatedly without finding the cause.

Give the checks as a table: Step | Check | How | Reading that points to a cause.

I want you to act as a commissioning lead. Equipment: a packaging line with 4 VFD conveyors, 2 pneumatic diverters and a PLC panel. Below are the I/O list and the functional description.

Build a commissioning checklist in the order the work is actually done:
Step | Phase | Check | Method / tool | Expected result | Done by | Initials and date

Phases, in order:
1. Before power: panel inspection, terminations, labels, grounding, network cabling.
2. Power-up: supplies, controller and I/O status, network communications, firmware and program version recorded.
3. Point-to-point I/O check: one row per I/O point from my list, input simulated or operated at the device, seen at the PLC; outputs forced and seen at the device.
4. Devices: motor rotation, VFD parameters recorded, valve and actuator travel and feedback, analog ranges checked against a reference.
5. Functional tests per the description, then fault and recovery tests.
6. Handover: backups, as-built markups, open punch list.
Use only devices in my I/O list. Where the description is missing information I need for a check, write QUESTION.

Also give the punch list template: Item | Location | Description | Severity | Owner | Target | Closed.

=== I/O LIST ===
Paste I/O list

=== FUNCTIONAL DESCRIPTION ===
Paste description

I want you to act as a process control tuning coach. Loop: tank level controlled by an inlet valve. Controller: PID instruction and platform. Current settings: Gain Gain, Integral Integral time or rate, with units, Derivative Derivative, loop update time Update time, action Direct or reverse.

Below is the trend data after a setpoint step: time, setpoint, process value and output, as a table or CSV.

Work through it in this order:
1. Check the data first: the units of the integral term on this instruction (time vs repeats), whether the output saturated at 0 or 100 %, and whether the step was big enough to read. If any of these makes the trend useless, say so and stop.
2. Read the response: dead time, rise time, overshoot %, settling time, steady-state error, oscillation period, and whether the output was noisy.
3. Name the most likely problem (too much gain, too much integral, dead time, valve stiction, saturation, wrong action) and the evidence for it in the data.
4. Recommend ONE parameter change, with the new value and what the next step test should show if you are right.
Do not change more than one parameter at a time. If the evidence points to a mechanical or instrument problem instead of tuning, say that.

=== TREND DATA ===
Paste time, SP, PV, OUT

I want you to act as a technical translator for PLC programs. Below are comments, tag descriptions and alarm texts from a PLC or HMI project written in Italian. Translate them to English.

Rules:
1. Keep every tag name, address, block name and number exactly as is. Translate only the human text.
2. Use the words a controls technician would use on the floor (for example "seal-in", "proximity switch", "fault reset"), not literal dictionary translations.
3. Keep each translation within the same length as the original, because HMI fields and comment columns have limits. If it will not fit, give a short version and flag it.
4. Where a term is ambiguous or plant-specific slang, give your best translation and mark it CHECK, with the alternatives.
5. Keep the abbreviations consistent: list each abbreviation you found and how you expanded it.

Output as a table I can paste back:
Tag / address | Original text | Translation | Notes
Then a glossary of the recurring technical terms.

=== TEXT TO TRANSLATE ===
Paste comments or tag table export

I want you to act as an alarm management specialist. Machine or process: Machine or process. Below is the current alarm list, plus alarm history if I have it.

Rationalize it in the spirit of ISA-18.2 / IEC 62682. For each alarm give:
Alarm | Keep as alarm / Make it a status message / Remove | Cause | Consequence if ignored | Operator action | Relative priority | Reset condition | Reason

Rules:
1. If there is no operator action, it is not an alarm.
2. Use only equipment and causes in my list. Do not invent alarms.
3. Base priority on consequence and how much time the operator has to respond, and state the basis.

Then list:
- Duplicates: one root cause raising several alarms, with which one to keep.
- Chattering or nuisance alarms from the history, with the fix (deadband, on-delay, latch, suppression by state).
- Causes with no alarm at all.
- For each alarm kept, a one-line alarm text in the pattern: where, what, consequence, action.

=== ALARM LIST ===
Paste alarm list

=== ALARM HISTORY (optional) ===
Paste history or write NONE

I want you to act as a strict reviewer of PLC code written by an AI, before it is downloaded to a controller. Platform: Platform and version. Language: Language. Below are my numbered requirements, then the code.

Do a review in five passes and report each as a table. Do not rewrite the code.
Pass 1, requirements: Requirement | Where it is met (block/line) | Met / Partly / Not met | Why
Pass 2, instructions: every instruction or function used | Exists on my platform and version? (Yes / No / UNSURE) | Correct parameters and units?
Pass 3, structure: timers or edge detectors called inside IFs or conditional branches, reused instances, outputs written in more than one place, latches with no reset.
Pass 4, behaviour: what happens on first scan, power cycle, download, mode change, and when an input is stuck or a sensor fails.
Pass 5, gaps: anything the code does that no requirement asked for, and requirements with no code at all.

Finish with findings ranked by impact: Finding | Block/line | What goes wrong on the machine | Test that would prove it.

=== REQUIREMENTS ===
Paste numbered requirements

=== CODE ===
Paste code

I want you to act as a commissioning engineer writing a Factory Acceptance Test (FAT) plan. Machine: a sorting conveyor with three diverters. Below is the functional specification, numbered by clause.

Write test cases as a table:
Test ID | Spec clause | Precondition | Action (what I do or force) | Expected result (exact tags, values, HMI text and timing) | Pass/Fail | Witness

Cover, for every clause:
1. Normal operation: start, run, stop, mode changes.
2. Each sensor stuck on, stuck off and flickering. Each actuator failing to move.
3. Faults during stop and during reset. Two faults at once.
4. Power cycle, controller stop/run and communication loss: what must restart, what must not.
5. Boundary values: test just under and just over every timer and setpoint in the spec.
Where the spec does not define the reaction, write NOT IN SPEC and add a question. Do not invent behaviour.

After the table give: a clause-to-test coverage matrix (any clause with no test is a gap), and the order to run the tests so I force and clear signals the fewest times.

=== FUNCTIONAL SPECIFICATION ===
Paste spec

I want you to act as a controls technician building an I/O list from electrical drawings. Below is the PLC I/O sheet, typed or pasted as printed: Drawing number and revision. Target platform: any.

Transcribe it into a table with one row per channel:
Rack/Slot/Channel | Address as printed | Wire number | Terminal | Field device tag | Description as printed | Device type | NO/NC | Signal type and range | Proposed PLC tag name | Notes

Rules:
1. Copy text exactly as printed. Do not correct spelling, tag names or wire numbers. Mark anything unreadable as ILLEGIBLE.
2. Do not fill NO/NC, signal type or range from typical values. If the sheet does not state it, write NOT ON DRAWING.
3. Spare channels get their own rows marked SPARE.
4. Proposed tag names follow this convention: Area_Device_Function. Keep them separate from the printed text.
5. After the table, list: duplicate addresses or wire numbers, channels with a device but no description, redlines or clouded changes you noticed, and questions for the drawing owner.
Give the table as CSV as well, so I can import it.

=== DRAWING SHEET ===
Paste or describe the I/O sheet

I want you to act as a controls engineer writing a Function Block Diagram (FBD) block for Platform and version. It scales one analog input and detects bad signals.

Signal: tank level transmitter, 4-20 mA, engineering range 0 to 5000 mm. Raw card range: give the raw counts for 4 and 20 mA from your card manual, or write UNKNOWN.

Requirements:
1. Scale raw to engineering units with linear math or the platform's own scaling instruction.
2. Quality states: Good, Wire break (under about 3.6 mA equivalent), Over-range (over about 21 mA equivalent). Bad must stay TRUE for 500 ms before it latches, so one noisy sample does not trip it.
3. When Bad, hold the last good value and set a Value_Hold flag. Do not pass a scaled value from a broken wire.
4. Alarm_Bad latches and clears only on a Reset with the signal Good again.
If the raw range is UNKNOWN, do not assume one. Show where it goes and list it as a question.

Give: the FBD network by network as text (block, inputs, outputs, connections), the same logic as Structured Text so I can check it, your assumptions, and a fault-injection test table:
Raw value written | Duration | Expected engineering value | Quality | Alarm_Bad | Value_Hold

I want you to act as a PLC programmer writing ladder logic for Platform and version. Write a motor start/stop circuit for Conveyor_M1.

Inputs, with what TRUE means:
- Start_PB (normally open pushbutton, TRUE = pressed)
- Stop_PB (wired normally closed, TRUE = healthy, not pressed)
- M1_OL_OK (TRUE = overload healthy)
- Downstream_Running, Lube_Pressure_OK (TRUE = OK to run)
- Reset_PB (normally open, TRUE = pressed)
Outputs: M1_Run, M1_Fault.

Requirements:
1. Stop-dominant seal-in: Stop, overload trip or loss of any permissive drops the motor, even with Start held.
2. Overload trip latches M1_Fault. Reset clears it only on a rising edge of Reset and only when the overload is healthy again.
3. Start does nothing while the fault is latched or a permissive is missing. No restart on its own when a permissive returns.
4. Each output is written in exactly one rung.
Use only instructions that exist on my platform. If you are unsure one exists, mark it UNSURE.

Give: the rungs as text in execution order with a comment per rung, your assumptions, then a test table:
ID | Precondition | Action | Expected (tags and values)
Include Start and Stop pressed together, Stop while running, overload trip and Reset while still tripped, and a permissive dropping and returning.

I want you to act as a controls troubleshooter. An operator reported this symptom: "Conveyor 3 starts, then drops out after a few seconds". Platform: Platform and version. I am pasting the source of the blocks, routines or POUs involved, the calling order from the main task, and the I/O list.

Start from the output or fault that misbehaves, the motor run output, and trace it backward across every block. Give a table:
Hop | Block / routine / network / line | Exact condition for this hop | Tag I must watch online to confirm it

Then:
1. List every write to each tag in the chain, in every block, including both branches of every IF and writes that happen after a block call.
2. Say which block calls which, and whether any call is conditional.
3. Rank your top 3 hypotheses for the symptom, each with one read-only check that would confirm or rule it out.
4. List what you cannot see from this code: HMI writes, network or comms partners, forces, hardware configuration, blocks I did not paste.
Do not propose a fix yet. I will send back live values for your watch list first.

=== CODE (all blocks involved) ===
Paste block sources

=== I/O LIST ===
Paste I/O list

I want you to act as a senior controls technician reading a PLC program I did not write. Platform: any IEC 61131-3 platform. Language: Ladder. Below is the code as text, followed by the I/O list or tag comments if I have them.

Explain it rung by rung (or network by network) in a table:
Rung | Condition in everyday words | What it does | Scan-order or latch notes | Assumptions

Rules:
1. A normally open or normally closed contact in the program examines a bit. It says nothing about how the field device is wired. Take field wiring only from my I/O list; if it is not there, write UNKNOWN.
2. Rungs execute top to bottom and the last write in the scan wins. List every tag written in more than one place, with the rung numbers.
3. For every latch or set coil, name the unlatch or reset that clears it, or write NONE.
4. For every one-shot or edge contact, name its storage bit and say if that bit is used anywhere else.
5. If something depends on code or settings I did not paste (another routine, the HMI, a comms partner), write QUESTION instead of guessing.
Do not suggest changes. This is a read, not a review.

=== CODE ===
Paste the rungs as text

=== I/O LIST / TAG COMMENTS ===
Paste the I/O list or write NONE