The ones that actually get asked, answered straight. If your question is about how to drive the app, the manual is the other page.
You do. Your presses, your molds, your process, your studies. MoldMove holds it to run the service and has no claim on it. That is in the contract in plain words, not buried.
No, and it is not a promise resting on good intentions. Every query that touches plant data carries your account's identifier, taken from your signed-in session and from nowhere else — never from a URL, a form field or a header, so there is nothing for anyone to tamper with. There is no path in the software that reads across accounts.
It is tested rather than asserted: a suite of cross-account probes runs against the live database and has to pass before anything ships — reading another plant's record by its identifier, listing, deleting, writing into their identifier, forging an account id in the request body and in the query string. All of them are refused, and a record belonging to someone else answers exactly the way one that never existed does, so the refusal itself gives nothing away.
Here is the honest answer, which is more useful than a comfortable one.
We have administrative access to the database, the way every software vendor does. We do not use it to look at your work. The application gives us no route to your data — we would have to go around it, and doing that leaves a trace. The contract forbids using anything seen for any purpose other than fixing your problem, and forbids selling or pooling your process data outright.
What we are building towards, and do not have yet, is support access you grant from inside the app: recorded, scoped to one session, and gone when that session ends. Until that exists, the answer is “we don't, and here is the record” rather than “we can't.” Anyone who tells you their hosted software cannot technically see your data should be asked how.
No. Process, part, mold and customer data is your trade secret and never leaves your account.
There is one thing we do intend to build, and it is worth being precise about the line. Machine specifications — a press's screw diameter, stroke, intensification ratio, platen and daylight — are objective facts about equipment somebody else manufactured, stamped on a nameplate the builder fitted. Those we would like to pool into a shared reference library, because a library of them makes the app better for everyone and nobody's secret is in it. Anything about your parts or your process is on the other side of that line and stays there. If and when the shared library happens, it will be disclosed and agreed before a single upload, not retrofitted.
You have thirty days. Deleting a record does not remove it — it marks it, and it drops out of every list until you restore it or the window runs out. Saving new content over a deleted record brings it back too.
Yes. Every save, delete, restore, sign-in, invitation and export is on your plant's activity log with the name of whoever did it and when. The log is append-only: nothing in the app edits or removes a line, and removing a person from your account does not erase what they did while they were on it.
One click, any time, as a single file with your machines, materials, studies, members and full activity log in it. It contains no passwords or tokens — it is your records, not the keys to your accounts.
Export never switches off. Not when a subscription lapses, not when an account is closed, not the day before data is due to be removed. A tool you cannot get your work out of is a tool you should not put your work into.
| First 14 days | Read only. Everything you entered is still there and still openable. Nothing new can be saved. |
|---|---|
| Days 14 to 90 | The account closes. Nothing is deleted. Export still works, and renewing brings all of it back exactly as it was. |
| After 90 days | The account and its records are removed — and only after two notice emails, the second of which says it is the last. |
An account is never removed if the warning did not actually go out. A lapse is usually an expired card or a purchase order that needs re-issuing, not a decision.
Any of them, including the old ones. What the app needs is what is on the nameplate: screw diameter, stroke, tonnage, and the intensification ratio for a hydraulic machine. Make and model do not have to be in any list.
Those are where it is worth the most, because the technician has nothing else helping them. A press with a hydraulic gauge and a flow control has no setpoints to map, so the output for one is a target sheet and how to verify it — hit this shot volume, this plastic pressure, this fill time, and here is how to confirm you got there. On a machine like that the pressure conversion through the intensification ratio is the job.
On a hydraulic press, the injection cylinder is larger than the screw, so hydraulic pressure is multiplied on its way to the polymer. The intensification ratio is that multiplier — typically somewhere between about 8 and 14. It is on the nameplate or in the builder's manual.
Do not guess it and do not borrow it from a similar machine. It is the single number with the most leverage over everything the app produces. An all-electric press multiplies nothing, so its ratio is 1.
Because velocity is not what the polymer feels. A bigger screw moving slower delivers the same volumetric flow rate, which is what actually governs the fill. The app holds the flow rate constant and works backwards to whatever velocity that press needs. Large changes in the setting are normal and correct; identical settings between two different screws would be the error.
Same reason, one layer down. Matching RPM between a 30 mm screw and a 52 mm screw gives the melt far more shear on the bigger one. What matches is surface speed at the flight, so 120 rpm on 30 mm comes out as about 69 rpm on 52 mm.
Yes, and it handles pack and hold steps and a back pressure profile as well. Every stage boundary converts as a volume of polymer rather than a screw position, and every stage velocity as a flow rate.
If the target control has fewer stages than your profile, the app says so and leaves the consolidation to you — which stages merge changes the fill, and that is a technician's decision, not a piece of software's.
The ones it can see from data, yes, and they are the reason there are two panels rather than one. Will it fit answers whether the steel goes in. Will it work in it answers whether the mold works once it is in: hydraulic core pull circuits against what the tool needs, the knockout pattern, ejector force as distinct from ejector stroke, whether the screw can melt fast enough for the cycle, whether the shot is a sensible share of the barrel at either end, what a smaller nozzle orifice does to the pressure the cavity actually sees, whether the water supply can feed the mold, and what the material's shrink band means for the dimensions.
Two of those deserve a sentence each. A mold with two core pulls going into a press with one circuit does not run, and nobody finds out until the tool is hanging in the machine — so that is a refusal, not a note. And a shot far below the barrel's capacity is a warning too: a small movement of a big screw is a large proportion of the shot, and the weights scatter.
Nine checks: through the tie bars in both orientations, platen coverage, shut height inside the machine's window, enough daylight for the shut height plus ejection plus getting the part out, ejector stroke, locating ring against the platen bore, mold weight against the platen rating, and clamp tonnage against projected area. Each line names the number that decided it.
A field left blank never reads as a pass. It says which number it is waiting for.
The parts that matter for a transfer: how far the mold has to open for the arm to get in, what the arm is carrying against its rated payload, the ejector interlock, and the cycle time it adds. A robot program does not transfer — positions are taught against one cell — so the app carries the requirements the new cell has to be taught to, and records the old program name as evidence of what was running.
No, and you should not. The area and the volume fields each carry their own unit selector: in², cm² or mm² for area, and cubic inches, cc or mm³ for volume, independent of the inch/millimetre toggle. Enter the number in the unit you were handed it in.
The reason this exists rather than being left to the user: 0.22 cu in is 3.60 cc is 3,605 mm³. A conversion done by hand on a calculator is where a decimal point goes missing, and a part volume off by a factor of ten is a shot size off by a factor of ten.
Yes — a startup and validation checklist that prints from the setup sheet, worked in the order a process technician works in. Heats and water and residence, purge and plastication, a short-shot ladder, pack and hold and cushion, cycle and stability, and then a validation section that only applies if the run is a qualification.
The right-hand column carries the app's own numbers — the melt window, the coolant flow per circuit, the residence time against the material's limit, the target shot weight, the transfer position for each rung of the short-shot ladder. Every box is still blank. The value is what to aim at; the tick is a person saying they saw it.
Capability is left blank on purpose. MoldMove does not compute Cp or Cpk, and the sheet says so where the number belongs rather than implying a study was done.
Yes. It installs to a home screen and works at phone width. The printed sheets exist because a screen at a press is not always the right tool.
Yes, and it is enforced rather than requested: signing in ends any other session on the same account, so two people sharing one login spend the day throwing each other out. Separate logins are also what makes the activity log worth anything — a record that says which of your four techs changed a press is useful; one that says “the shop login” is not.
Invitations come from the account owner. There is no way to attach yourself to a plant you were not invited to.
Yes, for the branch that is built. The Troubleshoot tab reads the press, the mold and the material off the setup sheet and asks for the two readings no machine hands over: peak pressure during first stage, and how full the part is at transfer.
It runs a capability gate first. If the shot is bigger than the barrel, or the press cannot move polymer fast enough, or filling the mold needs more pressure than the machine has, that is the whole answer — no process advice at all, because tuning advice for a part that does not fit the press wastes a shift. It names the shortfall with a number.
Then it forks on the one question that decides everything below it: is the press at its pressure ceiling. Above the line the fill is not velocity controlled and no amount of velocity setting will help, which is the single most expensive wrong turn in the trade. Below it, the next question is the transfer position — and a part short at transfer is a transfer-position fault, not a pressure fault, which is the most common real cause.
It gives a direction and a bounded range, never a setpoint. It ends in a study or a physical check rather than a list of eight things to try. It writes nothing. And where the tree is not built — cushion, cavity balance, trapped gas — it says so instead of guessing, because those branches need thresholds nobody has signed off yet.
No, and be wary of anything that says it does. A documented transfer built on machine-independent variables can reduce what a requalification on a second machine needs — that is the published finding of a consortium of medical device manufacturers, not our claim. The first full validation on the originating machine still has to happen.
Not in the formal sense a regulated plant means by that word, and we will not pretend otherwise. What exists is a test suite in the several hundreds of assertions, run against the deployed code before every release, each one there because something specific could go wrong. That is the beginning of validation evidence, not a substitute for a package. If you need one, tell us what your quality system requires.
No. Matching machine-independent variables is a real method that produces dimensionally sound parts — it has been demonstrated across four very different presses by people who had to prove it. Matching pressure curves to a validated template needs the machine instrumented. Matching cavity pressure needs sensors in the tool. MoldMove does neither, and produces the record that an instrumented run attaches its curves to.
All of them are on a Thresholds page, and yes. Twenty-nine house numbers — where “tight” begins on a clamp, how full a part should be at transfer, what cushion variation indicts a check ring — each prefilled with what MoldMove recommends, each with a Custom box beside it. Untick Custom and ours comes back; your number stays in the field, so trying one costs nothing.
Some of them are not ours to recommend at all. A residence limit and a melt window come off the material data sheet. A cushion tolerance, a velocity linearity and a pressure repeatability come off the machine builder’s published specification. Those rows read from the record and carry no MoldMove number, because putting one on somebody else’s spec would be inventing it.
Changing a threshold is an owner or quality decision, not a shift decision. And the page prints: every threshold, the number in force, which tier it came from, our recommendation beside it, and a line to sign. None of them is a standard and the sheet says so — they are the lines this app draws, and they need a name on them.
Yes — the number comes from you. If your quality system issues process sheet numbers, MoldMove takes yours rather than inventing a parallel scheme for you to reconcile. It goes on the record and prints on every sheet, so a print can be filed where your quality system expects to find it.
It can, and what makes it mean something is that it is bound to the contents. An approved record carries who approved it, the date, and a fingerprint of every value in it. Change a number afterwards and it reads “edited since” — on the screen and on the printed paper, which says plainly that the print does not match what was approved. Saving an edited sheet drops the approval and says so.
What this is not: a 21 CFR Part 11 electronic signature. There is no signature credential, no re-authentication at the point of signing, and no validated system behind it. It is an approval of record with tamper-evidence, which is a useful thing and a smaller thing. If your quality system needs the regulated version, say so and we will talk about what it actually requires.
No, and this was a design mistake we fixed rather than a feature we planned. The first version cleared the approval and wrote over the record, which destroyed the thing that had been approved. It now forks: the approved version keeps its content and its approval untouched, the edit becomes a new record that supersedes it, and the chain links both ways. The old one is labelled superseded in the picker, says so when opened, and prints SUPERSEDED across the header.
Every printed sheet also carries the record id and a fingerprint of its contents, approved or not, so a sheet found in a folder is traceable back to what produced it.
Yes. Four roles: owner, quality, technician, read-only. Only an owner or a quality account can approve. A technician can do the work and save it and cannot release it, and a read-only account can read and export and cannot write. It is enforced on the server, so it is not a matter of which buttons the page happens to show — and an approval records the signed-in account alongside the typed name, so a signature on paper traces back to a login.
Yes, per account, under Security: a password plus a six-digit code from any authenticator app. Two things about how it is built, because both are places this is commonly done badly. It is only switched on once a code has been accepted, so nobody ends up locked out by an app that did not really take the secret. And a code cannot be used twice, even inside its own thirty-second window — a shop floor is a place where people read over shoulders.
Turning it off needs the password and a current code together.
The app shows the last records that device saw and says so, with the time they were last refreshed. Saving does not fall back — it fails and says it failed, because a setup sheet that looks saved and is not is worse than one that plainly refused.
No, and this was a deliberate decision rather than a happy accident. Nothing is stored as a control reading. A transfer position is kept as inches of screw stroke, a hold pressure as plastic pressure, a velocity as a flow rate the screw area can be divided back out of. Change the units on the control, or convert a press from psi to bar, and the sheet still describes the same process — it comes back on screen in whatever that control now shows and the target press's numbers do not move.
The reason to care: a record that stored “28.5” because the screen said 28.5 becomes a 28.5 inch shot on a 30 mm screw the day somebody retrofits the control. That is a number that goes on a press.
Two parts. A one-time setup, priced per press with a two-press minimum, where we enter your machines from the nameplates and manuals — screw, stroke, intensification ratio, platen, daylight, ejector — and hand you a machine data sheet for each one that you keep whether or not you continue. Then a subscription: a base fee for the plant plus an amount per press, with unlimited users.
Why two presses minimum: the entire product is moving a process between presses. One proves nothing.
Because it is work, and because it is the part that makes the app useful on day one instead of week six. A trial of an empty app is a demonstration of blank tables. The setup happens first so that the trial runs on your real presses.
No, and what makes that fair is that you get something for it: your presses fully specified, ratios computed, and a data sheet per machine that is yours to keep. If you walk away you still have work product you did not have before.
Because process technicians work shifts. Charging per seat means a plant buys one, gives it to the lead, and the app becomes one person's tool instead of the plant's record. Per press tracks the value, needs no policing, and makes shift coverage free.
For a launch, usually yes, and it is the fastest way to get a fleet in and a first job moved. It is a separate line on the quote with travel accounted for, because bundling it into a per-press price means somebody is always paying for a trip they did not need.
You export everything and you still have your machine data sheets, your printed setup sheets and your studies. The retention schedule and the export exist so that this question has a real answer rather than a reassuring one. Ask it of anyone selling you software that holds your process.