Asking good questions
How to phrase a technical question so Edmund starts a real search: name the machine or line, quote the HMI fault code exactly, tell it to search the documentation, and state the output you want — shown with one good and one weak example.
Edmund answers from the open project’s own knowledge — its documents, PLC programs and maintenance journals. There’s no special syntax to learn, but a specific question is what lets Edmund start searching instead of asking you for more detail first. Tell it what you’d tell a colleague who can’t see the machine. If you haven’t asked anything yet, start with your first answer.
Why specific wins
When your question is specific enough, Edmund launches a search agent — you’ll see a status row such as Hledám v denících (searching the journals). A too-general question launches no agent at all: nothing gets searched and the reply stays generic. So if no status row appears, take it as a cue to add detail and ask again, not as a sign the answer is complete.
What a good technical question carries
Check your question against four things before you send it:
The machine or line section — name it (for example, line section PU6) so Edmund knows where to look.
The concrete problem or HMI code — what is actually happening, plus any fault code exactly as it shows on the panel, letters, leading zeros and punctuation included.
Tell it to search — a word like find (Czech najdi) points Edmund at the documentation instead of answering from general knowledge.
The output you want — say you want the cause and the exact steps to fix it.
One good, one weak
Same fault, two ways of asking:
- Weak: the machine keeps stopping, what’s wrong? — no machine, no code, no task. Edmund can’t tell what to search, so no agent runs.
- Good: the side-shift on line section PU6 doesn’t respond at all; the HMI shows a fault code (type it exactly as shown). Find in the documentation what’s causing this and the exact steps to clear it.
The good version names the machine, the symptom and the code, tells Edmund to search, and asks for cause plus fix — so it can point at the right record instead of asking you first.
A short question still works if it carries a concrete subject. “Find the wiring diagram for PU6” is brief but specific, so Edmund knows exactly what to look for.
A thin answer, or Edmund saying it doesn’t have that, usually means the machine’s knowledge isn’t loaded yet — not that you asked it wrong. Tell whoever curates that machine’s documents.
Keep one fault to one chat, so each follow-up builds on the last answer. Once you have a reply, see reading answers & citations to check where each part came from.