piefum
-
Posts
140 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Downloads
Posts posted by piefum
-
-
Hi
thanks for the explanation.
However, even if the configuration is properly saved on the PMAC, the problem after a reboot is still there.
I found this thing that could be interesting: in order to make the motor move after a reboot, I need to go again through the System Setup.
The strange thing happens on the System Setup: when I open it, the motor and driver properties on tabs 1 through 6 are all at the correct values; however, if I jump to tab 7 "Test And Commissioning" and I run the automatic test, I got the Overcurrent error.
In order to not get the OverCurrent error, I need to go to tab4 "hardware Interface", click on Accept and then I can go to tab7 and run the automatic tests without error.
When I click on the Accept button I can see on the Output panel that the Motor properties downloaded are the same that are already in memory; together with the Motor properties it is also downloaded the command BrickLV.Reset = 1.
At the moment the system works as expected only if i send a BrickLV.Reset=1 after a power-on, otherwise I got the overcurrent error.
Is that behavior nominal? I didn't find any reference on mandatory brickLV.Reset=1 command after power-on on the documentation.
Thanks
gigi
In order to retain your changes you've made through the System Setup software, you need to generate a configuration file, and then copy the changes into a file under PMAC Script Language-->Global Includes in your project.
To generate a configuration file, right-click the Configuration folder in your project, and then click Generate Configuration File. This will contain all the changes made from factory default. Copy what you need out of there and paste it into the file you made in the Global Includes folder. You need to download your project at this point, and then issue SAVE, and then the settings will be retained.
Regarding the inability to clear the fault, please call technical support to alert them of that issue; call them at 818 717 5656.
-
Hi
I just updated the firmware to 1.6.1.1, sent a general reset and restarted the configuration.
I am using now the automatic System Setup available in the IDE.
I can configure correctly the Stepper Motor to move in Direct-MicroStep, and this is a very good news.
Unfortunately, I can't keep the configuration after a reboot (hardware or software).
All the variables are stored correctly (I check them via the Setup Variable panel on the IDE), but after a reboot the motor does not move and I continously get the overcurrent fault (C2 on the led).
Moreover, it seems that the overcurrent fault is latched in hardware: the $$$ is not affecting the state of this fault, as well as a BrickLV.Reset = 1 command; only an hardware power cycle is deleting this fault.
Any ideas?
thanks
gigi
-
Hi
It sounds like you might have set Motor[x].PhaseOffset incorrectly, and possibly Motor[x].PwmSf as well. What values do these parameters have, and how did you set them? I recommend going back through the automatic setup for this motor and specifically the Voltage Six Step Test and the Current Six Step Test.
I used the value on the documentation, that are fixed for the stepper motor. "Unfortunately" we are on vacation now and we will reopen the office in 3 weeks, I will try to setup the motor with the automatic procedure.
Thanks
gigi
-
Hi All
I am trying to setup a Stepper motor on a brand new Power Brick LV driver.
The setup is:
- power brick LV, 1.6.0.30, 5/15A
- IDE 1.7.0.53
- RTA stepper motor, 5.6A, 1.9 deg/step, 75V DC max
I am following instructions on Power Brick LV preliminary manual (28 May 2014), setting up a stepper motor with encoder, using the stepper as high pole count brushless (p. 122 of the manual).
I followed all the instruction up to the I2T setting, then, proceeding in order with the manual, I should tune the current loop as in the regular brushless motor.
However, I am constantly getting an overcurrent fault ("2 C" on the front led display, because I am working on the second channel), for any current loop test that I perform: "simple autotune" and "auto-tune" always fail, as well as the "Interactive Tune", even if I set a smaller gain and a magnituted of 1 bit on the step size parameters.
What I see on the motor is that it get a hit, moves of few degrees, than it stopped with the Overcurrent error.
After that, I can't even recover from the error with teh BrickLV.Reset = 1 command, neither with a soft reset $$$: the only thing that I can do to restore from this error is a hardware power cycle.
Do you have any idea on what's happening and how can I tune the stepper motor?
thanks
gigi
-
[sOLVED: it seems that the Motor[].AbsPosSf was not saved after I set it on the terminal but not on the config file].
Hi All
I have a problem detecting the absolute multiturn value at power on.
The setup is the following:
- power brick LV, 1.6.0.30
- IDE 1.7.0.53
- Endat 2.2 encoder multiturn: 23 bit/revolution + 12 bit absolute rev, for a total of 35 data bits
I followed the instructions on Power Brick LV User Manual (May 28/2014), pag 40, but I still cannot get the multiturn position (my encoder differs from the one on the example only on the 23 bit/revolution instead of the 25 in the example).
At power on, I get the absolute position on the single turn, but I loose the information on what multiturn I am on.
Moreover, when I issue a #n hmz, the reading of hte encoder is set to 0.000, not the absolute value (that anyway is acquired with a reset).
Do you have any idea? Is the manual wrong?
thanks
ciao
gg
-
Hi all
has anyone tried the zeromq libraries ( http://zeromq.org/ ) on the Power PMAC system?
I will need this solution to implement a socket communication mechanism between my Power PMAC and a global Control System for the entire plant.
Do you think these libraries can be imported on the Pmac IDE and compiled for the PowerPMAC?
thanks
gigi
-
Hi Charles and Curt
The first issue sounds like an IDE bug.
...
Only that which has been added to the project system and downloaded to PPMAC can be retained through a SAVE.
ok, understood: when I downloaded at first the ECT there was no project active on the IDE. Now that there a project, everything is working fine.
Sorry for the newbie question, I didn't get that a project loaded was mandatory.
Thanks
Gigi
-
Hi all
I am turning on in these days a new system with this setup:
- power brick LV, 1.6.0.30
- IDE 1.7.0.53
- Endat 2.2 encoder multiturn: 23 bit/revolution + 12 bit absolute rev, for a total of 35 data bits
The configuration for the encoder should be like:
- # bit used: 23
- result unit per LSB: 9.5367e-004 (8000 um screw / 2^23 bit)
- source address: PowerBrick[0].Chan[0].SerialEncDataA.a
I have some problems on the Encoder Conversion Table:
1) If I use the window under "Configure -> Encoder conversion table" and enter the variables as per previous point, I constantly get the error "ECT Setup:192.168.125.129 Download entry 1 failed. Check your parameters and try again:7/22/2014 :10:32 AM" when downloading the configuration. However, despite the error, the configuration is downloaded because I can see the position change of the correct amount when I turn the encoder by hand. Moreover, if I look at the same variables in the window under "Configure -> Setup Variables", these are changed according to what I set on the other window. What is the origin of this error?
2) When I issue the SAVE command, the encoder conversion table is not saved (other variables are properly saved): at the reboot, I get the default address (PowerBrick[0].Chan[0].ServoCapt.a), method and Scale Factor set on the ECT. Is that because of the error on the previous point?
(I have a problem also on the Absolute value reading, but I will put this in a separate thread).
Thanks
gigi
-
I think we have a way of figuring this out using the "watchdog timer". The watchdog counter register (Y:$25) gets reset to I40 value at the end of each background cycle (or house keeping) and every Servo interrupt the counter is reduced by one until next house keeping occurs. The lowest value the watchdog counter ever reaches from a power up/reset is stored in X:$25 register.
We can either:
1. Take the average of Average(I40 - Y:$25) for a certain period and find out how many Servo cycles it takes for the CPU to go through a background cycle.
2. Assume the worst case scenario and use I40 - X:$25 to assume the longest background cycle.
I would suggest using the 1st method as you're trying to adjust a minimum Ixx88 required for your application.
this seems very intersting, thanks! tomorrow I will try to measure the cycle and see what I can get
ciao
gigi
-
Background in position check period as you mentioned is dependent on the housekeeping period which can vary depending on the CPU load. Since CPU load is not constant (even a query from PC can affect the CPU load) this will not provide you with exact timing.
However, using I13 you can let the PMAC check for in-position in foreground and set a bit 13 of motor status word. However, this method does not support Ixx88 and you have to implement this code as an RTI code to check for Ixx88 consecutive cycles and set a custom flag for your process.
Thanks Sina
I understand the way it works I13, but I would prefer the use of Ixx88 instead of a higher load on servo-interrupt and a RTI to be written from scratches.
I would choose then to set the In Position with a not-so-exact timing, I would say 0.5 < t < 1 s.
Is there a way to have an idea of the housekeeping frequency?
thanks
gigi
-
Hi all
I need to know the exact unit for Ixx88 (Motor xx In-Position Number of Scans) because my UMAC have to raise the InPosition flag after the actuator is inside the In Position Band for 0.5 s.
I understand the Ixx88 frequency is function of the housekeeping... but is there a way to measure this frequency? Keep in mind that my PLCs do not have any fancy computation, meaning that the CPU load for each PLC is always the same.
Thanks
Gigi
-
Hi All
I am using the hardware available here (Geo Macro GMH 152 + UMAC) to drive an old actuator that we must refurbish for an old customer.
The actuator embeds a TTL encoder, a sin/cos 1Vpp encoder and a Brush Motor (24V dc).
The manual of the GeoMacro says that it is possible to drive the brush motor, so I am trying to re-tune this hardware.
For the moment, I am trying to drive the actuator with only the TTL encoder. The reading of the encoder seems ok: if I drive the motor via a 24V external power supply, it moves and the UMAC sees the TTL encoder counting of the correct amount.
I have problem driving the Brush Motor. I followed the instruction of the manual, and now I am stuck in a point where I can't tune the current loop.
Let's get in order:
- The two phases of the motor are connected to A (or U) and C (or W).
- the GeoMacro is powered at 100V DC. To ensure that the maximum output voltage limited to 24V dc, I am using Ixx66 as threshold:
Ixx66 = VmaxMotor / Vdc * i6800. In my case, Ixx66 is 725. Is that correct?
- If I use the Ixx66 setting computed as above, I can't move the actuator in open loop
- If I use Ixx66 = 1500 (doubling the max Voltage, anyway inside the maximum limit of that motor), I can move the motor with Open Loop commands. However, I can't tune the current loop. I am tuning it starting from Ixx61 = 0.01 and Ixx76 = 0.1 and going up, but it seems that the gain are not controlling anything. In the attached plot you can see a test (run from a PLC) that is commanding the actuator in open loop commands (o20 and o30): the plot shows the Commanded Current( addrress X:$000BF) and Actual Current (X:$000B9). As you can see, the actual currents rise and move the actuator, but it does not follow the commands. That behavior is exactly the same for any gains I put (I stopped at Ixx61 = 0.01, Ixx62 = 0.3 and Ixx76 = 0.5).
Did I forget any other setup for hte brush motor?
Thanks
Gigi
-
Current loop is a closed loop system. It relies on the ADC feedback. One possibility is something changes on one or both of the ADC feedbacks.
Current loop is coupled to phase position. The reading of the phase encoder is usually not the same as the position encoder as one goes through the ECT and might even be interpolated. So something could have changed on the phase encoder value.
ok, good to know. In fact, the ECT entry of this channel has an Exponential Filter (Max change + LPF filter).
How can I check that the phase encoder value has some problem?
-
No, I cannot tell which came first; unfortunately, with this setup (ethernet connection to the UMAC) I cannot go faster than these 32 Hz.
I finally managed to gather at high frequency the strange blip; in attach you can see a plot showing the following error, the actual current and the commanded current.
It seems that the blip is starting from the actual current (readout of the ADC of the geomacro).
Does this means anything to you?
ciao
gg
-
Yes, internally what happens is that the raw following error value FE is adjusted using the "deadband" parameters, producing a modified following error value FE' that the servo loop operates on. This has the result of changing the effective proportional gain as a function of raw following error.
ok, thanks. On the same topic: when the deadband compensation is activated? It is always ON or there is another condition to start the compensation (i.e. commanded vel = 0) ?
The manual does not cite any particular condition to trigger the deadband compensation.
thanks
ciao
gg
-
The "TURBO PMAC USER MANUAL" has a good graphic of this on page 159 (175 electronic):
http://www.deltatau.com/manuals/pdfs/TURBO%20PMAC%20USER%20MANUAL.pdf?id=635288562230097687
Hi Steve
that's exactly what I was talking about. If you confirm that this is the way it is implemented, it's fine with me.
In reply to Brian: I don't think the PID result is the same if the deadband gain is applied to the following error or the Ix30.
E.G: let's forget for the moment that the gain is applied without discontinuity (as explained in Turbo PMAC USER MANUAL, p. 160).
I'm assuming the deadband gain is -12, for a total gain of 0.25;
if the deadband gain multiplies Ixx30, I will encounter a discountinuity and a large loss of output current when I enter the deadband, because suddenly the Ixx30 (and then the output) is multiplied by 0.25.
If the deadband gain multiplies the following error, when I enter the deadband, the 0.25 gain is applied only to the proportional and derivative part of the PID, leaving the integral part constant.
Considering the fact that I need the deadband to decrease the high frequency controller "noise" when I am keeping a position in close loop (with an high integral output because I need to keep the load in position etc), a deadband gain that multiplies the Ixx30 is unusable for my application.
I am running some tests right now, it seems that the gain multiplies only the FollowingError as explained in the TurboPMAC User Manual, so that's good for my application.
ciao
gg
-
Hi all
in my actuator tuning I need a special commanded velocity feedforward branch, that must have an output limitation.
The problem with my actuator is a stick-slick effect that I can easily counteract with a strong and fast velocity feedforward that kicks-in fast for each commanded motion (very small or very large).
I use this in the open-servo algorithm more or less like the Ixx68-Friction Feedfoward gain, but in my open servo implementation it is applied linearly with the commanded velocity, without the bias/discontinue effect of the Ixx68 gain.
Is there anything I can do to implement this in the regular PID? Maybe changing the FeedForward gain in runtime? The Turbo SRM cites that the gain can be changed during runtime, but I cannot find infos about that.
thanks
gigi
-
In that situation I imagine you would just not have any data points and you would see in the data which usually has the servo count included a jump in the servo count that is too large and would indicate the gathering did not happen at that cycle.
I am looking at the servo count included in the data gathering: the Time coordinate on the plots is exactly the servo count scaled into Seconds for more readability.
It seems that the gathering has been performed without problems: the time frame between each measure is constant during all the test (1 servo count each datum gathered).
-
Hi all
I have a question regarding the deadband gain Ixx64: what does it really multiply? In the Turbo SRM (p. 107) it is stated that the Ixx64 gain multiplies the proportional gain Ixx30; however, in the Turbo PMAC user manual it is stated that the gain is applied to the following error used in the servo loop.
It seems to me that it is more logical to have the gain multiplying the following error instead of servo output (keeping the integral part of the output near-constant over time, regardless of the deadband gain).
Am I correct? Is the Turbo SRM wrong in that?
thanks
gigi
-
It does not look like you are using the PMAC plotting. What are you gathering and how are you recording it? This might give some clues.
These are the addresses that I gather and are plotted in the previous post:
i5001=$80008B // Actual Position i5002=$8000A5 // Commanded position
...
i5005=$4000BF // I command value
i5006=$4000B9 // Actual current
-
did you look at any status bits such as servo error and real time interrupt re-entry? I would not be surprised to see servo error coming on meaning the servo code is not always finishing in one servo cycle.
No, I'm sorry, I had not look at the servo error flags. But is it possible that an error on the servo generates such a random behavior on the current and encoder readings? I don't understand why, with a 8% load, the CPU has crashed under the PLCCs and PVT maneuvres.
ciao
gg
-
UMAC is a Turbo PMAC so the statement holds.
Although some people run with CPU higher than 50% when you get to that point you must carefully evaluate how the entire system behaves because you are in the region where tasks might get starved of time. All this causes is run time errors and slow communication and slow execution of PLCs/PLCCs and perhaps a watchdog. So you must be sure that when everything else is going the system is robust for the application you have written. Our statement means that you are in the zone where such faults are more likely to occur.
So, I ran some test last week on the Hexapod machine, and the results are not promising.
Here's a brief description of what we tested on the system, we'd like to have your opinion on that, because what we saw was at some point really scary.
Apart from the OpenServo, the system is loaded with:
- kinematics computation
- 1 PLCC that performs the forward kinematics, to compute actual hexapod position from actual position of the 6 encoder
- 2 PLCCs that compute the variance of the following error, used as watchdog to stop oscillation (1 PLCC for fast oscillations, 1 PLCC for slow oscillations with a different timing)
- 2 PLCs that monitor external sensor variables (ADC input) and in case stop the motion
- 2 PLCs for communication (one checks if a command has been sent, one to move the variables to return to the host in the proper register position)
First test: we run the hexapod with the Open Servo controller that I tuned on a single axis and run on my lab for several weeks. The servo CPU load is 72% for all the 6 axis. I sent small motion commands to the hexapod, at it behaves correctly: the system stayed in close loop for several minutes without any sort of error.
Second test: because of the "50% suggested limit" we removed some filters on the OpenServo algorithm and we used it as a carbon copy of the standard UMAC PID (just to test that if it behaves like the regular PID).
The CPU power consumption for the 6 axis is 47%. Again, the system stayed in close loop and has been moved for several minutes without any error.
We then tryied to perform a PVT test that help us in measuring the transfer function of the actuator; it is a constant velocity command with an overimposed noise. The PVT file is generated by a Matlab script.
To perform this test, the kinematics is turned off and all the actuators are assigned the X axis, so all the actuators are moved simultaneously. This test has been performed hundreds times in the past, so we are confident on the correct execution of the PVT command. The PVT program is quite long (5000 lines); the code of the PVT test is the following:
CLOSE END GATHER DELETE GATHER DELETE TRACE OPEN PROG 21 CLEAR ABS PVT2 X 0.000000 : 100.000000 X 0.200000 : 100.000000 X 0.400000 : 100.000000 X 0.600000 : 100.000000 X 0.800000 : 100.000000 X 1.000000 : 100.000000 X 1.200000 : 100.000000 X 1.400000 : 100.000000 X 1.600000 : 100.000000 X 1.746460 : 74.844406 X 1.896149 : 196.944243 X 2.290038 : 72.480201 X 2.434998 : 58.546872 X 2.552092 : 95.639992 X 2.743372 : 163.561903 X 3.070495 : 42.032994 X 3.154561 : 107.092339 ...
Here begins the strange behavior of the system: at first, we tried to run the PVT test on the 6 actuators with teh OpenServo enabled on all of them. The maneuvre did not succeed because some actuators went in following error right after the PVT commands had been issued.
We then decided to load the OpenServo only on 1 actuator, in order to have the smallest CPU load possible. The total ServoTime measured was 8 %.
We run again the PVT test, and here the system started to behave crazy. In attach you can see a couple of plot showing positions and currents gathered t servo-loop rate directly on the UMAC.
The actual position (red line), measured by the encoder, has several points at 0.0 (not even a bit set to 1) and 1 point at -2.8e8 (basically -inf, that number cannot exist). These measured skipped all the low-level safety systems such as the Encoder Conversion Table filtering, Following Error, etc.
The corresponding currents measured are quite scary too: the plot shows the commanded and actual currents as read by the ADC. It seems that the ADC read two points at full-scale (30A) and the commands has several points at 0 A or out of the limit imposed on the Open Servo (7A, clearly visible in the flat part of the plot). These kind of error appeared only in the first part of the PVT maneuvre; the remaining part of the test (10seconds) is ok.
Because the hexapod is mounted on the final system with all the other instruments, we obviously decided to go back to the standard PID configuration and do not explore the Open Servo on the hexapod system until we got a description on what happened on the machine.
The OpenServo that generated that error is the following.
FYI, we decided to go to the openservo solution because we needed:
- an extra D action with a notch filtering
- a velocity feedforward with a limited threshold
- an extra filtering while the hexapod is inposition
We'd like to know if and how we get this malfunction of the UMAC: is it an error on our side due to CPU load? The PVT with 2ms pacing is too fast and it takes too much CPU time? Is there any other way to perform the filtering that we need on the PID?
In the code that follows, we use only the standard PID branch as implemented in the UMAC (all the rest is commented).
CLOSE END GATHER DELETE GATHER DELETE TRACE #define AddrOffset P3000 ; offset of the address, used to address all the motors in the proper variables (P3100 to P3199 for motor 1, etc) #define MaxOut P3004 ; output saturation limit #define ActualOut P3005 ; actual output (temporary variable) #define FFGain P3009 #define FFLim P2999 #define FEOffset 2 ; #define ServoCycle L0 L0->X:$0,0,24,S ; Servo cycle counter #define LastServoCycle L1[MTRNUM-1] L1->X:$010400[32] ; Register array in UBUFFER #define ServoExtension L2 L2->Y:(R1-$21) #define PIDout F1[MTRNUM-1] F1 ->L:$010000[32] ; size 32 is MANDATORY!! #define Dout F2[MTRNUM-1] F2 ->L:$010020[32] #define Mout F3[MTRNUM-1] F3->L:$010040[32] #define PREVouta0 F4[MTRNUM-1] F4->L:$010060[32] #define PIDa2 F5[MTRNUM-1] F5->L:$10080[32] #define PIDa3 F6[MTRNUM-1] F6->L:$100A0[32] #define PIDb1 F7[MTRNUM-1] F7->L:$100C0[32] #define PIDb2 F8[MTRNUM-1] F8->L:$100E0[32] #define PIDb3 F9[MTRNUM-1] F9->L:$10100[32] #define Da2 F10[MTRNUM-1] F10->L:$10120[32] #define Da3 F11[MTRNUM-1] F11->L:$10140[32] #define Da4 F12[MTRNUM-1] F12->L:$10160[32] #define Db1 F13[MTRNUM-1] F13->L:$10180[32] #define Db2 F14[MTRNUM-1] F14->L:$101A0[32] #define Db3 F15[MTRNUM-1] F15->L:$101C0[32] #define Db4 F16[MTRNUM-1] F16->L:$101E0[32] #define PREVouta1 F17[MTRNUM-1] F17->L:$010060[32] OPEN SERVO CLEAR COPYREG P3010 ; P3010 to P3015 are {ActualVel; DesiredVel; FollowingError; ActualPos; DesiredPos} units are the same as ESA, so FE is (1/(1xx08 * 32)) cts ; reset out e input variables: OPTIMIZE THIS!!! IF (ServoCycle-LastServoCycle!=ServoExtension+1) PIDa2 = 0 PIDa3 = 0 PIDb1 = 0 PIDb2 = 0 PIDb3 = 0 Da2 = 0 Da3 = 0 Da4 = 0 Db1 = 0 Db2 = 0 Db3 = 0 Db4 = 0 ENDIF LastServoCycle=ServoCycle ; Store for next cycle ; P path ; numerator * FolError PIDout = (P3012 * 2.885683) + (PIDa2 * -5.388260) + (PIDa3 * 2.503395) + (PIDb2) ; shift prev errors PIDa3 = PIDa2 PIDa2 = P3012 ; shift prev out ; set prev P output PIDb2 = PIDout; ; Derivative path ; numerator * FolError ; Dout = (P3012 * 2.503395) + (Da2 * -7.346922) + (Da3 * 7.346922) + (Da4 * -2.503395) - (Db2 * -1.818224) - (Db3 * 0.879512) ; Dout = ((P3012-Da4) * 2.503395) + ((Da3-Da2) * 7.346922) - (Db2 * -1.818224) - (Db3 * 0.879512) ; shift prev errors ; Da4 = Da3 ; Da3 = Da2 ; Da2 = P3012 ; shift prev out ; Db3 = Db2 ; set prev D output ; Db2 = Dout; take only previous D out ; set actual out as prev out for the next cycle ;End of servo loop ; ========== modding on assist ;if (M(ITOF(MTRNUM * 100)+40) != 0) ; != 0 invece che == 1 fa risparmiare 0.01% ; Mout = PREVouta0 * 1.9 - PREVouta1*0.9025 + PIDout * 0.0025 ; check this filter in matlab as tf(0.1, [1 -0.9], 1/2250, 'variable', 'z^-1') ;else ; Mout = PIDout + FLIMIT(P3011 * 50, 179200); + Dout ; extra vel FF with 1 A limit ;endif ;PREVouta1 = PREVouta0 ;PREVouta0 = Mout ; ========= end modding on assist Mout = PIDout RETURN(FTOI(FLIMIT(Mout, 1488640))) ; CLOSE -
Gigi, please correct me if I am wrong, the system we are speaking about is RJ45 Macro, correct? This is important for Richard to know in regards to the Macro Ring Error discussion.
FYI: we think we solved the startup false error problem with an extra power line filtering.
The main power supply now pass through a 3phase transformer that reduces the V ac input of the GeoMacro by a factor of ~4 (400 to ~90V ac), that is the voltage necessary to the application. At the beginning of the project we decided to keep all the voltage available for contingency, but now we decided to go for the extreme reliability of the system.
The motors are now equipped with pure sinusoidal filters (before we had only PWM slew-rate filter), and the system seems more quite (in terms of both acustic and EMC).
bests
gigi
-
Other than that I can pass the developement environmet and some samples for the assembly coding.
Hi Brad
I am in front of the Hexapod system where I plan to put the Open Servo algorithm. It looks like that the CPU load is almost linear with the number of axis activated: the load on one axis is around 12% and on the full 6 axis is 72 %.
This is only the Servo Task load. Please keep in mind that the UMAC is also running forward and inverse kinematics as well as several watchdog PLCCs.
On the Turbo PMAC manual it is stated "It is generally recommended that the portion of processor time devoted to phase and servo tasks not exceed 50%, in order to allow sufficient time for lower-priority tasks, such as motion program and PLC program calculations. To find out how much processor time an Open Servo algorithm occupies, refer to the section Evaluating Turbo PMAC’s Computational Load."
Is that valid also for this UMAC / Turbo PMAC 2? Should I be concerned about that load?
thanks
gigi
Communication with external word
in Power PMAC
Posted
Hi
how did you manage to install the zeromq libraries on the pmac?
I copied all the sources on /tmp, run "./configure" and "make" and everything worked fine; however, I get a write-only error:
how can I install the libraries?
thanks
gigi