Messages and Logs

Where a message lands decides how long it lasts and who else can see it, and that is usually more useful than what it said at the time. The toasts and the footer belong to one browser and are gone at its next reload; the four session message lists and the day's log file are held by the service. Picking the right surface is most of the difference between a specific question and a vague one.

Where a message can land

The application has several places to put a message, and they do not carry the same things.

A toast — bottom right, for a few seconds, then gone. The only surface that interrupts, and the only one that keeps nothing itself.
The footer's latest line, and the recent list behind it — a toast is copied here before it is shown, so this list is the toast's afterlife. Two kinds never arrive: a toast carrying neither message nor caption, and the notices Tool House, the Spindle Capability editor and the Controller panels raise, which are shown once and not kept. A small number of status lines go the other way — written straight here, and never toasted at all.
The footer's session strip — the middle of the bar, drawn once a run has produced something and empty until then.
The footer's background zone — the right end, drawn only while one of the File menu's operations is in flight — Close Project included — naming the operation and the path it is working on.
The Session Messages panel — on the Execution page, four lists kept by the service.
The Log Viewer — on the Help menu, the file the service itself writes for the current day.

The footer summarises; it does not hold. Everything a run reports also goes into one of the panel's four lists, and the panel is where it stays.

Messages a project load raises

Opening or re-reading a project can report holes in it — a referenced STL missing from disk, a side file the project names as a reference that cannot be read, or a runner configuration whose content would not load, leaving the project on a default one. None of these fail the load. The project opens, the body that needed the missing STL simply comes up without its geometry, and the action still reports success. The message is the only thing that says otherwise. Only the project file itself is different: one that cannot be read fails the action, and no project is open afterwards — the open project is released before the file is read.

A side file named as a reference — the machine tool, the spindle capability, the coolant condition, a material, a cutting parameter set, the NC runner — that is missing, locked or malformed reports XmlSource-Read--Failed, one message per reference with the resolved path. The object it held stays empty rather than taking a default, and its panel names the file in red — Referenced file could not be read: <file>; the reference itself is kept, so a save writes it back unchanged, and putting the file back and choosing ReLoad restores the object. What needs the object is skipped when the program plays, and that message belongs to the run, in the Session Messages panel — an NC runner file that cannot be read leaves no runner at all rather than the default one, so no program plays. See Projects.

The controller's lists are read entry by entry. An entry — of the tables the controller keeps with the project, or of its NC runner's dependencies, initializers, syntaxes and semantics — whose kind this version does not know, whose reading fails, or which reads as another kind of entry than its list holds is left out with one XFactory-Load--SkippedUnloadable warning naming it; the rest of the controller and of the project loads, and a save writes the list without it.

An older project file can name its script as a file beside it rather than hold the text, and a script file that cannot be read reports ScriptFile-Read--Failed with the resolved path: the Script command it belongs to comes up empty and holds the reference instead, which a save writes back, a script typed in replaces, and ReLoad reads again once the file is back. Played, that command runs nothing and reports one ScriptCommand-ScriptFile--Unreadable naming the file, on the Session Messages panel's Shell tab.

One neighbouring case goes elsewhere. A mesh-geometry .wct file a raw geometry names but that is not there raises nothing here at all, because the load never opens it; the first word about it comes when the meshed geometry is next needed, and that message belongs to the run, so it lands in the Session Messages panel like any other.

These messages then take a path of their own, and it has a consequence worth knowing before that path is relied on. A project file operation runs outside any session, so the panel's four lists — which belong to the service, and are where everything a run reports stays — never see them. Instead the first five errors and warnings are toasted, anything past that goes straight to the footer's recent list, and one more toast says how many did not get their own. Anything milder than a warning is not surfaced in the window at all.

That leaves the footer's recent list holding the only copy in the window, and that list is the browser's: a reload empties it. So read the messages when a project opens with pieces missing, or read the service log, which has them either way. The Session Messages panel will not.

The left region is this browser's own record and nothing else's. The list behind the latest line is newest first, capped at a hundred entries, emptied by its Clear button — which takes the latest line back to Ready with it — and by a reload, and written down nowhere — nothing about it survives closing the tab. Each entry keeps the wording it was raised in, so switching the language leaves the list as a mixture while the panel's lists re-render at once. The frame page describes the regions themselves: see The Application Window.

Nothing marks the list as having something new in it. The button carries no badge and no dot, deliberately, because a toast has already drawn attention once. The consequence is the failure this page exists to prevent: a message that never toasted at all, or one whose few seconds expired while the window was behind something else, is invisible until that menu is opened by hand. Opening it after an action that seemed to do nothing is the cheapest check available.

The middle strip is the other way round — the service pushes it, so every connected browser sees the same run activity, and each browser keeps its own short ring of the last entries behind it. What it last showed stays on the bar after the run has ended; a project change is what empties the ring and takes the strip away with it. A cursor line carries Sn and the sentence index it sits on; a message line carries whatever anchor the message supplies. Two limits are worth knowing: the strip mirrors the newest message across three of the four lists — nothing from NC Manipulation reaches it — and it is sampled rather than recorded. There is no refresh interval to tune: the service sends the newest message and, while that send is still on its way to the browsers, keeps only the newest of whatever arrives behind it, so a message that lands inside that window is replaced before it was ever sent and never appears on the strip at all. The cursor line is thinned the same way under a fast run. The lists on the service drop nothing.

The session message panel

The panel sits on the Execution page, in the middle column, below the 3D Rendering Canvas. Its header row reads Session Messages and stays visible when the panel is collapsed, so a grey strip with that name on it is the panel, shut.

The whole column can be switched off, and nothing on the page says so. The column quick-toggles at the right-hand end of the menu bar include one whose tooltip reads Toggle the Execution canvas & messages column; with it off, neither the panel nor its header row is drawn, and the page simply looks like it has fewer parts. That choice is the browser's and survives a reload. The expanded or collapsed state of the panel itself is not: it is kept by the service, and is therefore the same for every browser that opens the page afterwards.

Four tabs, each a separate list:

Tab	What it holds
Shell	The session's own lifecycle and routine progress — what began, what finished, what was refused. It is empty outside a session, because the list is created with the session.
NC Diagnostics	What the NC pipeline reported while playing a program.
Step Diagnostics	What was reported against a machining step rather than against program text.
NC Manipulation	What converting a played program to NC, or optimising one, reported. Each such run clears the list before it starts filling it again.

A tab shows a small count badge only once its list has something in it, so an empty sink is a tab with nothing beside its name.

Where a message carries a position, the row shows it in a monospaced anchor column: a step diagnostic names its step, and its block as well when it has one; an NC diagnostic names the block's position in execution order, and its tooltip adds the source file and line where the diagnostic carries them. Not every NC diagnostic has one — a complaint about the pipeline rather than about a particular block has no anchor to show, and shell messages never have one. A run of consecutive identical messages arrives already folded into a single row with a multiplier badge. A row with more behind its one line carries a chevron; clicking it opens what the message brought with it, with a Copy of its own.

A collision is reported the moment it is found, before the step that collides is built, and a run with Pause on Failure on pauses right there. Until that step is built, its row names the program line the message is about, marked step not built, where the step number would be: Resume builds the step, and the row shows the step again. After Stop and Start without Reset, the program plays again from its top and its steps are numbered on from where the stopped run left off, so the number the message was given goes to another step; the row keeps naming the message's own line, and its tooltip says which line the step with that number came from. A Stop while the run is going drops the steps still on their way, and a collision on one of them is marked the same way for good. A licence refusal that holds the run at a step is marked the same way until the step is built, and so is a step whose building failed. The Filter text… box and Export still read such a row by its step number (S19 · Sn 12), not by the line it shows.

Each tab filters independently: a Severity list, a Category list, a Filter text… box, and a Reset. The badge at the right of that toolbar reads two numbers separated by a slash, and they count different things — rows currently shown on the left, raw messages on the right, so folding alone makes them differ, and on a long session the left number stops at the most recent thousand rows while the right goes on counting. That badge is also the tab's connection indicator: it is outlined green only while the connection behind that list is up, and its tooltip names the state. Export writes the tab's filtered rows to a CSV file.

Important

Two different controls on this screen answer to Reset, and only one of them is labelled with it. The labelled one sits in each tab's filter toolbar and clears that tab's three filters and nothing else. The other is the transport group's eject button, which carries no text at all and reads Reset only in its tooltip; it ends the session and empties three of the four lists — Shell, NC Diagnostics and Step Diagnostics. Only NC Manipulation is left standing, and the same is true of a project change: opening, reloading, creating or closing a project empties the same three and leaves that one alone. It is the list to read for what the last conversion or optimisation said, long after the run that produced it has been reset away.

The lists are the service's, not the browser's. They survive a reload, a move to another screen and a second tab opened on the same service, and two browsers watching the same run read the same four lists.

That is also what makes collapsing the panel harmless. Collapsing it takes it down entirely rather than hiding it, and all four connections drop with it. Nothing is lost, because nothing was being held here. What does not come back is the arrangement: re-expanding builds the panel fresh, on the first tab, with every tab's severity, category and text filters back at their defaults.

The service log

The Log Viewer is on the Help menu, below a separator — its last entry, except on the installed HiNC, which adds Check for Updates… after it — and opens in place at /preference/log. The entry reads as the page's own title, Log Viewer.

The viewer shows one file: the one this instance of the service is writing for the current day. There is no way to reach an earlier day's file from this page.

Read the header row for what is on screen — the day the file covers, the time it was last fetched, and how many lines came back. The pane opens at the end of the file, which is where the newest lines are, and stays at the end through later fetches unless it has been scrolled away from the bottom.
Press Refresh for a fresh copy, or switch Auto on and choose an interval — two, five, ten or thirty seconds — to have it re-fetched on its own.
Take the text with Copy, or the whole file with Download. Both are unavailable while there is nothing loaded. Download saves the file as log-<date>.txt, without the instance name the file carries on the service, so rename it when collecting from several instances.

Switch Auto off before leaving the page. Moving to another screen does not stop it: the page is kept alive behind the one on screen and goes on re-fetching at its interval. Reloading the browser stops it, and so does a project change, because both rebuild the page area from scratch.

An empty file and a missing file look almost alike and are not the same thing. Both show No log file for today., and both hide the line count entirely — no count is drawn at all rather than one reading zero, so the caption simply being absent is itself the signal that nothing came back. The day badge is what separates them: when the file exists, the day comes from the service's own clock; when there is no file at all, it comes from the browser's clock in UTC, which need not name the same day — before eight in the morning in Taipei it names the day before. The service itself never leaves the file empty: the day's file comes into being with its first line already in it, so an empty file is one that something outside the service emptied.

A fetch that fails replaces the pane with the reason and a Retry button, and posts the reason to the footer under the viewer's own name — one of the few lines that reaches the footer without ever having been a toast.

The Log Viewer at /preference/log, on a service that has been running for a while. The header carries the page name, the day the file covers, when it was last loaded and its line count, then the Auto toggle — off here — beside its interval, and Refresh, Copy and Download. Each line in the pane starts with its time and its level, then names the part of the service that wrote it.

The Log Viewer: a header row with a day badge, a last-loaded time, a line count, an Auto toggle switched off beside a 5 s interval, and Refresh, Copy and Download at the right; below it a dark monospaced pane, scrolled to the end of the file, of timestamped lines, each carrying its level and the part of the service that wrote it

This is the log of the service, not of the browser. A message seen in the footer reaches it only if the service also recorded it, and much of what it holds was never shown anywhere in the application.

What the file holds

One line per event worth reading back:

Start-up — a line naming the instance, its build and API version, the working folder, the admin directory and whether sign-in is on, then the address the service listens on.
Project operations — one line for each load, reload, new, save, save-as and close, naming the project file and how many milliseconds it took. A load or reload also counts its load errors and warnings, and is written as a warning when there was an error; the messages that load raised are in the file too.
Runs — a line when a run starts and one when it finishes, is stopped or ends, giving the time it took, the project, the number of steps, and the errors and warnings counted separately for NC, step and shell. The closing line is a warning when the run had an error. A single step recomputed while nothing is playing is not a run and writes neither line.
What the engine warned about — every warning and error from the four message lists, with its message id and, where it has one, its anchor (Sn and the sentence index, or the step). One message id is written at most twenty times in a run; the run's closing line says how many repeats were left out.
Sign-ins — a sign-in, a sign-out, and a refused sign-in, which is a warning carrying the name tried and the address it came from.
Failures — anything the service did not handle, and the native core's own lines: a licence failure is critical, a graphics failure an error, and software rendering a warning.
Screens connecting — a canvas set up and torn down, its first frame drawn, the Execution page initialised.

Per-frame and per-input chatter, each message hub connecting, visibility changes, frame compression and status broadcasts are written at the Debug level, which the file leaves out unless its level is lowered.

Where the file is

The file is log-<instance>-<yyyy-MM-dd>.txt in a logs folder under the service's working folder. The instance is the environment name the service was started under — Production unless something set another — so several instances sharing a working folder keep separate files, and the Log Viewer of each shows its own. A second copy started under the same name in the same folder writes log-<instance>-<process id>-<yyyy-MM-dd>.txt instead and says so on its first line. A folder the service cannot create or write to is replaced by logs under the working folder, again with a note on the first line.

On a copy the HiNC installer set up, the working folder is its data folder, %LocalAppData%\HiNC\webservice — or the data folder in a portable copy's own folder — so the files are in the logs folder there, out of reach of an update; see Installing HiNC on Windows. Whatever the copy, the service prints its working folder at start-up, on the Data and logs line of its console output.

Files older than thirty days are deleted when the service starts and each time the day changes — this instance's own, and any carrying no instance name at all, log-<yyyy-MM-dd>.txt, which is how the file was named before instances got a file each. Other instances' files are theirs to delete.

Changing what reaches the file

The file has levels of its own, set under Logging:File in the service's settings and independent of what the console shows. On a copy the HiNC installer set up, they go into appsettings.local.json in its data folder, or into appsettings.local.<instance>.json for one instance — see Installing HiNC on Windows; the appsettings.json beside the program is replaced by every update. A copy put in place by hand reads them from its appsettings.json, or from the appsettings.<instance>.json beside it, which overrides it key by key. Out of the box it takes Information and above from the service itself and Warning and above from the framework under it, with the framework's start-up lines kept, and its line for each request refused for a host name the service does not admit. A key names the start of the category printed on each line, and Default covers every category no other key names.

{
  "Logging": {
    "File": {
      "LogLevel": {
        "Default": "Warning",
        "Hi.Engine": "Error"
      },
      "Directory": "../HiNC-Logs",
      "RetainDays": 90
    }
  }
}

This keeps only warnings and worse — apart from the framework's few start-up lines and its refused host names, which keep their own Microsoft.Hosting.Lifetime and Microsoft.AspNetCore.HostFiltering keys until those are set too — and from the engine's message lists only errors; writes the files to another folder, where a relative path is taken from the working folder; and keeps ninety days of them — 0 keeps every file. The same keys can come from environment variables instead, as in Logging__File__LogLevel__Default=Warning. Restart the service after the change. To bring back the detail left out by default, set a category — or Default — to Debug.

Which surface answers which question

To find out	Read
what the last action reported	the footer's latest line
what was reported while another screen was open	the recent list behind it — the only copy the window keeps
where a run has got to	the footer's session strip
whether one of the File menu's operations is still running	the footer's background zone
what the session itself started, finished or refused	the Shell tab
why a program did not do what its text says	the NC Diagnostics tab
why a move behaved the way it did	the Step Diagnostics tab
what the last conversion or optimisation reported	the NC Manipulation tab, which a reset does not clear
why a project opened with pieces missing	the footer's recent list, or the Log Viewer — not the Session Messages panel
what the service recorded, shown or not	the Log Viewer

Table of Contents