Okuma handles part counting differently than a Haas or FANUC, and for once the difference works in your favor. Instead of a fixed counter that always adds one at program end, you use a common variable you increment yourself in the program, then tell the MTConnect app to report it. Because you own the increment, counting multiple parts per cycle is just a bigger number, no plus-one math, no compensation. This guide sets it up and gets the count into Spall.
Before you start This assumes the Okuma MTConnect Agent & Adapter app is already installed and running, from the Okuma MTConnect setup guide. You’ll be editing a program on the control and changing one setting in the MTConnect app. Nothing here touches the machine’s motion, just a counter.
Why a common variable
The OSP does have a built-in parts counter on the operation screen, and it bumps on program end (M02). But that counter is awkward to expose cleanly over MTConnect, and it always counts by one, which is wrong the moment a cycle makes more than one part. The fix Okuma and the monitoring world settle on is a common variable, typically VC1. You control exactly when and how much it increments, and the MTConnect app maps it straight to the part count Spall reads.
| Piece | Role |
|---|---|
VC1 | A common variable on the OSP. Holds your part count. You increment it in the program. |
| MTConnect app, Device Configuration | Where you tell the app which common variable is the part count, so it reports it. |
1. Tell the MTConnect app which variable to report
Open the Okuma MTConnect app’s Device Configuration and set the part count variable to the common variable you’ll use, for example VC1. This is what links the number you increment on the machine to the PartCount that shows up in the MTConnect stream.
2. Increment the variable in your program
Near the end of the program, just before M02, add one line that bumps the variable. For one part per cycle:
( ... end of program ... )
VC1=VC1+1
M02That’s the whole mechanism. Every time the program ends, VC1 goes up by one, and the app reports it.
Multiple parts per cycle
This is where Okuma is easy. Making four parts a cycle? Increment by four. Because nothing else touches VC1, the number you add is the number of parts, no minus-one, no adjusting for an automatic bump:
VC1=VC1+4 ( four parts this cycle )
M02If the count varies cycle to cycle, drive it from another common variable that holds this cycle’s good parts, say VC2:
VC1=VC1+VC2 ( add whatever ran this cycle )
M023. Reset the variable when a job starts
VC1 keeps climbing until you clear it. Zero it at the start of a job or shift, either with a line at the top of the first program (VC1=0) or from the common variable screen on the OSP. Decide whether you want VC1 as a per-job counter you reset, and use a second variable for a running total if you want both.
Always test one cycle After you set the variable and add the line, run a single cycle in a safe condition and watch VC1 on the common variable screen. It should jump by your full part count, four, not one. Then confirm the same number shows in Spall. Proving it once beats trusting a count that’s wrong and nobody’s checked.
How the count reaches Spall
The MTConnect app maps VC1 to the PartCount item in the stream, and Spall reads that over the same connection from the Okuma setup guide. Set VC1 correctly on the machine and the right number flows straight through, nothing else to configure. One thing to remember: whatever variable you pick, make sure your Spall setup is pointed at the same one, so the mapping matches end to end.
What Spall does with the count
Production. Spall turns VC1 into pieces-per-shift and pieces-per-job against target, updating as the machine works. With the increment set right, the numbers match what shipped.
Quality. Pair the total count with scrap and reject tagging, and Spall separates good parts from total. That split feeds the Quality side of OEE.
Performance. An accurate count plus runtime gives a true per-part cycle time. When it creeps, Spall flags it before it eats a shift of capacity.
OEE and dollars. Availability, performance, and quality combine into OEE, each loss ranked in dollars so the biggest recovery is obvious.
Quick recap
- Use a common variable (VC1)
- Map it in the MTConnect app Device Config
VC1=VC1+Nbefore M02- N equals parts per cycle, no plus-one
- Reset VC1 per job or shift
- Test one cycle, confirm in Spall
Get the count right on the control and everything above it gets accurate. That’s the whole point, a number the floor believes.