hannsx

Hi, I am working with a PowerBrickLV-System and need to do some Drawings with drill holes matching them on the PowerBrickLV case. Is there a technical drawing that includes them?

The Version I downloaded from the link posted above works for me. I hope though to be able to solve the problem with the new IDE.

You can download it from here: http://www.deltatau.com/Common/support/downloads/PowerPMAC_IDE32_64_Bit_V3.1.2.2_Full%20Release.zip Thx!

Is it possible to download version 3 of the IDE somewhere? I would like to see if that works on my system.

Hi, same problem here... I tried setting up my system again because we suspected broken registries. Directly after having installed the IDE upon having reset my windows it worked properly. But the next day I have the same problem again. The error-message reads: "Project "...." is newer than the supported project version of this PowerPmac IDE. Please upgrad to the newest version of PowerPmac IDE." But this is the new IDE. And it does not create a directory tree in the solution.

Hi - I installed the new IDE and created a project. Upon creation of the project I immediately got the error message: "Project 'PowerBrick_LV_Tango02.ppproj' is newer than the supported project version of this PowerPMAC IDE. Please upgrade to the latest version of PowerPMAC IDE." I can open the project but there is no directory tree. So the projects I created with the new IDE are said to be not supported whereas I can open old projects which I created with version no 3 of the IDE.

Ok, thanks for clarifying that!

Hi, I am dealing with a PowerBrickLV and in the documentation for the encoder setup it says "Halls T" for primary use on pin 14. When I look into the User Manual however there is no mentioning of Channel T and there is no mentioning elsewhere in the Manuals. What ist Halls T for? Best regards, hannsx

Hi, it seems the that my assertion is wrong, that both motors should perform the type of motion in time. The plot with the position of motor[6] on the Y-axis and motor[1] on the X-axis shows that they make a perfect circle, though distorted by the scaling of the image. When I think about it, it doesn't contradict a circular motion.

My linear motor has motor units of 50x10^(-9)m. Though the numbers seem very high, the maximum speed for motor[1] amounts to just 0.2m/s or 0.2mm/ms.

Hello EricHotchkiss, thanks for looking into this. These are not identical Motors. They have different MaxSpeed, InvAMax, InvDMax and InvJMax values. I added a Motor[].PosSf factor to each of them to make one unit equal to one micro meter of movement. So now they do show the same change in position per unit. These are the values for Motor[1]. That's a brushless linear motor: Motor[1].jogspeed= 1000 * Mtr1ScaleFactor Motor[1].JogTa= -( 1000 / ( 10000 * Mtr1ScaleFactor ) ) Motor[1].JogTs= -( 1000 / ( 1000000 * Mtr1ScaleFactor ) ) Motor[1].MaxSpeed=4000 * Mtr1ScaleFactor Motor[1].InvAmax= 1000 / ( 1000000 * Mtr1ScaleFactor ) Motor[1].InvDmax= 1000 / ( 1000000 * Mtr1ScaleFactor ) Motor[1].InvJmax= 1000 / ( 1000000 * Mtr1ScaleFactor ) These are the values for Motor[6]. That's a stepper motor in a linear actuator: Motor[6].jogspeed = 0.0005 * 1000 Motor[6].JogTa=-( 1000 / ( 10000 * Mtr6ScaleFactor ) ) Motor[6].JogTs=-( 1000 / ( 10000 * Mtr6ScaleFactor ) ) Motor[6].MaxSpeed=100 * Mtr6ScaleFactor //Max Speed Motor[6].InvAmax= 1000 / ( 10000 * Mtr6ScaleFactor ) Motor[6].InvDmax= 1000 / ( 10000 * Mtr6ScaleFactor ) Motor[6].InvJmax= 1000 / ( 10000 * Mtr6ScaleFactor ) From what I understood out of the User's Manual, the maximum values are reduced to the ones. I tried setting the limits and speeds of the linear equal to the ones of the stepper motor but that did not change anything.

Update: I am using Motor[1] for the Y-axis and Motor[6] for the Z-axis. I have no X-axis. I switched the axis assignments of the Motors and saw that it is always Motor[6] which is not doing the sinus. Are there Motor Setups which can prevent a motor from being included in the circle mode calculations? Is it maybe a problem, that the Motors are not on the same amplifier: amplifier1 = motors 1 - 4 amplifier2 = motors 5 - 8

Hi, I was just experimenting with move modes and did not get the motion paths for my axes that I would have expected for a circle. I intended to program a circle in the YZ-Plane and specify the center vector relative to the current position as 5000 units in Y-direction: /****************************************/ open prog 3 Coord[1].FeedTime = 1000 Coord[1].SegMoveTime=10 // Has to be greater 0 to enable circle move calculations Coord[1].MinArcLen = 5 // Circular motion in YZ-Plane inc F1000 // Feedrate Specification normal I1 // Specifies X as normal vector to circle plane YZ circle1 // Puts XYZ in clockwise circle mode J5000 close /****************************************/ However when I plotted the axes-motion I got the attached graph. I would expect both path to have exactly the same curvature. Am I doing something wrong?

I got it to work on 1/20 - scale. It seems as if the current loop is not affected by this scaling.

Hi - thank you for your advice. I tried with a small change in Motor[1].PosSf and set it to 1/2 to begin with. I managed to tune the motor, but it took a while. I will now try tro go on with 1/20 and see how it works out.

Update I mistook Motor[1].PhasePosSf for Motor[1].PhasePosSf. However if I change Motor[1].PosSf to 1/20000 and try to tune the gain terms I do not get any movement at all. 1/20000 should make the gain terms quite big and approaching the old gain terms multiplied by 20000 should show some action. But I do not see anything.

Hi, we are using an encoder with a 50nm count resolution. That makes the configuration of the motor-setup a little tricky. To make it easier for people, not that heavily involved in the Pmac, I would like to scale the encoder units into 1mm. I thought I could solve this by setting: EncTable[1].ScaleFactor = 1 / 20000 ; since there are 20000cts per mm. Furthermore I would multiply Motor[1].PhasePosSf by that factor to keep the commutation cycle correct. For my Motor it then becomes: Motor[1].PhasePosSf = 20000*( 2048 / ( 330000 * 256 ) ) ; However when I apply these changes, I am not able to tune the Position Loop gains. I am not sure if I am on the right path here either. In the teaching materials, there is a figure depicting the Motor Scale Factors. In that figure the EncTable[1].ScaleFactor is multiplied by Motor[1].PhasePosSf. That would effectively eliminate the Scale Factor I applied before. But If I do not adjust the Parameter for Motor[1].PhasePosSf, it would give the wrong counts for the commutation cycle. Is there a comprehensive explanation or example available on this topic. Is this even feasible? Best regards, Filip

Thanks for your comment. At our facility the ip-adresses have to be managed by the network branch in order to keep track of everything. Otherwise I guess that would be the easiest solution.

Ok - it is solved. Somehow the dns-server does not give the Pmac a fixed ip-address any more. When I read the ip-address via serial connection and use it in my IDE-connection it works fine. The Network guys will have to fix that. That in turn means I must've been trying to log into another machine all the time.

Update. I can log into PMAC via serial connection. That points towards an issue with ssh. I have contacted my network administrators for help and will let you know if I get to the root of it.

Hi, I am using a PowerBrickLV in an experimental setup and recently changed my Location in the Laboratory. When I tried to connect via IDE, it was not possible anymore. When I tried to log in via ssh I got a warning saying the ssh-key was unknown but I proceeded. However when I enter the default username and password I get the Message: 'Access denied'. In one thread I read about one user who had trouble after installing the IDE and found the reason to be a security software product. Are there other reasons possible? I did not change anything except that I connected the PowerBrickLV to another ethernet socket. Best regards, hannsx

Hi, I am using the CaptCompISR to store my motor position. I run it on a PowerBrickLV at a 1kHz frequency. After the Interrupt I immediately deactivate it. According to the Manuals I cannot write to the source bits of the Gate3[0].IntCtrl-register. Therefore I worked out this bitoperation to force the Position- and Capture-Enable Bits to "0", the Position- and Capture-Flag Bits to "1" while leaving the Source-Bits unaffected. Gate3IntCtrl = ( Gate3IntCtrl & ( Gate3IntCtrl ^ 0x00ff0000 ) ) | ( 0x000000ff ) ; This however didn't work and I was succesful when doing these operations, one at a time which produce the same outcome *MyFirstGate3IntCtrl = *MyFirstGate3IntCtrl & 0xff00ff00 ; *MyFirstGate3IntCtrl = *MyFirstGate3IntCtrl | 0x000000ff ; Then I use a phase routine to calculate the offset a my desired position and to inject it into to the Motor[1].CompPos register. At the end I want to activate the ISR again. There too I could use this code : Gate3IntCtrl = ( Gate3IntCtrl & ( Gate3IntCtrl ^ 0x00ff0000 ) ) | ( 0x00010000 ) ; To enable Position-Capture on Gate3[0] However it didn't work that way and I found that simply writing to it works: Gate3[0].IntCtrl = 0x00010000 ; However I expected there to be problems if I that would result in writing a "0" to the source bits. Does anyone have any further insight into this?

Update - As I had time to look at the problem again I got another Stepper to run on Gate3[0].Chan[1]. So It must've been some hardware Problem on the motor side. Unfortunately I can't recosnstruct exactly which connectors and motor I ran there but either way it rules out the pmac.

Update I do only have to read the Gate3[0].Chan[0].HomeCapt - register once after having unmasked the CaptCompISR and enabled the UserAlgo.CaptCompISR. Then it works reliably. Still the source and the enable bit of the Gate3[0].Chan[0].Equ output in the Gate3[0].IntCtrl-register flashes up regularly

Update It is the export of the UserShared Memory data that is causing these irregular pauses in the motion. The only question left is why the source bit of the Gate3[0].Chan[0].Equ and Gate3[0].Chan[1].Equ output in the Gate3[0].IntCtrl-register flashes up regularly when I do not use the inputs.