JayL

not really sure if this is a csharp coding problem or not. If you can read M5000 with some value, there is no reason you are not seeing it in P2001. Make sure there is no other program or PLC writing to P2001 at the same time. and make sure the assignment from M5000 to P2001 is continuous, otherwise you are just assigning a value once in the beginning.

it is suggested to use KinPosAxis and KinPosMotor variables in kinematics. not sure why you are using them in inverse but not in forward. Ln and Rn are local variables, and you can't not monitor them. and your inverse and forward kinematics are not matching together: in inverse, it's a scara robot, and in forward, it's just a scaling. Please specify what you are trying to achieve so we can help you better

it is not clear how you map your PDO. Usually the error you are seeing in diagnostic should go away when you enable ethercat network. could you please show the mapping window of PDO to ECAT[0].IO[k].Data structures ?

there is no plan to add SLERP in the future. Actually I have asked about this before, and we do have a 6 DOF robot running using quaternion. At the time the decision was not adding SLERP because to come up with another special type of axes will consume too much development resource, including changing firmware, and in practical, our trajectory planning algorithm is good enough for the approximation of quaternion components. I used type (a) axis definition on a Denso Robot, and it works out fine. If the robot is not moving crazy fast, then it is not a problem in practical application. In fact, with the speed spec of Denso robot, there is no problem using quaternion in kinematics to achieve attitude performance at all the following is a link of the Denso robot demo

Please refer to Power PMAC Software Reference Manual, for online command, p Motor[x].ActPos is the position after power-on. p command will take out home position out of Motor[x].ActPos. So if you have any home offset, then they will be different. Here is a portion of the content for p command for motor //====================== If Motor[x].PosReportMode (new in V1.6 firmware, released 3rd quarter 2013) is set to its default value of 0, or in an older firmware version that does not have this new element, the values in these offset-mode registers are subtracted from the net desired position. Working from the source registers for Motor[x], the reported position is calculated as: + Pos // Raw feedback position relative to power-on/reset location + CompPos // Compensation table measurement correction + PresBlSize // Backlash correction - CompDesPos // Compensation table command offset - ActiveMasterPos * MasterCtrlOffsetBit // Master position when in offset mode - HomePos // Motor zero position relative to power-on/reset location If Motor[x].PosReportMode is set to 1, the values in these offset-mode registers are not subtracted from the net desired position. In this case, the reported position is calculated as: + Pos // Raw feedback position relative to power-on/reset location + CompPos // Compensation table measurement correction + PresBlSize // Backlash correction - HomePos // Motor zero position relative to power-on/reset location //=========

if you are referring to point-to-point interpolation of "quaternion" axes, then it might not be possible for PMAC to do it since the trajectory planning does not have this SLERP feature. Here are some suggestions for inverse kinematics: 1. before getting into the calculation, normalize quaternion axes to ensure unity constraint. 2. different axis definitions can be chosen for quaternion, such as: a. [n1*sin(theda/2), n2*sin(theda/2), n3*sin(theda/2), cos(theda/2)]=[A, B, C, D], or b. [n1, n2, n3, theda] = [A, B, C, D] where [n1, n2, n3] is a unit vector. this really depends on how you want to command. In practical, definition b will be better since theda=D is just an angle, and interpolation of this angle will not affect the unity of quaternion. if the interpolation segment is small enough, then the interpolation from, say [n1, n2, n3] to [n1', n2', n3'], will still be close to maintain unity of the rotation vector. No matter which definition chosen, the unity constraint of quaternion will be violated somehow. However, in practical, this violation can be overlooked with small segmentation.

To uploading the firmware through USB or SDcard, you would need to create a folder in USB flash or SDcard as below: Folder Name: PowerPmacFirmwareInstall Description: Power PMAC firmware will be updated. The installation package "powerpmac.deb" file should be placed in this folder. and you should only use file name as "powerpmac.deb" Please inform us which CPU/form factor you are using. Different CPU will need different firmware.

you can determine when you would the compensation to be applied by setting Sys.CompEnable = n, whcih will enable comptable 0 to (n-1) If Sys.CompEnable is not set, then motor position will only be raw encoder reading.

There are 2 possible solutions for this, but no one has tried them, so you might have to experiment on them and see the result. 1. You can use PLC0 or PLCC0 to calculate the vector components of this XY vector, and use the components as the cascaded outer loop feedback on the corresponding motors. Say, your tool tip is at a theda angle, and the XY components might be [cos(theda), sin(theda)], depending on how theda is defined. If the distance you want to maintain is L, then the movement on X and Y should be [L*cos(theda), L*sin(theda)] So your height sensor can give you a value related to this L distance, and the 2 components, X and Y distance, can be feedback to cascaded loop on 2 different motors. Of course, the tuning will be a big challenge to maintain not only the distance, but also the proper ratio between the 2 components. 2. Use kinematics without lookahead. You will need to calculate the move components according to the sensor reading, and then use that to update the "offset" you will have on each axis. Similar idea as option 1, but this one will take care of the component ratio correctly.

it would be better to use kinematics to do this since the relationship involves sin and cos non-linear functions. You won't be able to use position following in this case since the scale factors Ixx07, Ixx08 can only be integers. There is not enough resolution to follow the table correctly. It still only clear how the machine should work. Is the tool tip moving in XZ plan and trying to maintain constant gap between the tool tip and the table? What is the gap direction? Usually, if the gap is only in one direction, say Z axis, then cascade loop can be implemented to maintain specific gap distance.

It is ok to have multiple motors following the same master. However, the following is working on motor position, not axis position. If you have a robot with 3 axes, and you want to robot to follow the table, then you can't use position following. In this case, you need to use kinematics feeding table position to kinematics calculation to achieve that.

In Turbo PMAC Users Manual, page 329, we have some example G-codes. Basically G-codes are implemented by user, and user can choose whatever function they want in a specific G-code. Once you have you G-codes, you don't need to activate them. They are automatically recognized in a motion program, and you can use them directly.

there is a confusion for how you want to control this. If you are trying to close the loop using user servo algorithm, then you have to use jog command in order to close the loop. If you are trying to do open loop, then user servo is not used. Up till now, the user servo mentioned here is the servo code implemented on the controller side, which can be customized. But if your servo algorithm is not implemented on controller side, then for our controller, it is open loop since you are just changing the servoout. In that case, the set point velocity is not in control since the motor only reacts on a constant torque with open loop command. If there is no load or friction, the motor will accelerate. So in your servo algorithm, you need to look at the feedback and adjust your output accordingly.

Power PMAC use IDE instead of Executive for interface. PMAC Executive is for Turbo PMAC, and does not allow structures. Turbo PMAC use I-variables only, and if it's Turbo, then Ixx29 is the variable you need to adjust

Even though you are not using a motion program, Motor[x].jogspeed will still affect the speed when you do jogging. Motor[x].jogspeed will still be a better way to change the speed than changing pwmsf.

it is not desired to limit the speed by changing Motor[x].PwmSf. This should be set to enable 100% of the motor capability. Motor[x].JogSpeed should be the structure to change if you want to change speed according to some P-variable. After Motor[x].JogSpeed is changed, issue jog command again to make effect. Since standard PID servo loop from Power PMAC is not used, the tuning for user algorithm PID might be difficult. If the load is uneven, then the motor should exceed fatal following error and stop if the fatal following error is set properly according to the resolution of the encoder. All these should be handled in a PLC. Yes, there are several structures related to motor acceleration, jerk, and max speed: Motor[x].InvAmax Motor[x].InvDmax Motor[x].InvJmax Motor[x].MaxSpeed Please check the above structures in Power PMAC software reference manual for details.

The reason that you are not seeing the change for your test is that you are doing closed-loop jogging. 1. changing the maximum and rated RPM DOES NOT have any effect. That part of the setting is not used in the setup. The original plan is to put those as constraints for maxspeed, but not being implemented yet 2. changing max voltage will have effect on Motor[x].PwmSf, which will constrain the output voltage. However, if you are doing closed-loop with some jog speed, then the servo loop will try to keep up with the jog speed no matter what the maximum output is. The controller will try to keep the speed while maintaining the maximum output constraint. The fact that you have 1V as the max voltage and the motor still works means that Power Brick LV can still push enough current to achieve the jog speed. That is why you can not see the effect of changing the max voltage. If in the case that the maximum voltage is too low, and LV can not push enough current under the voltage constraint, then you will get a fatal following error, and probably amplifier fault. You will have a hard time to tune the motor since the voltage is too low to get the full power of the motor. You will be able to observe the effect of max voltage setting if you use open loop to run the motor. In open loop mode, such as #1o5 command, will give you 5% of the max voltage on motor 1. So if you change the max voltage and use the same command, you will see the speed change.

we would like to know more about the hardware you are using, such as what form factor of the controller, what type of driver you are using. Did you create your own servo algorithm? When you set up virtual motor, what do you mean by it got the same result? We need more details on the system.

in the PLC program, there is a subprogram called "Timer" I forget to put that in the document, and here it is: //***************** open subprog Timer (time) local EndTime; local count; EndTime = Sys.Time + time; do count++; while (EndTime > Sys.Time); close //**************** * usually it is placed in PMAC Script Language>>Libraries folder.

The attachment shows how to read absolute position off CN1 of a Yaskawa Sigma V drive with ACC-24E3 in a Power UMAC rack.Yaskawa Sigma I Protocol Implementation.pdf

Hi, We are a bit confused now. in one post you mentioned that when E3 jumper is installed, the problem went away. But in this post, you said even with the E3 jumper installed, the WD LED is still red. The other thing is, when you said "system is able to detect PMAC and asking for firmware", did you install E23 jumper? Because unless you use a firmware reload jumper, PEWIN should not ask you the firmware. Here is the logic for E3 initialization jumper: there is a memory location that has all default values of variable settings, and when E3 jumper is installed, PMAC will use this setting on power on. But, if you did not issue a "SAVE" command when you communicate to PMAC, then the factory default will not be saved in flash memory, which means when you remove E3 jumper, PMAC will use whatever is in the original flash memory instead of factory default setting. Like Richard mentioned, if with E3 jumper installed and you still have a WD LED red, then there is some hardware issue and it won't be fixed by re-installing the firmware. Of course, if you reinstall the correct version of firmware with E23 jumper on, then it might fix the problem since this will set everything back to factory default even with E3 jumper off. Please make sure you understand what the real problem is and use a proper approach to resolve it. Jay

have you tried to use E3 jumper to set everything back to factory default values for reset? If this resolves the watchdog problem, then it's something wrong with your original setting, and it has nothing to do with the firmware.

Hi Oliver, here are the 3 things you need to consider: 1. clock Please change your clock to 1Mhz or lower. I don't think 5Mhz will work on GeoBrick LV If you have a very short cable, then 4Mhz might work. 1Mhz clock: EnDatGlobalCtrl1_4=$2003 2. Actual position The actually position in your case, will be separated in two registers, since the data is more than 24 bits. The first 24 bits will be in Y:$78B20, and the rest 4 bits will be in the lower 4 bits in Y:$78B21 You need to define an M-variable, or suggested M-Variable, M162, as the actual position. And then construct the position: M162 = (Y:$78B20) + ((Y:$78B21)&(00000F))*$1000000 3. CRC error You should define M-variables pointing to Serial Data A register (Y:$78B20) and Data B register (Y:$78B21) to monitor the data comes in. If you find bit 22 in Data B is high, then you have a CRC error, meaning the resolution setting is wrong. This means your encoder might not be 28-bit, and you have to check it again. Once the resolution setting is correct, CRC error bit will be 0.

Hi, Matthew Can you also give us the serial number of that GPL102 amplifier so we can cross reference if there is anything wrong with the C160 component?

In Example 1, the NORMAL command is used. However, because of wrong break in the command line, the command got into the comment. This is a typo. If you look at that example again, you will see what I mean. The command line should be: NORMAL k-1 j (-TAN(60))