sutty

Ok. Ask your experts, I will test it by next chance.

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=4800Motor[4].Servo.EstMinDac=100Motor[4].Servo.EstTime=300Motor[4].Servo.MinGainFactor=1Motor[4].Servo.MaxGainFactor=5 Motor[4].Servo.NominalGain=4800Motor[4].Servo.EstMinDac=100Motor[4].Servo.EstTime=3000Motor[4].Servo.MinGainFactor=1Motor[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=4800Motor[4].Servo.EstMinDac=100Motor[4].Servo.EstTime=160Motor[4].Servo.MinGainFactor=1Motor[4].Servo.MaxGainFactor=9Motor[4].Servo.MinW=0Motor[4].Servo.MaxW=0Motor[4].Servo.MinDR=0Motor[4].Servo.MaxDR=0 Put 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)

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! VarSync_09_ppmac_from_scratch.zip

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