MAM Against MAJ on a Logix Axis: A Move That Ends and a Move That Does Not

An absolute MAM to 400.000 mm at 250 mm/s, with 1000 mm/s² either side of the cruise, sets its .PC bit 1.83 seconds after the rung goes true. An MAJ at 120 mm/s on the same axis sets no .PC bit at all, ever, because the MOTION_INSTRUCTION structure for a jog does not contain one.

That is the whole choice, and it is a choice about the sequence rather than about the motion. Use the MAM instruction when the next step of the machine needs to know the axis got somewhere; use MAJ when something else — a photoeye, an operator’s finger on a button, a jam detector — decides when to stop, and be ready to issue the MAS that stops it. Everything below is what the two instructions do with the operands they share.

And what happens when one of them is triggered again while the first is still running.

The .DN bit is set almost immediately and stays set. It is the .IP bit falling and the .PC bit rising, 1.83 s in, that say the load is where you asked for it.

What the four bits actually say

The reference manual’s wording for MAM’s .DN bit is “the move was successfully initiated”, and that word initiated does all the work. It means the planner accepted the instruction. It says nothing whatsoever about the load, which at that moment has not moved. .IP is set while the axis is travelling to the end Position, and the manual lists exactly six things that clear it: the axis reaching the end Position, another MAM superseding this one, an MAS, a merge from another instruction, a shutdown command, and a fault action. .PC is the bit that means arrival, and it has a property worth knowing — it stays set until the rung makes another false-to-true transition, and it stays cleared if anything stopped the move before the axis reached the end Position. So .IP clear with .PC clear is not an odd state. It is the signature of a move that was cancelled, and a sequence that only watches .PC will sit there forever without ever telling you why.

Watch .IP falling and .PC rising together. One without the other is information.

A jog has no end, and that is the point

MAJ moves the axis at a constant speed without regard to position — the manual’s phrase, and it is literal. There is no Position operand on the faceplate to fill in. The speed, the accel and decel rates, the profile and the jerk operands are all there and they all behave as they do on a MAM, but the instruction has no idea where the axis is going and no opinion about when it should stop. Its .IP bit clears on another MAJ, an MAS, a merge, a shutdown or a fault action, and on nothing else. The practical consequence is that every MAJ in a program needs a matching stop, and that stop has to survive the cases where the operator lets go of the button during a fault, or the sequence steps past its own jog rung. An MAJ left running because the stop rung was conditioned on a step number that the sequencer skipped is not a subtle failure. It is a motor turning until somebody hits the E-stop.

Every MAJ needs its MAS, on a rung that cannot be skipped by the sequencer.

The jog travelled 169.7 mm. Nobody asked for 169.7 mm – that is just what 120 mm/s for 1.55 seconds comes to, including the ramp at each end.

There is a second trap in MAJ that the manual flags in its own words: starting a new jog while one is already in process can make an accelerating axis overshoot its speed, and can make a decelerating axis reverse. That warning is attached to S-curve profiles, and the note about reversal carries a revision qualifier — revision 15 and earlier — which is the sort of detail worth reading twice before assuming a modern controller is immune. The new MAJ cancels the old one and the axis takes the speed, acceleration, deceleration and jerk of the new instruction. If your operator screen has a fast jog button and a slow jog button, and both write to the same axis, that is two MAJ instructions.

The second one wins, and it brings its own accel, decel and jerk with it.

The two shaded rows are the ones that decide which instruction the job needs. Everything else in the table follows from them.

Changing your mind while the axis is moving

This is where MAM earns its keep, and it is documented behaviour rather than a trick. Fire a second MAM at an axis that is already moving under the first one and the change takes effect immediately: the manual gives a table for it, and both rows of that table matter. To change the endpoint of an absolute move, either issue an absolute MAM with the new position, or an incremental MAM whose Position is the amount by which the endpoint should shift — the new end position is the old end position plus that distance. To change an incremental move, an absolute MAM sends the axis straight to the new position without finishing the original increment, while a second incremental MAM adds the two distances together. And in every one of those cases the manual adds the sentence people skip: the axis moves to the new position without stopping at the old one, including any required change of direction.

That change of direction is not theoretical, and it is not gentle.

At the moment the second MAM lands the axis is at 218.7 mm doing 250 mm/s. Stopping inside 200 mm is not physically available, so it overruns by 49.9 mm and comes back.

Whether that overrun is acceptable is a question about the machine, not about the instruction. On an infeed screw with 300 mm of clearance it is nothing.

On a gantry parked 50 mm from a fixture it is a repair bill and a night shift. The first MAM’s .IP bit clears and the second one’s sets, no error is logged, and the only evidence in the tags is a position that went past the number you would have predicted. If the sequence genuinely must not overshoot, the answer is not a second MAM. It is an MAS, a wait for the axis to rest, and then a fresh move.

Three steps instead of one, and a deliberate full stop in the middle of the cycle.

Merge, and the operand you fill in and then ignore

Merge is a two-way choice with a three-way consequence. With Merge disabled, the new move is added to whatever motion is already in process, and the Merge Speed operand is ignored — though the manual is clear that you must fill it in anyway. With Merge enabled and Merge Speed set to Programmed, the new instruction ends the motion from other instructions and runs at the speed you typed into this one. With Merge enabled and Merge Speed set to Current, it ends the other motion and carries on at whatever speed the axis is already doing, ignoring the Speed operand entirely. That last combination is the one to reach for when a jog has to become a positioned move without a bump in the profile: the axis does not change speed at the handover, it simply acquires a destination. Set the same combination by accident and a move meant for a programmed feed rate runs at the jog speed.

Fill Merge Speed in every time. Half the trouble it causes comes from it being left at a default nobody read.

The dead end: a timer standing in for .PC

The rung looks reasonable. MAM fires, a TON runs for two seconds, the next step waits on TON.DN, and the machine works all week. What it is really doing is asserting that the move always takes the same time, which is true until the day a lighter product changes the load, or somebody lowers the Speed operand for a fragile carton, or an MCD trims the feed rate mid-cycle. Then the timer expires with the axis still moving and the next actuator fires into a load that has not arrived. There is a related habit that fails the same way — a jam timer sized from zone length and belt speed is a fair way to detect a fault, and a poor way to detect success. The axis already publishes the answer in .PC and in AxisStatus, at the coarse update rate, for free.

A timer measures your estimate of the move. The bit measures the move.

Rotary axes get a third move type

On an axis whose Positioning Mode is Rotary, Move Type offers Rotary Shortest Path alongside Absolute and Incremental, and it does what the name says: the axis goes to the specified Position in the shortest direction regardless of where it started, through zero if that is the short way round. A plain Absolute move on the same axis does not do that. Its direction depends on the current position — a start below the target moves positive, a start above it moves negative — so an absolute move from 350° to 10° travels 340° the long way while a Rotary Shortest Path move travels 20°. Try Rotary Shortest Path on an axis that is not configured as Rotary and the instruction errs with .ERR 17, Axis Mode Not Rotary. Parameter problems come back as .ERR 13 with the operand number in .EXERR, counting from zero at the first operand, which is how a jog with a speed above the axis maximum announces itself.

Error 13 with an extended code of 3 on an MAJ means the Speed operand, nothing else.

Next thing to do: take one MAM you already trust, put .IP, .PC and the axis command position on a trend, and fire a second MAM at it halfway through. Measure the overrun on your own machine at your own rates rather than trusting the 49.9 mm above. Before any of that works the axis has to be enabled, which is MSO, MSF and MASD, and if the axis does not exist yet, the walkthrough from motion group to first move builds it. Where two axes have to run at a matched rate rather than to matched positions, speed matching across a transfer is the conveyor version of the same argument.