sutty
-
Posts
80 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Downloads
Posts posted by sutty
-
-
Hi Steve!
Unfortunately it is quite a deal to de-cascade the 2 loops. At least at the moment I cant spend time to do so. ... I will see in about 1 or 2 weeks and get back to you as soon I know more..
However, Is there a strict no-go for cascaded loops?
Bye, Anton
-
Yes, it is!
When I set Motor[4].Servo.MinGainFactor = Motor[4].Servo.MaxGainFactor (which forces Motor[4].Servo.GainFactor to that value) = "GainFactor" I calculated according several NominalGain-estimations, and it works from 0 to 100 kg.
For example I tune the 100kg system. Estimate Nominal Gain for 100 kg (around 50) and for 22kg (around 500). So I set Motor[4].Servo.MinGainFactor = Motor[4].Servo.MaxGainFactor = 50/500 = 0.1 which forces Motor[4].Servo.GainFactor = 0.1.
Might the cascading of motor #4 and #24 be a issue?
-
Hi Steve!
I rised EstTime up to 3000 - no improvments at all.
I have to mention again that that ABS(Motor[4].Servo.EstGain) wont rise above 2e-2 in no case.
Motor[4].Servo.NominalGain=4800
Motor[4].Servo.EstMinDac=100
Motor[4].Servo.EstTime=300
Motor[4].Servo.MinGainFactor=1
Motor[4].Servo.MaxGainFactor=5
Motor[4].Servo.NominalGain=4800
Motor[4].Servo.EstMinDac=100
Motor[4].Servo.EstTime=3000
Motor[4].Servo.MinGainFactor=1
Motor[4].Servo.MaxGainFactor=5
-
Hi!
It's one axis. Did tuning unloaded. IDE-Tune-tool says: NominalGain=4800 (unloaded) resp. 550 (loaded with 21,94 kg)
Servo: 16kHz
RTI: 2 kHz
Topology: Motor #4 and Motor #24 (put-through only) cascaded
Set Adaptive-Control-Parameters:
Motor[4].Servo.NominalGain=4800
Motor[4].Servo.EstMinDac=100
Motor[4].Servo.EstTime=160
Motor[4].Servo.MinGainFactor=1
Motor[4].Servo.MaxGainFactor=9
Motor[4].Servo.MinW=0
Motor[4].Servo.MaxW=0
Motor[4].Servo.MinDR=0
Motor[4].Servo.MaxDR=0Put load with 21,94 kg (total of 100 kg possible) on.
Motor[4].Servo.GainFactor remains all time at 1!!
Motor[4].Servo.EstGain wont go above 0.02
Lowering MinGainFactor would lower GainFactor during accel/deceleration equally to MinGainFactor
By the way setting MinGainFactor = MaxGainFactor = 9 would give a nice and stable setup with 21,94 kg load.
I am really rookie-like - but can anybody show me a good practice example?!!
Would I absolutely have to also set MaxW, MinW, MaxDR and MinDR?
Thanks and regards,
Anton
-
Any news on this topic?
This issue accompanies me since 2018 with PPMAC V2.2.0.37, IDE V3.0.1.0 (see here)
-
2
-
-
Hi Curt!
Besides this mystery, what do you think, will I completely overcome this phenomenon by simply using whole-words resp P-Vars ?
The attachment is a simple ppmac-project which leads on a umac-arm cpu to such issue.
P3=0 (whole-word access - no errors)
P3!=0 (bit access - erroneous)
I used a gate3 for the clocks.
No physical hw (motors ..)
Have a nice weekend!
-
I also know this kind of phenomenon where a motor sounds noisy. Several reason:
* bad ECAT-setup (steady noise)
* wrong ServoExtension (should be set so ECAT-Update matches servo-freq) - steady noise
* noise during opening/connecting/closing IDE resp. especially IDE-Taskmanager to PPMAC (gpascii) in combination with heavy cpu-load
-
After more than 6h of testing-runtime the statistics say following:
-
Sys.ServoBusyCtr (black) remained 0 during gathering, increments slightly within minutes...
-
Hi Curt!
I took a plot of what happens here:
m2->u.user:$1884.26.1
plc4: increments p1+=1 and resets m2=0 if m2==1
uws: increments p2+=1 and sets m2=1 if m2==0
with Sys.BgSleepTime=1000 the difference between counter p1 and p2 remains 0
with Sys.BgSleepTime=250 p2 advances about 1 each 10s
Discussion:
In the plot below it shows on the left that plc 4 increments p1 (purple) and resets m2=0, then uws increments p2 (orange) and sets m2=1.
To the right it shows, that plc4 increments p1 and resets m2=0, but must be interrupted by uws, which (for whatever reason?) already sees m2=0 and so increments p2, but does NOT succeed setting m2=1. plc4 resumes at the point where it was interrupted by uws before and finishes up (in any case without incrementing p1). uws at next interrupt still sees m2=0 and does its job (increments p2 and sets m2=1) once more time. now p2 leads p1.
Is this what you expect it to do?!
I dont get it, that uws can see m2 already equal 0 even though plc4 has not finished its task?!!
-
Eric,
uws sets M1=1 only if it reads M1==0 & Capture has happened
bgplc resets M1=0 only if it reads M1==1.
What I was asking for, can it be possible uws fails writing M1=1 at all (in that circumstance that uws interrupted bgplc while bgplc was just reading M1 & a Capturing has happened so uws would want to set M1=1)
Using M1->*u or M1->u.user:$001880.0.32 (whole-word access) instead of M1->u.user:$001880.26.1 (bit access - multi-step process) are both possible solutions for this issue?
Regards,
Anton
-
Curt, will your suggestion to use whole-words (avoiding multi-step process) solve such issue in all cases (100%)?
I am asking because in our case:
uws checks a caputre flag. If the capture has happened it sets variable M1=1
bgplc polls M1. After it sees M1==1 it does stuff and at the end resets M1=0
But in very raw cases M1 never gets set even tough the capture has happened.
Is that possible while bgplc only reads M1, the interrupting uws can not change M1 at all?!
What do you mean by implicit/explicit operations?
Would it also help to use a self-definded M1->*u instead?
-
Thank you, Curt, for clarifying!
Besides your suggestions (whole-word access) I don't see any other way to go.
Anyway, it will do, we got some space left ;-)
-
Hi!
In usrcode.c (user-written-servo) I am reading from and writing to M-Vars, which for itself are assigned to locations on user-shared-memory. But I am NOT using GetPtrVar() nor SetPtrVar(). Instead it works like this:
address = 0x001880;
ushptr = (volatile unsigned int*)(pushm + address);
read:
u32v = (unsigned int)((*ushptr & (1 << start_bit)) >> start_bit);
write:
*ushptr |= mask;
In a script plc I do the same on such M-Vars. The m-variable definition looks like this:
M1->u.user:$001880.26.1
In that plc M1 is reset once in a while.
Now and then it happens, that setting M1 within uws does not succeed, and remains 0.
Besides, using P-Vars instead of M-Vars dismisses such issue and setting/resetting works all the time.
Regards, Anton
Ps. pp_proj.ini:
[CPU_AFFINITY]
rtpmac_main=0
servotask=1
rtitask=1
backgroundthread=0
-
Hi!
My forward kinmatic subroutine is 1 single line calling CfromScript():
open forward (1) ForwardKin1ErrCode = CfromScript(cfsNr,KinematicType,NrPoints,0,0,0,0); close
Anyhow, I do not get axis velocities nor axis following errors when issuing &1v resp &1f, eventhough I tried to rebuild the double pass option (where CfromScript() simply calls ForwardKin())
double ForwardKin(int kinType, struct LocalData *Ldata) { double ErrCode = 0; //double *R; double *L; double *C; double *D; int i; int tmpKinVelEna; //R = GetRVarPtr(Ldata);//Ldata->L + Ldata->Lindex + Ldata->Lsize; L = GetLVarPtr(Ldata);//Ldata->L + Ldata->Lindex; C = GetCVarPtr(Ldata);//Ldata->L + Ldata->Lindex + MAX_MOTORS; D = GetDVarPtr(Ldata);// Ldata->D; //if (KinVelEna) callsub 100; if (KinVelEna > 0.0) tmpKinVelEna=1; else tmpKinVelEna=0; for (i=0; i<=tmpKinVelEna; i++) { //double pass option? if (tmpKinVelEna == 1) { if (i == 0) { Ldata->Lindex = Ldata->Lindex + Ldata->Lsize; } else { Ldata->Lindex = Ldata->Lindex - Ldata->Lsize; KinAxisUsed = 0x1C0; //X,Y,Z in use } } else { KinAxisUsed = 0x1C0; //X,Y,Z in use } //N100: if (1>0) //pshm->Coord[1].HomeComplete) { if (kinType == 0) //standard { ... and so onCan anybody tell me how to realize such double pass option the right way in a CfromScript() program?!!
Best regards,
Anton
-
The present algorithm was designed to ensure that memory conflicts could not be created as tables were entered in development. We are looking to see if there is a way around these protections.
Meanwhile have you found "a way around these protections"?!
Also important how to free table-buffer, since save-cmd takes quite some time (minute) if 500MB are in use.
-
Typically, compensation for CMM is done on a computer. Compensation in PMAC is used to compensate for motion, but CMM does not require a high absolute motion accuracy. CMM requires only a high measurement accuracy. Therefore, the position of the motor encoder is taken back to be calculated to calculate the exact trigger position of the probe
Thanks for your feedback.
And yes, I agree for trigger-probing, where the compensation can be done on the measured points (on the host-pc). But the new 3D-Compensation on PPMAC allows compensating the whole trajectory, which is good for scanning-probes.
-
Thank you, Curt!
(You say it is a CK3E CPU. Are you sure you don't mean CK3M?)
Well, more precisely it is a Power UMAC with a ACC24E3
-
Hi!
To increase the volumetric performance of a CMM, geometric error compensation, also known as computer-aided accuracy, is indispensable.
I split these errors I need to compensate into 2 leagues: position-dependent and position-independent errors.
Position-dependent errors can once more be split into 3 translation and 3 angle errors per axis. In sum 18 error-parameters for all 3 axis.
Position-independent errors are the 3 squareness-errors between the 3 axis.
(Besides, thermal errors are to be counted to the positioning-errors (as part of the translation errors))
Once those 21 error-parameters are known (eg through measuring with laser interferometers) there are several ways for getting PPMAC doing the job:
+ axis transformation matrices
+ kinematic subroutines
+ axis definition statements
+ 3D compensation table
However, for the matter of computational load I did simplified testings with 3D-compensation table (3rd order interpolation). On a CK3E-CPU with Phase/Servo/RTI of 32/16/4 kHz, one table put another 2 to 3% load onto the foreground CPU (I tested up to 8 tables leading to +20%)
This result made me wonder, if it would make sense to use other features of PPMAC than a 3D-compensation-table, with the goal getting the 21-error-parameters into PPMAC with the least necessary amount of CPU-load.
Questions:
Does anybody have experiences concerning this issue, how did you solve it?!
Which of the above features consumes how much of the CPU-power (rule of thumb)?
Are there any other features not listed here which could be used?
Does somebody have a list of hints to save cpu-power (besides 32/16/4 kHz loop freq, I know)?
3-D compensation tables are calculated with servo-update-rate (0.0625ms), Segmentation (10ms) time would be enough - but how to get there?
General question:
Which strategy to follow: Should I rather do the compensation in the forward path (between trajectory calculation until servo-loop), than in the backward path (compensating actual positions)?!
Don't hesitate for any idea!
Thanks!
-
Hi Alex!
Did you get to do some testings meanwhile?
Any news?
-
Hi Alex!
Take in account that in my case ECAT runs in busshift-mode! Besides everything else is on default-setting.
I need SDOs only for tuning-issues (setting gains) - so as a workaround I can change ServoExtension for that goal, and set it back after each SDO-write-access.
Anyhow, thanks for keeping track on this!!
-
Hi Jeff!
Now I found the reason for the mailfunction of ecattypedsto() --> ECAT[].ServoExtension
If set to match the ECAT Cycle time (eg 1ms Cycle time, Servo-Freq 16 kHz --> ServoExtension=15) then the function ecattypedsdo() delivers "nan" all the time.
If ServoExtension=3 or less, then the function ecattypedsdo() works correctly and delivers reasonable values all the time.
The lower ServoExtension, the higher its reliability.
Thanks anyway for your efforts!
-
Thanks, Jeff!
Do you mean ecatreset or $$$ or $$$***!?
-
Sorry, in my case the ecattypedsdo() function seems not being stable.
I can't get any value from any of those addresses anymore. Also not on lower servo-frequencies.
I will try it next week again.
Is their any advice for savely using this function?!
By the way, of course, ServoExtension was well set since all the time to meet the 1ms cycle time of ECAT.
Adaptive Control - is this working at all?
in Power PMAC
Posted
Ok. Ask your experts, I will test it by next chance.