steveneads

Actually it's not directly related to my last post - that was for a different device. I am very well aware of the typical use of cascade control for force loops etc. I have been using this approach in our products for more than 15 years. However, it is also possible to use the PID structure to pass a scaled signal through from the command to the output by ensuring that the feedback is held at zero (so that the following error = the command) and that the only gain is the P term. The servo out is then simply a scaled version of the input. The only reason for doing this is to get around the standard DT system architecture for a weird application such as mine!

Hi This problem is rather awkward to describe, but here goes... I have what's probably an unusual application where I have 2 motion programs driving a single physical motor. One program sends its commands direct to the PID (#7) that actually drives the motor, the other sends its commands to another PID (#4) which cascades its output to PID#7 via a 0D compensation table, that writes to the CompDesPos input of #7. PID#4 has no feedback and only a proportional gain of 1, and the output that gets copied from it to #7 is scaled by the compensation table. The compensation table runs between PID#4 and PID#7 to minimise delays. This layout does what I need and works. Since seeing that you have the new pCascadeCmd method, I've tried converting my code to use this. I've removed the compensation table, set #4 to cascade to the CompDesPos input of #7 and set the proportional gain of #4 to the scale factor that was previously in the compensation table. It "sort of" works - but not quite right! I can't figure out what's really going on, but my motion programs don't quite work in the way that they used to. Both programs are started together, and the motion program that drives #4 waits in a while loop doing zero moves whilst #7 attempts to move the motor to zero position. #4 is then allowed to exit its while loop and generate a required motion. The problem is that the move to zero now sometimes does not end up at the correct position. It seems like some sort of timing issue that is resulting in an offset somewhere being wrong. Is there a subtle difference in the way the pCascade command executes in comparison with my 0D compensation table method? I've given up with it for now and reverted to my old method - but I'd like to understand what the problem really is!

I was referencing your manual 050-PRPMAC-0S0 dated April 11, 2016 - page 1416. Page 1295 in this manual refers to "Mathematical Feature Specification". Is this manual now out of date?

We have had some difficulty with Motor[x].PhasePosSf when converting UMAC code to PPMAC. It seems that the description under Ixx70 on p1416 of the PPMAC Reference Manual "Set PhasePosSf = 256/(Ixx71/Ixx70) for compatible operation" is incorrect. This yields: 256 * commutation cycles per rev / counts per rev I believe that the description for Motor[x].PhasePosSf (p464) is correct. This yields: 2048 * commutation cycles per rev / (256 * counts per rev) Clearly there's a scaling mix up.

How does the scheduling work if some motors have an extended servo update period (using Motor[x].Stime)? For instance, if I have several motors which are closing their loops on alternate servo-cycles, are they all closed on the same servo-cycle as each other or can they be scheduled to do their calculations on different cycles to each other, or does it depend upon the timing of loop closure? Thanks Steve

Hi mbalentine, thanks for you comments. However, using the handwheel (master) input is not really what I want to do. I want to use the commanded position to another motor, not its actual position - which is subject to the accuracy and delays of the PID control. Also, I don't want the additional delay caused by processing a signal via the encoder conversion table. I am still hoping that there's a simple answer to my initial question!

I'd like to use something like the gantry following (Motor[x].ServoCtrl=8) so that I can get 2 motors to use the same command signal. However, I want one motor's command to be a scaled version of the primary motor's command - in my case 70%. I have a messy solution, but is there an easy way to achieve this? There doesn't seem to be a variable to scale the input to the secondary motor in a simple way. Thanks Steve

Hi Steve I tried your suggestion, but as far as I could see, the listing looks correct. However, the two versions of code don't work in the same way. Seems a little concerning to me! Steve

Thanks, Motor[x].pAbsPos set up pointing to User Shared Memory did what I wanted.

I've just been debugging a PLC that wasn't working as I expected. I had the lines: brEndTime = Sys.Time + 0.5; while (Sys.Time < brEndTime) {brState = 631;} //wait for 0.5 sec This code did not appear to wait in the while loop at all. Adding carriage returns as below fixed the problem: brEndTime = Sys.Time + 0.5; while (Sys.Time < brEndTime) { brState = 631; } Is this to be expected? Thanks Steve

Hi I'm currently converting some UMAC code to PPMAC. I have a motor using a potentiometer for feedback. I currently use Ix10 and Ix95 to specify the feedback and I then use the "$*" command in a PLC with a value in Ix26 to set the offset I need. What's the right way to do this in PPMAC? Thanks Steve

Hi I've been using the 0D compensation table method for cascading servo-loops. Although it works fine, it's a bit clunky if you have multiple cascades because of the limitation of having to select one place in the sequence of closing the loops for all the compensation tables to reside. I've noted that you have now added the Motor[x].pCascadeCmd which looks to be a nicer method to use. However, in my 0D compensation tables, I've used the scale factor CompTable.Sf[j] parameter. Is there an equivalent to this for the new method? Thanks Steve

Thanks.

Hi Greg Thanks for clarifying that. Incidentally, is there now a buffered program command for use in PLCs to replace phase finding search commands? Such as: cmd "#7$"; I didn't spot one in the manual. Steve

Hi, Can someone clarify the subtleties of the timing of command execution when commands are issued from a PLC? For instance, in my old UMAC code, if I wanted to issue a command to jog or home an axis I would use something like: COMMAND"#1HOME" etc. Since this is executed as if it were an ASCII command from the terminal, I would then often use a timer to hold the PLC for a while to give time for the command to start execution etc. before moving on in the code. When I first translated my code to PPMAC, I just swapped the syntax to: cmd "#1HOME"; This seems to work fine, but can you explain how (if at all) execution is affected by using the new method of changing the line to: home 1; Why do you now have 2 ways of doing this? Does it make any change to the timing or priorities? Thanks Steve

OK, thanks for the help.

Could someone clarify what the value of a P variable (global) is on power up? In UMAC it was whatever had been saved in flash. Is it simply a random undefined value unless it has explicitly set in a file such as global definitions.pmh or PLC 1? I've had some issues where "nan" and "inf" have appeared in globals, and I suspect that it's because I've not initialised everything that I need to at power up. If I do need to make sure that key variables are explicitly initialised, is there an easy way to do this for arrays, so that I don't need to use a loop or add loads of lines, ie something like: global Xvalue(100) = 0; Maybe it's in the manual somewhere - but I didn't spot it! Thanks Steve

OK, thanks for your help - the DAC bias seems to do what I need.

I'm currently trying to convert some existing PMAC code to PPMAC and have come across a feature that I've previously used that I can't find in the PPMAC manual. In PMAC I have an M variable pointing to X:$00022E,8,16,s: the "#4 PID internal filter result". In my application I write to this directly from a PLCC when I need to generate a current in the motor at a time when it's open loop. I need to do the same in PPMAC from the rtiplc code. How do I do this? There's no notes in the equivalent section in the PPMAC ref manual. Thanks Steve

OK, thank you for clarifying that. I agree that it needs to be made clear in the manuals.

Is there any chance of some response from DT on this?

I've been struggling with an issue that's been generating large spurious commands to a motor. I have a motion program running in spline mode. It runs with a short move time (5 milliseconds), set up as follows: spline (brMoveTime) spline (brMoveTime) spline (brMoveTime); When the desired motion is complete, the code switches to linear mode using the following lines: linear //revert to standard move mode tm (brMoveTime); //; set move time ta (brMoveTime); ts (0); A general function is then called to move the motor back to zero in linear mode: linear; //just in case! tm (stepTimeB); // set move time ta (1000 * brVel / pmBrMaxAccel); ts (0); brPosition = 0; //set current commanded position W(brPosition) (The move time is calculated depending upon the size of the offset to be removed). Using the code above, the commanded position (Motor[7].DesPos) can be seen to move to zero in the expected way, but then it simply blows up and goes to a huge negative value. I've spent a considerable amount of time examining my code and found nothing obvious (to me) wrong. Eventually, on a hunch and thinking back to similar issues with UMAC, I added a "dwell 0" before the linear command (ie to separate the spline mode moves from the linear mode moves. This has fixed the problem! Why? It seems pretty unsafe to me. I've never spotted anything in the manuals which says that you need to employ tricks like this when changing the mode - but maybe I've missed something?

Thanks for doing this, I've fixed my current problem - but I'm sure this change will be useful at some point in the future. Steve

I'm struggling to debug a C from script code issue that hard-watchdogs PPMAC. The problem is made harder to find because all the items in the IDE watch window are set to zero when the watchdog occurs - so it's hard to add debug that useful. Is there anyway that I can change this behaviour? If not can you? It would be very helpful to keep that last values read displayed. Steve

Yes, we have a number of background C programs and a CPLC which is started by PLC 1 which also runs on power up. There are no MACRO-related commands.