Operation & Maintenance
CNC remote support is a diagnostic channel, not a repair. It lets somebody who knows the control look at the alarm history, the parameters, the PLC states and the drive diagnostics while the machine is stopped, which is often enough to identify the subsystem at fault and to correct configuration, parameter or programming problems on the spot. It cannot change a bearing or reseat a coupling. What decides whether the channel is usable is decided long before it is needed: a network path to the control, a current parameter backup, the electrical drawings and the alarm record.
What CNC remote support can and cannot settle
The value of CNC remote support comes from being able to see the machine’s internal state rather than a description of it. That is a large advantage in a specific set of faults, and no advantage at all in others. Knowing which is which stops a session from being arranged for a problem that remote access cannot touch.
| Suited to remote diagnosis | Not suited to it |
|---|---|
| Alarm interpretation: what the message means for this control and this machine configuration | Mechanical wear: a failing bearing, a worn guideway, a seized axis, a damaged screw |
| Parameter and offset problems, including values changed by accident | Anything that requires a component to be removed or measured with a tool |
| Drive and servo configuration, following error behaviour, tuning and load traces | Contamination, coolant leaks, chip jams and physical obstructions |
| PLC, interlock and sequence faults — for example a clamp confirmation that never arrives | Electrical damage that has to be found by continuity testing at the cabinet |
| Programming and program transfer problems, feed and rapid behaviour, reference procedures | Anything where the machine cannot be powered or connected safely |
| Comparing current parameters and diagnostics against the backup taken when the machine was installed | Faults that only appear under cutting load, unless the session can be run during production |
Two conclusions follow. First, cnc remote support is most useful at the start of a fault, when the question is “which subsystem is this?” rather than “how do I replace it?”. Second, it is far more effective when the machine’s own documentation is available, because the alternative is a conversation about what the machine ought to be doing. That documentation is what the build and testing records at how DAHUI MT documents its machines are intended to support.
The fastest version of the channel is a good record
A machine that arrives with a current parameter backup, electrical drawings, the component list and a written alarm history can often be diagnosed from the record alone — by email, without any connection at all. The network path is useful; the documentation is what makes it productive.
The four prerequisites
A network path to the control. This is the part that cannot be improvised on the day. The machine may sit on an isolated workshop network with no route to the outside, on the plant network behind a firewall, or on no network at all. Each case has a different solution, and the decision belongs to whoever owns the site’s network rather than to the machine’s operator. The usual arrangements are a temporary, supervised connection granted for a session; a dedicated remote-access appliance kept off the production network; or a diagnostic laptop connected locally to the control and used on a call. What matters is that the route is known, permitted and tested while the machine is healthy.
A control that supports it. Most modern controls provide remote viewing, a diagnostic port, or at minimum a screen-sharing route through a PC connected to the machine. Confirm which applies to your control and what it needs — an IP address, a user level, a licence, or an application installed on the machine’s own PC. The capability is documented by the control builder; where the control is a Siemens system, for example, the access and diagnostic facilities are described in the control documentation.
A documentation set. A parameter backup that is current — not the one taken at installation two years ago — plus the electrical drawings, the PLC or ladder copy if the machine has one, the component list with the control, drive and bearing identifications, and the alarm history. Without a backup, any parameter change made during a session cannot be reversed, which is the line between a diagnosis and a gamble.
Somebody at the machine. A person who can power the machine, operate the controls under instruction, look inside the cabinet, and answer the question “what is it doing now?”. Remote diagnosis is a conversation with a pair of hands at each end, not a remote-control operation.
How a diagnostic session runs
A session that resolves a fault follows a recognisable pattern, and the pattern is worth knowing because most of the time saved in cnc remote support comes from the first two steps rather than from the connection itself.
The fault is reported with evidence before anything is connected: the exact alarm text and number, the alarm history in order, what the machine was doing, and what has already been tried. That report is what allows the person at the other end to arrive at the session with a hypothesis instead of a blank screen, and it is the same information that makes an email exchange productive. The structure of that record, and the diagnostic order that follows from it, are set out in how CNC alarms are read.
Then the session runs observation, hypothesis and test in a loop. The observer looks at the state the machine is actually in — alarm list, parameters, offsets, PLC states, drive diagnostics, load traces on an axis that is being jogged — and the person at the machine runs the small test that distinguishes between two explanations. Good sessions change one thing at a time and check the effect, which is why they are slower at the start than somebody guessing loudly.
A conclusion is either a specific correction — a parameter restored, an offset corrected, a programme reloaded, a sequence fault cleared — or an identification: this subsystem, this component, and this is what to measure or order next. Both are results. A session that ends with “we think it might be mechanical” has produced a hypothesis, which is worth something but is not a repair.
Access, security and change control
A CNC control is a production asset and often part of a plant network, so remote access is a governance decision rather than a convenience. Four rules make it defensible.
Access is temporary and supervised, not permanent. A route that exists permanently for occasional use is a route that can be used at any time by anyone who learns of it, and the machine is unlikely to have any monitoring on it. Grant the connection for the session, over a means that the site’s network owner has approved, and close it afterwards.
Every change is recorded, with the value before and after. A parameter that has been altered during a session is the classic unfound cause of a fault that reappears months later, and the only defence is the record. A current parameter backup should be taken before the session begins and again when it ends, so the machine’s configuration has a known state at both ends of the work.
Nothing is changed that cannot be reversed, and safety-related logic is out of scope entirely. Interlocks, guard monitoring and emergency stop circuits are not adjusted to make a message go away, on site or remotely. Where a change is needed to something that affects how the machine behaves under cutting, it is made deliberately, tested, and written down.
Finally, the equipment on the other side matters. A laptop used for diagnosis should carry the control software and the machine’s backups, and should be treated as a production tool: updated, backed up, and not also used for browsing the internet on a workshop network. The practical consequence is that remote diagnosis is easiest to arrange between organisations that both have a process for it.
Preparing the machine before you need it
Almost everything that makes cnc remote support effective is prepared while the machine is healthy, and the work is small. Establish where the network route would be and test it once, deliberately, on a machine that is working — a channel that has never been exercised is not known to work. Take the parameter backup on a routine rather than after a fault, and store a copy off the machine as well as on it. Assemble the documentation set in one place: manual, electrical drawings, ladder copy, component list, lubrication chart, alarm list from the manual.
Then record the machine’s own reference data while it is healthy, because that is what a diagnosis compares against: the parameters as they should be, the offsets, the axis load readings on a normal jog, the spindle warm-up behaviour, and the alarm history so far. A machine that has never had its normal state written down can only be judged against what somebody remembers.
The same preparation covers the human side. A named technical contact on each side, an agreed way to report a fault, and a shared expectation about response — all decided before the machine is installed, when both parties are motivated and nobody is under pressure. The installation stage is the natural moment, and the records produced there are the ones a diagnosis will use later; the checklist for that stage is in the installation and commissioning checklist.
The session record
A diagnostic session produces a document as well as a repair, and the document is what makes the next occurrence quicker. Keep it with the machine file.
| Machine identification | Model, machine number, control and drive model, and machine hours at the time of the session |
|---|---|
| Fault reported | The alarm text and number, the alarm history in order, what the machine was doing, and what had already been tried |
| Connection used | How the session was connected, who authorised the access, when it was opened and when it was closed |
| What was observed | The states examined — parameters, offsets, PLC states, drive diagnostics, load readings — with the values found |
| Tests performed | Each test run and its result, so that a later occurrence does not repeat work that has already been done |
| Changes made | Every parameter, offset or program changed, with the value before and after, and who made the change |
| Backups taken | Confirmation that a parameter backup was taken before and after the session, and where the copies are held |
| Conclusion | Either the correction applied, or the identification of the subsystem and the next measurement or part to be ordered |
What to have ready before a session is arranged
- The alarm text and number, the alarm history and what the machine was doing
- A current parameter backup, stored on the machine and off it
- Electrical drawings, ladder copy and the component list with control, drive and bearing identifications
- A confirmed network route or a local diagnostic laptop, tested on a healthy machine
- Somebody at the machine who can power it, operate the controls and look inside the cabinet
- The name of the technical contact on each side, and the agreed fault-reporting route
Frequently asked questions
Can a CNC machine really be diagnosed remotely?
Partly, and the boundary is worth being clear about. A control exposes a great deal of internal state — alarms, parameters, offsets, PLC logic states, drive diagnostics, axis load traces — and reading that state resolves a large class of faults, particularly configuration, sequence and programming problems. What it cannot do is feel a warm bearing, hear a noise, or measure a guideway. A good session ends either with a correction or with a specific identification of what to measure next, and the second outcome is a result rather than a failure.
What does the machine need for remote access to be possible?
A network route to the control, a control that supports remote viewing or diagnostics, and somebody at the machine. The control’s capability is documented by the control builder and ranges from full remote access on modern systems to a screen-sharing route through the machine’s own PC on older ones. The network route is the constraint that cannot be improvised: it belongs to the site’s network owner, it has to be permitted by whatever security policy applies, and it is worth testing once while the machine is working rather than discovering a problem during a breakdown.
Is remote access to a machine tool a security risk?
It is a governance question, and it is manageable with four rules: access is granted temporarily for a specific session rather than left permanently open; every change made is recorded with the value before and after; a parameter backup is taken at both ends of the work; and safety-related logic is out of scope entirely. A control that sits permanently reachable on a plant network with no monitoring is the case worth avoiding, and it is usually a configuration that was set up for convenience and never revisited.
What if the machine is not networked at all?
Then the same diagnosis is done by other means, and it is often enough. A machine with no network can be diagnosed from the alarm record, the parameter backup, the electrical drawings and photographs of the screens, exchanged by email or a messaging channel with a call alongside. A diagnostic laptop connected locally to the control and operated by the person at the machine gives most of the same visibility. The absence of a network slows the process; it does not prevent it, provided the documentation exists.
What makes the biggest difference to how quickly a fault is resolved?
The quality of the fault report. A report that carries the exact alarm text, the alarm history in order, what the machine was doing, what has been tried and the readings taken can be answered in one exchange, remotely or not. A report that says the machine has stopped and there is an alarm on the screen starts a conversation about collecting information. This is the practical argument for keeping the maintenance log and the alarm log in one file: the answer to the first question is usually already written down. The record structure is described in the maintenance checklist.
Next step
Prepare the channel before the fault, not during it. Send the machine model, the control and drive details and how the machine is connected to your network, and we will set out what remote diagnosis can do on that configuration, what has to be in place first, and the documentation set that makes a diagnosis possible even without a connection — together with the fault-report format that gets a useful answer in one exchange. The control arrangements across the range are on the machining centre pages.
Ask about cnc remote support for your machine
WhatsApp: +86 15502628547 · Email: info@dhlathe.com
Tell us whether the machine is on a plant network, an isolated network or none at all. That single answer decides which of the options applies to you.
