You take on a machine project that has no ladder diagram, or you have to rebuild a whole sequence control on an existing machine. Most people’s first reaction is to open the software and start writing. That is the easiest way to get into trouble.
Writing the ladder is not what actually takes the time — getting the sequence straight is. This article breaks a complete FANUC PMC project into six stages, and every operation in FANUC Ladder III has a place where it belongs. What is the situation on site, does the existing program need backing up, how are addresses planned, how do you confirm it is really running after you finish writing, and what do you leave behind at handover.
This article is about methodology: it does not teach how to write a particular rung, but what order a complete project should follow. The real barrier in FANUC PMC programming is the process, not the syntax.
First, What This Process Solves
When a PMC project delivery fails, it is usually not because the ladder is written wrong — it is because one of the steps below was skipped. None of them require a high level of skill, but missing any one of them means rework. And on a production floor, rework is billed by the hour.
Stage 0: Site Survey — Do Not Connect the PC Yet, Ask First
This step is skipped most often on site, because you have already arrived and want to get working.
Four things to establish clearly: what the machine actually is and what it must do, whether the original program needs to be kept, what the I/O and safety conditions are, and who signs off on changes.
Action for the engineer: photograph everything in the electrical cabinet — the wiring, the address labels, and the PMC module model numbers. The value of those photos shows up later in the project: once the ladder reaches its third revision, you will need to keep cross-checking against the original wiring.
Stage 1: Full Backup — The Only Thing That Lets You Undo
Back up completely before changing anything.
Back up five categories, not just the ladder: the ladder program, PMC parameters, the option table, alarm messages and titles, and the symbol/comment table — all from the same machine.
Two disciplines: put the machine number and the date in the file name, and store the files somewhere other than the machine.
Stage 2: Address Planning — The Most Underestimated Step
This is the step most easily underestimated, and the one that most easily causes rework.
How to do it: take a sheet of paper or a spreadsheet and write out the purpose of every I/O point and every internal address, marking the signal direction and the interlock relationships.
Why it must come first: without a plan, addresses get assigned as you go, and by the third revision nobody can say what a given address is for. A ladder that nobody can read is a ladder nobody dares to change.
One important discipline: addresses follow field measurement, not the program. Before planning, use the machine’s own diagnosis screen to confirm how a few key addresses actually behave. Do not copy the address table from a similar machine.
Stage 3: Write the Logic — Safety Circuits First, Function Logic After
The order of writing matters.
- Write the safety-related circuits first. Emergency stop handling, safety door detection, brake release timing, spindle stop confirmation — these must be completed and verified on their own before you touch function logic.
- Why they must not be mixed: function logic keeps iterating and will eventually need changes somewhere. If safety and function share the same network, a change to function logic will sooner or later touch the safety part. The cost of separating them is only a few extra network titles; the cost of mixing them is a machine that can hurt someone.
- Then write the action flow. Tool change, tool change timeout, counting and display, exception branch handling; spindle start/stop, magazine rotation, manipulator actions — write them in sequence.
- Add a comment for every section you write. State the design intent, especially the places where the question is “why not write it the other way.” Those comments are worth the most during later maintenance, because the next person’s first reaction will always be “why is this so convoluted.”
Stage 4: Online Download — Download Success Does Not Mean Behaviour Changed
Once the ladder is written, it has to be written back to the machine.
Preparations before writing back: confirm the program protection state and confirm the sequence program is stopped. If protection is not released, the write will be rejected.
Do one thing immediately after downloading: open the machine’s own ladder monitor screen and see which line the execution cursor is stopped at.
This step cannot be skipped. A successful download only means the data was written in — it does not mean it is executing. Two common situations leave people completely baffled: the program is loaded but the PMC is in the stopped state, or the loaded program never becomes the active one.
Build the habit: use Ladder III to change, and use the machine’s own screens to check.
Stage 5: Staged Verification — Release Level by Level, Do Not Skip
The verification order is fixed at four levels; confirm each level before moving to the next.
Why you must not skip levels: a good share of timing problems only surface in semi-automatic or automatic mode. A single action working correctly does not mean the automatic cycle works, because during continuous running the timers, edge signals and interlock states all differ from single-step execution.
Logic involving retentive addresses must be retested after a power cycle. Retentive addresses carry their pre-power-off state across the startup instant, so passing in a warm state does not mean passing after a restart — this is the usual cause of the “it was fine yesterday, but it fails as soon as we power on today” class of fault.
How to handle a problem you find: go back to the ladder, change it, download again, and re-verify from level one. Do not patch it at the later levels.
Handover: Leave Five Things Behind
When the project is done, what you hand over should not be just a ladder that runs.
- A complete machine-specific backup file — the delivery version, not an intermediate version from mid-development. The file name states the machine number, a description of the contents, the date, and the version number.
- An address cross-reference table — the purpose, direction and interlock relationships of every I/O point and internal address. This document matters more than the ladder itself: the ladder can be modified by anyone, but the cross-reference table is what lets someone else understand what it is doing.
- The commented ladder source file — with the design intent written for each section. A ladder that only its author can read is no delivery at all.
- An alarm cross-reference — custom alarm number, alarm text and trigger condition, one-to-one. An alarm the operator cannot understand is no alarm at all.
- Commissioning records and parameter backup — which level was verified, what was changed, the original PMC parameter values, and diagnosis screen screenshots where needed. The original parameter values must be kept: they are the only baseline if someone later needs to restore or compare.
The Four Actions Most Easily Skipped in the Whole Process
If time is tight and you can only keep part of it, keep these four:
- Backup — skip it and you cannot roll back when something goes wrong later.
- Address planning table — skip it and the rework rate multiplies.
- Checking the execution cursor after download — skip it and you will spend much longer suspecting the ladder is written wrong.
- Staged verification without skipping levels — skip it and you carry the problem into production.
Learning Path
Building capability in this order is far more solid than studying a list of instructions:
- Video course: zero-basic FANUC PMC video tutorial.
- Systematic material: FANUC PMC maintenance learning material.
- Supporting reading: what a PMC is and the scan cycle (timing basics); reading, searching and clearing FANUC PMC alarm codes (what to do once an alarm appears); FANUC PMC communication with third-party PLCs (interfacing external devices).
Closing
The technically difficult parts of delivering a FANUC PMC project on your own are actually limited. What really determines delivery quality is the order: survey before design, back up before acting, plan addresses before writing code, write safety before function, verify before handover.
The value of this order is that it removes most risks before they happen. On a project done to the process, when a problem appears you know exactly which step it is in. On a project done by jumping around, when a problem appears you have to suspect every link from the beginning.
Worth treating these six stages as a checklist — run through it every time you take a new project, and over a year you will find your rework rate falling.
Safety note: This article describes a complete machine control program development and change process. The whole process must be carried out with the machine stopped, especially the online download in stage 4 and the verification in stage 5. Any change to safety-related circuits (emergency stop, safety door, brake timing) must be verified separately, and safety verification must never be skipped just because “the function works.” It must not be handed over for production use until verification passes. Where a project involves modification of safety functions such as emergency stop or safety doors, it must be performed by suitably qualified personnel under local safety regulations.
Disclaimer: This article is compiled from the general flow of FANUC PMC project development and field experience. Specific parameter items, address ranges, available instructions and function options vary greatly by CNC model and PMC model, so this article deliberately lists no specific parameter or address numbers. Follow the official manual for your machine and verify by measurement on site. The stage division and checklist here are engineering-method reference only; mechanical and electrical schemes must be drawn up by qualified personnel based on the actual machine.
Frequently Asked Questions (FAQ)
1. Why must safety circuits be written and verified separately from function logic?
Because function logic keeps iterating and will eventually need changes somewhere. If safety and function share the same network, a change to function logic will sooner or later touch the safety part. The cost of separating them is only a few extra network titles; the cost of mixing them is a machine that can hurt someone. Write emergency stop handling, safety door detection, brake release timing and spindle stop confirmation first, complete and verify them on their own, and only then move to function logic.
2. The download succeeded but the machine’s behaviour did not change. Why?
A successful download only means the data was written in — it does not mean it is executing. Do one thing immediately: open the machine’s own ladder monitor screen and see which line the execution cursor is stopped at. Two common causes are that the PMC is in the stopped state after loading, or that the loaded program never became the active one. Also check the preparations before writing: if program protection has not been released the write is rejected, and the sequence program must be stopped. Build the habit of using Ladder III to change and the machine’s own screens to check.
3. What should be handed over at the end of a FANUC PMC project?
Five things, not just a ladder that runs: a complete machine-specific backup file (the delivery version, with machine number, contents, date and version in the file name); an address cross-reference table giving the purpose, direction and interlock relationships of every I/O point and internal address; the commented ladder source file with design intent per section; an alarm cross-reference mapping custom alarm number, alarm text and trigger condition one-to-one; and commissioning records plus parameter backup including the original PMC parameter values, which are the only baseline for later restore or comparison.
4. Why must logic using retentive addresses be retested after a power cycle?
Because retentive addresses carry their pre-power-off state across the startup instant, so passing in a warm state does not mean passing after a restart. This is the usual cause of the “it was fine yesterday, but it fails as soon as we power on today” class of fault. Where the logic involves retentive addresses, power the machine off and on again and verify once more as the final step of staged verification.
暂无评论内容