Asking good questions
Edmund answers from the open project's knowledge in plain language, and the way you phrase a question shapes how useful the answer is.
EveryoneEdmund answers the machine you have open, using that project’s own knowledge. You don’t need special wording or keywords. Tell it what you’d tell a colleague who can’t see the machine, and give it the few details that point at the real problem. If you haven’t asked anything yet, start with your first answer.
What to include
A good question usually carries three things. The more of these you give, the closer the first answer lands.
- The symptom — what is actually happening, or what stopped.
- The machine state — running, stopped, or starting up, and any mode it’s in.
- Any fault or alarm code — written exactly as it shows on the panel or HMI, including letters, leading zeros, and punctuation.
The exact code matters most. A code copied as it appears lets Edmund match it against the machine’s own documents instead of guessing from a paraphrase.
One problem per chat
Keep a single fault to a single chat. When you stay on one problem, each follow-up builds on the last answer and the thread reads back cleanly later. If a new, unrelated fault comes up, open a fresh chat for it rather than mixing the two.
A good question and a vague one
Same fault, two ways of asking:
- Vague: the machine keeps stopping, what’s wrong?
- Good: infeed conveyor stops a few seconds after start, drive shows fault
F0011on the HMI, no product jammed.
The second version names the symptom, the state, and the exact code, so Edmund can point straight at the relevant page instead of asking you for those details first.
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, and the next answer improves.
Once you have an answer, see reading answers & citations to check where each part came from.
