The real test is the app, not the model number
This dashboard has no connection to your kiln. It signs in to Nabertherm’s cloud as you, asks that cloud for your furnaces, and then asks it every ten seconds what each one is doing. The MyNabertherm app does the same thing to the same cloud. So the question “is my controller supported” collapses into a question you can answer yourself in ten seconds, without asking anybody: open the app, and see whether your kiln is in it.
If it is there, it is here. If it is not there — the kiln is not on your Wi‑Fi, or the controller has no network module at all — then there is nothing in the cloud for either the app or this to read, and no model number changes that.
That is also why the list below is a list of names rather than a compatibility matrix. A matrix would imply we had tested each row, which would not be true, and would go stale the first time Nabertherm shipped a controller that is not on it.
The six Series 500 controllers
Said once, because it is the thing most worth knowing: the dashboard does not branch on the model. There is one snapshot format coming out of the cloud and one piece of code reading it, and nothing in that code asks which controller sent it. So the six paragraphs below are not six different answers. Each one hangs the part of the answer that an owner of that controller usually wants first.
B500
The plainest case, and the useful thing to know about it is what happens to the fields a simple run does not fill in. If the kiln is held at a single setpoint rather than stepped through a stored programme, the controller sends no programme name and no segment count, and the page leaves those tiles empty rather than printing “segment 1 of 1”. A value the controller did not send is treated as absent, never as a real zero — a missing temperature and 0 °C are very different things, and only one of them is worth graphing. The firing is still detected, still graphed, and still exports as a spreadsheet, because none of that depends on the programme.
B510
Same family, and the place it shows up is the labelling. The cloud
reports a furnace name, a serial number and the controller’s
software version, and those are what the furnace picker and the
spreadsheet’s summary sheet are headed with. Older controllers
leave the furnace serial out; the dashboard falls back to the only
serial on offer rather than showing a blank. A furnace that has never
been given a name at all is listed as
(unnamed) — it is still yours, still polled and
still exports; it simply has nothing to be called.
C540
Stored programmes, and a numbering trap worth stating out loud. The
cloud reports the programme number zero-based, so what the
controller’s own screen calls P8 arrives on the wire
as 7. The dashboard puts it back before anything displays it, stores
it, or writes it into a spreadsheet, so the number you read here is the
number on the kiln. Getting that wrong would have been invisible and
permanent: every exported file off by one, agreeing with itself.
C550
Segment detail. For a controller that reports them, the cloud gives the segment the kiln is in, how many the programme has, the temperature that segment finishes at, and how long is left in it — which is where “segment 10 of 16, finishing at 1190 °C” comes from. The segment index gets the same correction as the programme number, for the same reason: a twelve-segment programme runs 0–11 on the wire and reads “12 of 12” on the kiln, and the dashboard agrees with the kiln.
P570
Long programmes. Nothing in the dashboard limits how many segments a firing may have: the spreadsheet writes one row per segment the readings actually passed through, so a sixteen-segment crystalline glaze schedule produces sixteen rows and a bisque produces four. There is a limit on how LONG a single run may be before it is closed off, and it is yours to set — two days by default, because two days suits a bisque and would cut a slow crystalline firing in half.
P580
Errors and clocks. The controller’s error code is recorded with every reading, and the export lists when each error began rather than repeating it across the hundreds of readings it persisted for. The controller’s own timestamp is kept alongside the moment our poller received the reading, so a firing can be lined up against the controller’s log or against anything else that happened in the room. On the live kiln the two differ by about eight seconds, which is the cloud round trip.
What it reads from the controller
The same snapshot the app reads, every ten seconds while the kiln is working and every five minutes while it is cold and idle. From each snapshot: the temperature and the setpoint the controller is driving to; the element power as a duty cycle; the segment number, the number of segments, the segment’s end temperature and its remaining time; the programme name and number; the run time so far and the time remaining; the controller’s process state and error code; and the controller’s own clock.
What is kept out of that is a separate question from what is read. Below your start temperature nothing is stored at all — a cold kiln logged every ten seconds is a great many rows saying 27 °C — though it is still polled and still shown live. Where a figure is calculated rather than reported it says so: the energy in kWh is counted from the duty cycle against the power your kiln is rated at, which makes it indicative, and the only honest version of that number comes off a meter.
Pottery, ceramics, and lab furnaces
The controller is what matters, not what is fired in it. A studio bisque and a lab ash test reach the cloud as the same snapshot, so the same temperature curve, segment detail and spreadsheet come out of both. The vocabulary on the page leans towards pottery because most of the people using it are potters; none of the mechanism does.
The one place the difference is real is what the firing is for. A studio wants last month’s glaze firing next to this week’s; a lab wants a file it can attach to a report, with the times, the peak and the hold in it. Both come out of the same kept readings — see the firing log and its spreadsheet export.
Several kilns, and several logins
One cloud login can own several furnaces, and the dashboard asks the cloud for all of them. When there is more than one you get a picker, and it is one picker for the whole app rather than one per view: choosing a kiln chooses it everywhere, so nobody can read kiln A’s temperature while planning kiln B. With a single furnace the picker hides itself, because a menu with one item in it is not a choice.
You can also hold more than one Nabertherm login under one account. That is a different kind of “several”, and it is the common one: kilns get registered under whichever cloud account was to hand, so a studio ends up with two, and anybody watching their own kiln beside a client’s has two by definition. Each login gets a label of your choosing so the list can tell them apart, and each password is stored encrypted and sealed to its own row, so a copy of one is not usable anywhere else.
Each furnace carries its own rated power, because that is a fact about a machine — a plate on the back of one kiln — and not about the login that happens to reach it.
It only reads
There is no command this dashboard can send to a kiln. It signs in, and after that every single request it makes is a read. Starting, changing and stopping a firing stay exactly where they are now: at the controller, or in Nabertherm’s own app.
That is a design decision and not a feature waiting to be built. Nothing on a web page should be able to turn an element on.
Still not sure?
Look around a real firing first — finished firings from a real kiln, with their graphs and their spreadsheets, no account and no sign-up. Then connect your own kiln; you will need the Nabertherm app login and an email address, and nothing else.
If your controller is not one of the six above, or it is and you cannot get it into the app, ask me — I read these myself, and “no” is a perfectly good answer to be given quickly.