AccurateMovements

Hello joshuad, This is disappointing to hear the IDE installation is giving you so much trouble. Please indicate which software version you are speaking of. This may help us help you more. Thanks.

Thank you to daves! I was able to implement the two changes and now my download log is free from the Capt errors, just as he predicted. I had been troubled by the messages, but did not know how to proceed to a solution. Thank you again.

We are also seeing this error on: Windows 7 PowerPMAC firmware: 1.4.0.119 PowerPMAC IDE: 1.4.0.62 It seems to 'spread' to all of our motor feedback windows given enough time. Please help.

Super, I see it - Thanks.

Hello Sina, Thank you for the clear resolution including numbered steps and the motivation/reasons why this resolves the issue. Please kindly include the firmware/ver. numbers you are referring to. Since you posted today, I presume you are speaking about "all firmware before version 1.6" but in a few months we may not recall where this message fell in the release numbers/IDE version numbers timeline. Firmware which has this issue is: _________ ? IDE ver which (sometimes?) incorrectly changes files settings is ________? Thank You.

Thanks! (I thought it might be, but a few months from now I will likely forget.)

Hi Mark/Steve, Kindly include the version number of IDE to which you are referring. Thanks.

Greetings DeltaTau, My co-workers have quoted to me, more than once, that there is a known issue with the Encoder Loss bit on the ACC24E3 card for sinusoidal encoders (Gate3.Chan[j].SosError) and that I should discontinue use of it (!?). Of the multiple sinusoidal encoders on my machine, I have only experienced difficultly on one of them (as it relates to the EncLoss bit). Is there a white paper, release note, or known special circumstance that I should be aware of with ACC24E3s and the EncLoss bit? It seems more plausible to me that I have an issue with my scale...(?) Did I not 'get the memo'? Hoping to put this line of argument to rest. Thanks, AM Motor[1].EncType = 6; //Gate 3, sinusoidal enc. arctan extension Motor[1].pEncStatus = Gate3[0].Chan[0].Status.a; Motor[1].pEnc = EncTable[1].a; Motor[1].pEnc2 = EncTable[1].a; Motor[1].pEncLoss = Gate3[0].Chan[0].Status.a; Motor[1].EncLossBit = 31; Motor[1].EncLossLevel = 1; // Value of 1 is fault Motor[1].EncLossLimit = 10; // max accumulated # of faults

Hello, How do programatically determine if another PLC is enabled? If the syntax is not the same, kindly provide the verbiage for script PLC as well as for a C-program. I see that this was possible in Turbo (forum link), and have searched in vain today for the equivalent in Power PMAC. I expected it to be part of the Sys.xxx data structure, but have not found anything which tells the status of the PLCs. I can see the flags in the IDE, Task Manager... Thanks for your help.

Curt, Thank you, you have directly answered both of my questions. I see now that a motor is always assigned in a coordinate system (My Case3 posted previously is not a valid state.). I was looking for the line which said, "By default..." and the answer is that they are in coordinate system 0 and thus would share fault actions. (Just because they share timebase of cs0, that didn't explicitly tell me that they were in that system, but now I know for sure that they are.) Thank you for this answer as well, which was, "To which coordinate system are my motors currently assigned?" I was able to move my motors to unique coordinate systems, after which time, they were able to successfully home to their limit switches and would not affect unrelated motors. Thank You again for the answers, my project is off and running again! Thanks.

Hello Sina, Thank you for taking the time to review my question. I had read the manual you are quoting before posting and I read it again while trying to debug my system, the details in the manual are appreciated. The question remains - how do motors that are not assigned to a coordinate system behave? (Case 3 below) I believe there are three states for a motor: Assigned to a coordinate system with other motors Assigned to a coordinate system individually (only motor in sys.) -> Not assigned to any coordinate system. <- None of my motors are assigned to a coordinate system but still affect each other(!) Is this expected? Since I don't read anywhere that motors are automatically assigned to a coordinate system, limit switches from one affecting another, to me, seems to be unexpected behavior. Troubleshooting - Is there a way to ask a motor if it is part of a coordinate system, if one does not already know the relationships? May I ask a coordinate system which motors are assigned to it? Although it does not address the question and seems unnecessary, I realize that I should be able to get the desired behavior by placing each of my motors in their own coordinate system. Please help me clear the "fog" regarding motors and their limit switch interaction when they are not assigned to a coordinate system. Thank You. I hope this clarifies the matter. Regards,

Kill behavior observed: While Motor 1 was executing the "home1" cmd from a PLC script, an "unrelated" motor2 triggered its limit switch causing motor1 to kill! (amplifier killed, coast to stop) Abort behavior observed: If motor1 is simply jogging (#1j+) and motor2 triggers its limit switch motor1 aborts! (ramp to zero velocity, remain enabled) This sounds like expected behavior of two axes in a coordinate system, except these are two unrelated motors (so far as I know). Hmmmm, this is quite strange considering that there are no known relationships defined between these two motors. I do not have any coordinate systems defined. I carefully read the documentation on coordinate systems assuming that all motors may be placed into a default coordinate system (zero, perhaps), which might explain the relationship. I did not find this theory supported in the documents which I read. Motor[1].FaultMode = 0 Motor[2].FaultMode = 0 My goal is quicker machine initialization. I would like to home motor1 and motor2 at the same time. If motor2 homing to the limit switch kills the homing of motor1, then this plan of homing two at once will not work. (There is no mechanical interference between the two, so this is a "safe" situation.) How can I configure the two to "better ignore" each other during the homing process and have them home at the same time? Thank You.

Is it true that soft limits are "ignored" when a motor slaved to another motor? Slaving Motor 2 to follow Motor 1 allows us to command Motor 1 and have Motor 2 move beyond its software limits! :( Our findings today showed we had successfully configured motor 2 and homed it properly. We configured motor 2 soft limits by setting the values of Motor[2].MinPos and Motor[2].MaxPos. Moving around from the command line - the controller behaved as expected - stopping at the limits wherever we placed them. Next we configured Motor 2 to follow Motor 1 via the following parameters: Motor[2].pMasterEnc = EncTable[1].a Motor[2].MasterPosSf = 0.5 Motor[2].SlewMasterPosSf = 0 Motor[2].MasterMaxSpeed = 0 Motor[2].MasterMaxAccel = 0 Motor[2].MasterCtrl = 1 Commanding Motor 1 to move (multiple incremental moves) allows us to move Motor 2 beyond its software limits (and continue beyond)! I do note that the Status Flag is properly set in the Motor 2 status bits: SoftPlusLimit becomes true, but there is no action taken on the Motor 2 axis (such as abort move). I realize that there may not be an actual jog or move commanded during this special gearing/slaving activity, but I do need a way to tell motor 2 it is beyond its limit and that it should not proceed further. I may not have this properly configured (?). If so kindly point my oversight. If not, please provide the recommended method of keeping the software limits enforced even when a motor is slaved / geared to another. UPDATE: I am reading about Action on Closed-Loop Trip (which is my case, I think: certainly Motor2 is closed loop while following Motor1) and it depends on AbortTa and AbortTs, for my application those are: Motor[2].AbortTa = -2.0 Motor[2].AbortTs = 0.0 Also I have Motor[2].FaultMode = 0 Thanks. electronic cam electronic camming gearing slaving

Looks like I worked out a possible solution, although I would like to hear if there is a better solution. If PhaseCapt is < 0 then add 2* pow(2,32) which puts it back to a positive relative number and then the modulo operator discussed earlier, takes care of the CompA value being too big. if (Gate3[0].Chan[0].ServoCapt < 0) { tmp = (Gate3[0].Chan[0].ServoCapt + (2* pow(2,32)))* 16; } else { tmp = Gate3[0].Chan[0].ServoCapt * 16; // has 8-bits of subcounts extend to 12-bit subcounts }

Hello Bradp, Thank you for your code. I did make a modification to account for rollover of the CompA register, since, if a value which is too large for the CompA register is computed from PhaseCapt*16, the CompA register is filled with its max value of 2^32, instead of the actual value desired. (perform a % pow(2,32) before assigning to CompA or B). I am now unable to deal effectively with negative values of PhaseCapt. Gate3[0].Chan[0].PhaseCapt seems to have a range of +/- 2^32-1. This gives my calculations trouble, esp. when attempting to put a negative value into CompA. Manual states expected range to be positive values, but this is not what I am seeing on my demo box. What should I do to effectively deal with negative values of PhaseCapt?

Brad and Sina, Thank you gentlemen, after working out this offset, I have successfully configured my position-compare to start at the location I desired. Thank You, and yes, as andyf indicates in his last post, kindly update the Synchronizing Power PMAC to External Events document to reflect the correct fractional count information. Thank you.

I need some help computing the correct CompA register value on my Power PMAC and ACC-24E3 Card. Using my current calculation method, the PowerPMAC "misses" what I think the starting point should be and starts at another point. After it starts at the unexpected point, everything that follows is as I expect, meaning I get pulses at the desired regular intervals based on encoder position as configured (via CompAdd, etc.). From this I conclude that I am not specifying the starting point where I think I am, but that scaling is correct. Power PMAC CPU ACC24E3 Card Motor is 2000 cnts / rev Gate3[0].Chan[0].EncCtrl=7 Gate3[0].Chan[0].AtanEna = 0 If I power up the unit so that the PhaseCapt is at (or nearly 0), the following works nicely. This puts CompA one rev. into the positive future and CompB two revs. into the positive future and then sets the CompAdd for 2 revs. and suppresses the first autoincrement (new feature of PowerPMAC) I wish to have Equ change state once per revolution. Gate3[0].Chan[0].CompA = 2000 cnts * 4096 (register scaling) = 8,192,000 Gate3[0].Chan[0].CompB = 2 * 2000 cnts * 4096 (register scaling) = 16,834,000 Gate3[0].Chan[0].CompAdd = 2 * 2000 cnts * 4096 (register scaling) = 16,384,000 Gate3[0].Chan[0].EquWrite=1 // put Equ at zero and suppress first autoinc If I attempt to start somewhere after power-up and start from a present location, this code gives unexpected results: Gate3[0].Chan[0].CompA = Gate3[0].Chan[0].PhaseCapt + Gate3[0].Chan[0].CompAdd/2 Gate3[0].Chan[0].CompB = Gate3[0].Chan[0].PhaseCapt + Gate3[0].Chan[0].CompAdd Gate3[0].Chan[0].CompAdd = 2 * 2000 * 4096 (register scaling) Gate3[0].Chan[0].EquWrite=1 // put Equ at zero and suppress first autoinc Instead of changing the state of the Equ line on the next revolution, this above configuration started changing the output line, once per revolution after 374 revs. :( I stopped the motor, rotated the axis by about 90 degrees, re-executed the above 4 lines of code (the ones which include .PhaseCapt) and jogged the motor. This time the toggling of the output began after 430 revs. Please let me know how to make use of the current position when configuring my CompA & B registers. I expect that there is some other scaling going on that I am not aware of. I do note that .PhaseCapt appears to be +/- 2.147e9 while CompA appears to be 0 - 4.295e9, but they do not move 1:1 but differ by a factor of 16. 16*PhaseCapt = CompA at the point of "equality" and Equ line toggle. Thank you for your help.

Why is the the .PhaseCapt reporting negative values in the Watch Window or at the Terminal Window? The help documentation integrated with the IDE states that this is a 0 - 2^32 -1 range. (IDE version: 1.3.1.46) unsigned. I looked into changing the type of read / display which is done for the value, but my options were None, integer, float, ... there was not the signed / unsigned option. Thanks for your help on this item.

Please provide release notes for this new firmware and the associated IDE update as you did for version 1.3. (I was pleased to read the 1.3 Release Notes when that was released. We are anxiously looking forward to the release notes for version 1.4 to see what things will be affected and the new behavior programmed into the system.) Thank You.