MAG and MAS instruction

[slcman 9]

I need to troubleshoot a project with motion instruction. I need some information on MAG and MAS instruction. : 1- Once MAG instruction set, does axes stay geared until a MAS instruction is called (Stop type: gear or all)? I don't understand why programmer called this instruction each 50msec. 2- If MAG instruction is ON, and stay ON while MAS is true. Does axes return to "gear-in" state once MAS instruction goes to fales or MAG need to see a new false to true transition? Actually system operate properly if speed doesn't change but when we change speed of master axis (encoder tie to driveshatf) Slave "slip about an inch. thanks for help

[dmargineau 6]

The MAG instruction is being executed as long as the "rung conditions in" are True; it provides the "Slave" axis with a reference based on another axis position (Master) multiplied by the "gearing" ratio. Obviously, if a MAS instruction is "deployed" (and active) onto the same axis, the physical motion will cease even if the MAG is still "active". As soon as the MAS is not "active" anymore, the (presumably active MAG) will take over and the "geared" movement command will commence. Back to your issue, does the the MAG instruction have the "Clutch" option checked? Once in "MAG Active" state, the maximum velocity, acceleration, or deceleration limits established during axis configuration do not apply anymore!. If the difference between the Master velocity profile and the Slave pre-MAG one is significant, physical slippage might occur within the Slave's linkage at the moment of MAG's commencing. If the "Clutch" option is checked, you might need to "speed up" the Slave axis prior to generating the MAG command.

[slcman 9]

First, thanks for reply. You explication really help me. Back to your issue, does the the MAG instruction have the "Clutch" option checked? NO - DISABLED, I don't really understand what's this parameter does. If the difference between the Master velocity profile and the Slave pre-MAG one is significant, physical slippage might occur within the Slave's linkage at the moment of MAG's commencing. Like I said in point #1, if MAG instruction is ON 50msec and OFF 50msec continuously, is this could explain the variation while accel or decel? I guess while MAG instruction is OFF and there is not MAS command, motor run at the speed it run while MAG instruction goes OFF. In drawing I sent, I tried to represent what is caused my issue, but I'm not 100% sure, could you give me your opinion? (RED = Master speed, BLUE= slave speed) BLACK= 50msec ON, 50msec OFF) - I know Master and slave are equal while MAG is on but I lower blue line a little bit for reading. thanks

[michael G 2]

Ouch 1) MAG is a TRANSITIONAL instruction - Only executes once each time it is called 2) MAS is a TRANSITIONAL instruction 3) Get a Copy of Motion Reference Manual Once a MAG has been executed it will continue to be active until - MAS is called with ALL or Gear - A Merge Operation occurs - Look at MAM and MAJ commands - Slave Drive Faults IF the MAG is called again The ratio can be changed "on the fly" Eg Gearing Ratio of 1:1 then Gearing Ratio of 5:1 It is strongly recommended that if you are doing this that the "Clutch" feature is used - A motor cannot change speed in an instant, so it is better to have control of it. Once a MAS ALL Instruction has been called The Stop Must Complete before any Move command will work Pre V17.02 Behavior is different Look at V17 Release Notes Your Picture shows some funny stuff happening - it appears that Please use the RS5000 Trend - trend Master Speed and Slave Speed The trend function is your best buddy for debugging motion Can you attach your code? or even a snippet? What version of Logix 5000 are you using? If you have access to a spare processor you can set up two Virtual Axis and play and learn about MAG you can also do this in the emulator

[Gerry 13]

slcman: Definitely listen to michael G and ignore dmargineau. Michael is probably wondering (as I am) why the slave axis doesn't come to a dead stop when the MAS is triggered. Is there some other instruction taking over when gearing is off?

[slcman 9]

Micheal you have a great idea, I'll use graphic to see what's append there. Gerry program only use MAS stop type = 3 (gear) Could you tell me if the motor will run at previous speed if MAS instruction is executed with stop type = 3 (gear) ie. 1- Motor gear-in Master run at 1800 RPM (ration 1:1) 2- MAS stop type 3 3- what's speed the axe will run? 1800RPM? regards

[Gerry 13]

Always bear in mind that the axes are position loops. The gearing operation links the command position of the slave to the command or actual position of the master. The link is "relative" - i.e. the change to the slave command position is equal to the change in the master position multiplied by the gear ratio. The change is computed at the motion update rate. When gearing is stopped, the slave command position is no longer updated. Barring any other operation initiated on the axis, it would be expected to stop at the last command position. I suppose the MAS instruction might specify a near-zero decel rate which would keep the axis moving, but what the motivation for this type of programming might have been is a mystery. Gerry

[michael G 2]

Motor will run as required by whatever else is going on eg - a Move (MAM), a Jog (MAJ), a Time profile (MATC), a Position Profile (MAPC) Select the Axis and perform a cross reference - you are looking for any of the above instructions

[dmargineau 6]

You ever heard of Inertia "down under and farther East"? Or maybe Newton never experimented bellow the Equator... Even the initial inquiry lacks any code/soft trends posts and there isn't any functional description of the system , it's obvious that the OP application's two axii are physically connected, at least at the time of the MAG intended execution. The reason the "Slave" doesn't stop upon MASed is because the "Master" is running at 1800 RPM; motion synchronizing 1:1 a 0 RPM motor to a nominal RPM functional one is a pretty delicate endeavor. The original developer's "connecting" choice though, I admit, is quite "original "indeed... Without additional information about the matter it will be very difficult to mitigate the "slave slip"; "Positioning" might be the fundamental attribute of Motion, however, as its name states, a Motion application is a dynamic process first and then a positional one. Edited 8 Apr 2013 by dmargineau

[Gerry 13]

Ouch again! You continue to display your lack of understanding. Since we haven't been told otherwise, we have to assume that the servo loop for the slave is active throughout -- for the uninitiated, that means maintaining actual position equal to command position. It will not coast. I would say it's obvious that the two axes (note sp.) are not physically connected -- else why have separate drives and a gearing operation?

[dmargineau 6]

Your presumptions definitely denote not only a "low substance know-it-all" approach but also a total lack of any professionalism... In my engineering world, no scenario is excluded unless specifically stated within the given data...moreover, any civilized individual should politely disagree when confronting an opinion different than his own...but then again, this is just my way of approaching contradictions.... Separate axii (not drives!- the Master could very well be a Virtual axis- I have yet to find any "drive" reference within the OP's posts!) and MAG commanded motion are fundamental components of modern production lines where the processed product could represent the "physical drive linkage"...Ever heard of a Flying Cut-Off application?...ya know, stationary wait for the cut position, take-of and reach the line speed, grab the product while MAGed with the product "drive" and then cut it... That's what I was thinking about when presenting my opinion...the two axii most likely have substantial inertia momentum differences ("slip generator") and that's where "Clutching" the MAG usually helps by "forcing" trapezoidal dynamics at the time of the "electronic gearing" commencement since the Slave tunning does not apply anymore within a MAG state... However, I believe this "opinion exchange" does not serve any purpose unless the OP could provide more information: I could be wrong as well as you could be wrong....It would not be the first time, now wouldn't it? Kinda rest my case here unless new "evidence" will be provided...

[Gerry 13]

Hopefully, this exchange will serve the purpose of helping the OP to understand the operation of the program he is working on by supplying him with correct factual information instead of BS opinions and, secondly, to introduce you to reality.

[dmargineau 6]

Gerry, Back to (seemingly ignored) good ol' Isaac Newton's work...Every Action will invariably be responded to with a counter-action, or Reaction...If the Reaction is not desirable (or hurting when taken up the chin ) the Action is to be avoided in the first place...They teach that, however, one would acquire that knowledge within the first seven years of his/her life...Bullies do not and they are always surprised when they are put back to their places... I am very well aware of how the Motion Move instructions work...Are you ??!!...Open up your copy of RSL5K/ Instructions Help/Motion Move Instructions and then read my first post again...If you call that BS you might want to take it up with RA. Once called up (Rung-Conditions-In TRUE for at least one scan), a MAG will execute as long as it is not superseeded by another Motion Gear Axis command or it is terminated by a Stop, Merge, Shutdown command or a hardware declared fault. The OP states that his application's MAG is called up every 50 ms (Rung-Conditions-In are "toggled" every 50 ms) obviously because the respective axis "electronic gearing" is being terminated by the mentioned MAS instruction. Like I have previously stated, this is quite an "original" implementation, however, the first post states that it's doing the job unless the dynamics of the Master Axis are being altered ("changes speeds"); the Slave axis will not stop because it's being MAGed again before the motor/driven assembly has time to come to a complete, physical stop. Why are you guys wondering WHY the axis does not stop when MASed?...Obviously, because it is MAGed every 50 ms!!!... DUH! There are dynamics issues which might've not been initially considered or developed over time... You got a crystal ball for observing "reality"? ...You might want to consider another brand...The one you are using, obviously, has its optics distorted... Edited 10 Apr 2013 by dmargineau

[Gerry 13]

Oh my, but we are getting sensitive... It is not clear from your initial post, or your latest, that you appreciate the term "transitional". That is what prompted Michael's initial response (he got in before me). Perhaps in #5 I should have asked, "why doesn't the slave axis attempt to come to a dead stop". The diagram indicates no decel. Can you explain that? The slave appears to be 'lively' (steep rise to match master velocity), so one would expect to see a drop in slave velocity when gearing is stopped. Attacking me with ad hominems and sarcasm doesn't prove that you know anything. If you're feeling bullied - go whine to your mommy.

[BobLfoot 301]

FLAG ON THE PLAY!! UNTIL SLCMAN POSTS HIS NEXT QUESTION OR NEED FOR CLARIFICATION LETS END THE SIDE TOPIC DISCUSSION OF NEWTON AND ALL THINGS PERSONAL. PLEASE.

[slcman 9]

I agree. Michael give me the idea of using trending function to get some trace. This is what I would like to do on my next visit on site. I will follow up with trace,thanks

[dmargineau 6]

...and of course the above statements do nothing but "add" to your "professionalism", however, the lack of sarcastic content within your replies lets us know that my own use of it perfectly served the intended purpose... Back to the issue at hand though, your acceptance of Michael's given definition of TRANSITIONAL instructions is a far cry from an educated and coherent explanation required by the OP inquiry; "Only executes once each time it is called"???!!! Are you kidding me??...That's how you explain the Motion Move instructions' functionality to someone obviously not too familiar with Motion automation?! How about: The Motion Move instructions immediately change the motion state/functionality of the respective axii until another command superseeds the previously given one? Obviously that's why I avoided your (accepted) choice of MAG/MAS descriptional attribute and chose "Active" since we are talking about a time slice functional state...But then again, I don't know anything, don't I... I don't know why the slave axis does not attempt to come to a dead stop upon being MASed (I do not own a crystal ball and we still need a functional description of the system), however, from the available OP information, I believe there is a physical "connection" between the axii driven sub-systems and inertia is not being accounted for when "electronic gearing/timing" is implemented within a variable master reference; that's why I have inquired about the MAG "Clutch" feature which, currently, is not being implemented. It might be a "Flying Cut-Off" or a "Dancer Roll" application and again, the original developer chose a very "original" way to implemented it; I have yet to "see" a motion instruction being called every 50ms, however, it is OP stated as "it works" (unless dynamics change). SLCMAN promissed trends...Let's wait for it... Bob, you could remove the "flag", I will personally try to keep the sarcasm to a minimum since "cultures clashes" are to be avoided at all costs...see humanity's history results generated by said clashes avoidance lack thereof...

[Sleepy Wombat 27]

Bob should not remove the "Flag" and this post will continue to be monitored closely. Bob's request was quite reasonable that both dmargineau and Gerry "can" the personal banter and attacks. You both have different approaches to solving the problem at hand. From what I have understood, both of you have a good knowledge base. We thank you for your numerous reponses on the fourm however If you both cannot play nice then the mod team will consider other action. This forum is not a tool to be used as a "pissing contest". Please keep responses on topic and not personal.