Projects

A project is the whole of what a simulation runs against: the machine tool, the spindle capability, the background and coolant conditions, the fixture, the workpiece, the tool house, the controller and the NC programs a mission plays. It is a project file together with the folder that file sits in, and the Project dropdown on the menu bar is where one is created, opened, saved and closed. The equipment and mission screens are editors on whichever project is open, so a change of project reaches all of them at once.

Where it is

The Project dropdown, at the left of the menu bar beside Page and Preference. Its first row is a read-only field holding the path of the open project — selectable, so it can be copied — and reading No Project Loaded until one is open. The path is written relative to the admin directory the service was started against rather than as a location on the machine running it.

That row is the only place the path stays put; everywhere else it is transient — a line drawn while something is happening, or a record of something that has. While a project action is running, the footer's background zone names the action and the path together, as Loading project: … and its equivalents for the other entries. The toast that reports the finished action carries the path as its caption, and that line outlives the toast in the footer's Recent messages list. The service holds one open project rather than one per browser, so every browser connected to it is working on the same project.

What each entry does

Entry	What it does
New	Creates a project at a chosen path and opens it, refusing a path that already holds a file
Load	Opens an existing project file
ReLoad	Re-reads the open project from its own path, discarding anything unsaved
Save	Writes the open project back to its own path
Save As	Writes it to a chosen path, which then becomes the open project
Close Project	Closes it, leaving the application with no project

ReLoad, Save, Save As and Close Project are greyed out until a project is open. New and Load are always selectable.

The three entries that need a path — New, Load and Save As — open the shared file browser as a picker, filtered to HiNC Project (*.hincproj). It never offers the Resource root: the Admin root is always there, and the Project root beside it only while a project is open. It opens at the Admin root — in the folder the open project sits in, when there is one. Saving forces the extension, so a name typed without one still gets it.

What a project actually is

The project file is an XML document of references. Values that mean nothing outside this one project are written into it directly, while the pieces that are shared, large or edited on their own — the machine chain, the spindle capability, the workpiece and cutter materials, the cutting parameters, the mesh geometry — are held as references to files beside it, each named by a path relative to the project file's own folder. Opening the project file in a text editor shows those references rather than what they point at.

Important

A raw geometry that points at nothing does not stop the project opening; a missing side file does. Load and ReLoad read what they can and report what they could not — a missing STL, say — and the project comes up with that body simply having no geometry, the action still reporting success. A mesh-geometry .wct file a raw geometry names is quieter still: the load neither opens it nor mentions it, and the first word about it is a warning raised when the meshed geometry is first needed. A side file named as a reference is the other case altogether: when the machine chain, the spindle capability, a material or a cutting parameter set is not where the project file says it is, the load fails outright — no project opens, and the failure is reported as an error rather than as a diagnostic beside a successful load. Where a load does succeed with a hole, the message is the only thing that says otherwise, and it is not kept where a run's messages are kept: see Messages a project load raises.

A project is therefore a folder at least as much as a file. Copying one to another machine, archiving one, or handing one to somebody else means taking the folder.

The demo project's own folder, at /util/file-explorer/Project. The File Explorer's root switcher, beside the page name, is set to Project — the root that exists only while a project is open, and that resolves to the folder holding the open project file — and the path field reads ., the root folder itself. Three folders sit at the top, MachineTool, NC and Output, and five files below them: the cutting parameters and the workpiece material, the project file itself at 138.1 KB, the spindle capability, and a cutter material. The right-hand pane is the explorer's text editor, waiting on a file to be given to it.

The File Explorer showing the open project's folder under the Project root: the folders MachineTool, NC and Output above five files with their sizes, among them the project file at 138.1 KB and four side files named for a cutting parameter set, a workpiece material, a spindle capability and a cutter material, with the empty text editor pane on the right

Warning

A Save As into a new folder can produce a project that finds none of its programs. Save As writes out the side files the project file references — the machine chain, the spindle capability, the materials, the cutting parameters, and the STL meshes the equipment and the workpiece name — into the new folder and at the same relative place. Two things travel as a path with nothing behind them: a mesh-geometry .wct, which is never written out at all, and an STL that was already missing when the project opened, which is deliberately left missing rather than replaced by an empty file. Neither are the NC programs a mission plays: the project records each as a path, and nothing on the save side copies the file. Nothing rewrites those paths either, so the saved project still asks for NC/…, now underneath the new folder, where nothing has put it. The programs have to be brought across by hand, or the Save As aimed at a folder that already holds them.

The folder a run writes its output into is named the same way, and it is not a dependency of the same kind: nothing has to put it there, because the writers create it on demand under the folder the open project was read from. A Save As does not move it — a run still writes beside the folder the project came from, until that project is opened at its new path.

What a project change does to the rest of the window

What decides a rebuild is the path changing, not the entry chosen. New, a Load that picks a different project, Close Project and a Save As to a location other than the one already open all change it, and each throws away every screen the browser has built and rebuilds against whatever the project is afterwards — which is what stops one screen showing values from a project that is not open any more. ReLoad always rebuilds as well, being the entry meant for re-reading the same path. A Load that picks the project already open rebuilds nothing: the file is read again on the service, but the screens keep what they were showing. The Application Window states the same rule from the frame's side, and covers what a rebuild costs a screen carrying unsaved state.

How far a change travels beyond the browser that made it is not the same for every entry. The three that change which project the service holds open are announced to every browser connected to it, so all of them follow. ReLoad re-reads the same path: the browser that asked for it rebuilds, while a second browser — whose path did not change — carries on with what it was showing.

Save As announces nothing at all. The service moves onto the new path, and only the browser that performed the Save As is told, in the reply to its own request. Every other browser goes on displaying the old path in its Project dropdown, although the service is working with the new one underneath — so a Save from any of them writes to the new path. A stale row corrects itself the next time the service reports its state to that browser: a reload, the browser's status connection dropping and coming back, another project change, or a run being started, paused, finished or reset from any browser.

New, Load, ReLoad, Save and Save As take a turn each. A second one asked for while the first is still running is refused rather than queued, and the refusal arrives as a warning reading Another project operation is in progress. Please try again. Close Project takes no part in that turn-taking: it neither waits for a running operation nor holds one off, and it never raises the warning.

Losing work

Nothing keeps track of whether the open project has unsaved changes. No marker in the menu bar or in the path row says the project has been edited, there is no prompt in front of ReLoad or Close Project, and nothing at all stands in the way of a browser tab being closed or reloaded. Both ReLoad and Close Project discard what the service is holding and has not written, in silence and at once; a Save beforehand is the only thing that keeps it.

Save As asks nothing either. Its dialog opens on the open project's own folder with the open project's own file name already filled in, and nothing checks whether a file is already at the path chosen: confirming writes over whatever is there. Confirming on the name as it arrives therefore overwrites the project that is open — which is harmless, being what Save does — but the same confirmation one folder away overwrites a different project just as quietly. New is the one entry that refuses: it will not create a project where a file already exists, and reports that as an error whose message can carry the location in full.

Before one is built

The data to collect from the machine owner before a project can be built is a checklist of its own: Project Data Checklist. The order the pieces then go together in is Project Construction.

Table of Contents