mbalentine

Not exactly The 80v you refer to is the DC Bus voltage for your motors, correct? The current sensors read phase current and output a DC voltage signal proportional to the current. They are not concerned with motor voltage at all. I looked briefly and didn't find what I was looking for, but lets just say the output of the current sensor is +-10v (I may be wrong, perhaps it is +-12 or 15 or ???). The gain of the sensor would then be 10v/33.85A. The voltage output of the sensor is then digitized and sent as current feedback to the control loops. Note that what this means is that the control loops don't care what the actual current is; they only care where it is in the range of -max|0|max+. Certainly the output transistors and heat sink care about actual amperage though :-) But I have to ask why you wish to manually make this calculation? It is generally considered optimum to use the tuning tools and tune this by hand. The manual calc will give a theoretical result that could be considered a starting point. It can be argued that this is one area where ODT allows the user to exceed other systems. Most suppliers use a set of 'safe' current loop parameters in a 'one size fits all' approach. ODT provides the means to truly optimize the torque response of the motor-amplifier-cable-etc combination. That said, I find the ODT technical manuals are excellent in providing the theory necessary to better understand their products. So good luck with your project, you're using the best controls available.

If you are asking about trig functions, then yes they are based on a 2048 point interpolated look-up table. Not sure if the lookup is linear or 3rd order spline but I believe it is spline. I recall seeing a detailed paper on this subject many years back when PPMAC was first released, comparing it against the 256 point table in PMAC. Not sure if that literature is still available. I do not know the internal code for the current loops but the algorithm may call the trig functions therefore making use of the interpolation of the lookup table. It is also possible that interpolation is not used at all and the 'raw' 2*pi/2048 resolution is considered acceptable while offering faster results for current loop closure. If you are wanting to write your own algorithm, this is a trade off to be considered. ex: Sin(2*pi/2048) = .003068 Does a commutation calculation need to be better than that? Perhaps 2048 was chosen for this reason (???) Commutation is not based on position error, rather it is a function of absolute position (electrical position). While the magnitude of current command is driven (in part) by position error, the current loops themselves are not a function of position error. Simple command minus measured feedback from amplifier output phase sensors.

This is a specification of the current sensor used as the feedback element in the Current Loops, typically two of three phases on the amplifier output. For instance, an ODT GPH-052 amplifier shows 16.26 amps (dc) full scale w/ 12bits resolution. This value is obtained from the amplifier documentation. It is implied by your question that you are closing the current loops in PPMAC - using an ODT amplifier - GPH/L, or Brick, or Copley (?) with Direct PWM interface. If you are using a 'current mode' amplifier (eCat, analog +-10v, Yaskawa, etc) then the current command comes from PPMAC but the loop is closed in the amplifier.

http://www.deltatau.com/Manuals/Default.aspx Manuals are also categorized here but I usually just scroll to the one I need when I already know the name/acc# The PPMAC Users Manual on File Depot downloads fine for me. http://forums.deltatau.com/filedepot/ [FILE REMOVED]

Check out 'Geo PMAC Drive User Manual' beginning on pp88 (appendix A), dated Apr 28, 2016. The correct Molex part #'s are listed. Drawings follow as documentation of the pre-made DT connector kits, but the Molex #'s are included also. .... I see some issues here as well. But - I can say I have used the kit-1A #'s to buy Molex for GPH-052 drives, and your GPL-102 is listed as using the same kit. The 1A kit does spec the AC and Motor connectors as different. IF you were asking about a GPH-102 drive (but you are not), that calls for a 2A kit which does call for the same connector on AC and motor connections. Maybe this is wrong, but I have never used a GPH-102. The 2A kit is used for a GPH-152 (another drive I have used) and specs same connector for AC and motor, which I recall is in fact the case. You are right, they should be different, and on your GPL-102, using the 1A call out, they are. Confused yet?? As an aside - since you mention drives dating back to 2006, you might want to review the start-up and shut down procedures as outlined in the latest manual. There were many reliability issues, perhaps more acute with the 480v (GPH) drives. Lots of broken hearts. ^^^^^^^^^^^^^^^ Hey ODT, How about a separate heading for drives related topics ?? I hear there will be renewed interest soon....(?)

Your intention might be that both axes move together in a continuous manner? If so, try placing the X & Y move command together on the same line while(1) { x(AMPL * sin(MyXArg))Y(AMPL * sin(MyYArg)) //in radians ... } It looks like the X axis is moving, stopping, moving, stopping (sort of) with the spline mode blending the moves together a bit so that you do not come to a complete stop. There are (pi)/0.05 = ~63 ripple cycles per pi radians of the fundamental in the velocity chart, so this may agree. It might be interesting to leave as-is but change the move mode to Linear. I would anticipate minor amplitude would go to zero (DC), but the ripple would stay at the same frequency and amplitude over the same fundamental period, giving a sine wave envelope of same freq you are now seeing. Also just for fun: It looks like your axis has plenty of bandwidth and is executing the rather high acceleration required to produce the ripple as seen. You could try limiting the allowable accel/decel and see to what extent that will filter out the ripple (allow plenty of following error). Not that it would be a solution, just to see the masking effect of limited bandwidth. With commands on same line, I would think you'll see a smooth sine position and velocity, at 2x frequency.(?) Should chart at twice the frequency currently seen. This is because the axes are executing sequentially rather than simultaneously. Essentially, the individual axis are executing every 100 ms because the spline(50) statement is causing a 50ms spline for each axis sequentially. (100ms * ~63 ripple cycles =2(pi) seconds on the chart) From the chart, you have [(pi) rad]/[2(pi)sec]/ = 0.5 rad/sec; and in software [0.050]rad/[50ms]/ =1.0 rad/sec (intended), so the software would seem to be executing axis coordinates only half as fast as intended - due to executing X&Y sequentially. Not shown but assume axis definitions are straight forward like: #1->(nnnnnnn)X #2->(kkkkkkkk)Y

Can you comment on the current thruput comparison of Acontis vs Etherlab? I understand that you have been working to improve speed while retaining ease of use with Acontis.

Thank you. You described everything correctly. I will clarify my question a little. Is it possible to add a correction to the W axis using such an expression? tsel1; // Transform 1 selected as active Tdet= tinit(1); // Initialize Transform 1 Tdata[1].Bias[6] = XdOffset; // Set X offset term Tdata[1].Bias[7] = YdOffset;// Set Y offset term Tdata[1].Bias[8] = ZdOffset; Tdata[1].Bias[5]=WlOffset; // Is this expression true? Thanks in advance OK, A picture is SO valuable :-) 1) Tdata[1].Bias[5]=WlOffset; // Is this expression true? -- Well, yes, but not in the context I believe you are asking. Lets say you define: #5->2000W+28 This would write kw=2000 and dw=28 so the answer to your question is yes But will this value interact with the XYZ T-matrix? NO Referring to the July 2016 Users Manual: the axis def matrix on pp 466 and the T-matrix on pp484. Note how the ka, kb, kc axes are single elements on the diagonal, but the kx, ky, kz elements are surrounded by dot products kxy, kyz, kzx, etc. PMAC will treat these 3x3 sub matrices as a 'self contained' transformation. How? That is where the IJK vector comes into use. Note that I, J, K (II, JJ, KK) are skipped over in the axis definitions. They are reserved to define rotation of the XYZ coordinate frame. As you already know, the IJK vector is used to define the rotation of the XYZ T-matrix. This is hard coded into PMAC firmware. It is so common to do a rotation in XYZ space that this very basic kinematic transform is built in. Your machine is an XYZ machine. You can indeed use the built in XYZ T-matrix functionality. And an offset in d5 will apply to the W axis. (Easiest done in the axis def statement) Lets say your machine has 5000 cts/mm with 200mm of travel in W and 2000 cnts/mm with 1000mm travel in Z, but you want to include the W axis as part of the XYZ T-matrix so you can take advantage of basic CNC coordinate rotations and circular interpolation, etc. over the full travel capacity in Z. I think(?) you could just define motors #4->(2000*1000/1200)Z+d4 //assume #4 is driving axis Z #5->(5000*200/1200)Z+d5 //assume #5 is driving axis W This will linearly proportion any Z axis command over the two motors, but is probably too simplistic a solution for real life. You probably have significant mechanical constraints to consider. Another approach would be to do something like: #4->2000DD+d12 #5->5000EE+d13 you will need to use a dummy or phantom axis for Z, and implement some algorithm to distribute the Z command over the two axis. See the document on spectral decomposition from Kurt for one idea when two axes of significantly different bandwidths complement each other. Very. Cool. (Also a Youtube video). ODT - please correct my omissions, lack of detail, and outright errors.

I believe he is asking: A) How to add a 4th (rotary) axis B) How to accommodate a compound (or redundant) Z axis A) For the rotary axis, isn't this usually handled in a CAM software package? (Suitable POST processor assumed) Otherwise the CNC machine can be treated as a 4 DOF kinematic machine, which is essentially what the CAM software does. B) I suspect his machine has a 'Major' & 'minor' Z axis arrangement where the W axis might move the entire head in the Z direction and the (z) axis extends & retracts the spindle (also in the Z direction) so that "Z" = W + (z). Could this be handled as: (???) 1) Make Z a phantom axis with feedback Z=W+(z) so that the T-matrix remains intact. Phantom not controlling, no cascade - just a buffer between the machine Z command and two other active axes such as DD & EE. 2) An algorithm to distribute the Z motion command over the two axes. The W axis might be slower than the (z), but who knows. (spectral decomposition comes to mind, linear proportioning would be simplest.) Or perhaps I am completely missing his point.... It has happened before. Maybe all he wants to do is add some screen art.

Thank You

hi mbalentine, 1) Just because plc0 runs faster than background plcs or cplcs. 2) I just want to show the outline or the method of my test, not the whole project. I have run it successfully. 3) I'm sorry but I think you may have misunderstood my needs. I know there are many methods to get such sine trajectory, but what more important is to keep resultant velocity rate constant, which means, stays the same along the path. Have you ever do applications like this? Yes, I have. Based on the graphs you posted, look for a possible speed limitation on the X axis. It appears you are following your desired path with constant velocity except where Vx is near maximum. In other words, can Vx >= F ? Also, is your data density so high that point to point increment per servo interrupt in this region will not allow F to be achieved? (not sure how PPMAC would respond to this conflict, but I think it would give priority to the path, thus slowing down) In your PLC0 software the 'dt' calculated value is minimum in the area of issue so the question is whether (dt/servo) Does the total error get smaller if F is reduced? Is the error affected by values in TA or TS? Just for fun, in western calculus notation dt is commonly used for delta time or the time derivative. The name 'Delta Tau' is derived from this as tau (greek) is commonly used for a repeated time increment as in a servo interrupt. Best of Luck.

Quick review of your code raises some questions: 1) Why are you using PLC 0 to pre-process the data? 2) The code as written fails the comparison test on the first pass and exits PLC 0 immediately dt=sqrt(pow(pxt-Px(intt),2)+pow(pyt-Py(intt),2)) = 17x10^-6 if((dt-ds)>0 && (dt_last-ds)<=0) //ds=0.05 (dt-ds) = -0.049983 ;fail comparison on first pass No data is loaded into the arrays. These lines of code never execute. Px(intt)=pxt; Py(intt)=pyt; Apparently there is junk data in the memory, which you then try to use as an X Y data path for motion in prog 7 Unfortunately, the code is not fulfilling your intentions. It is possible for your strategy to work, but you will need to refine your code a bit. I would say that this is not really the best way to use PPMAC, but I do not know your objectives. My advice: 1) try the code outline shown in previous comments. This would be fully executed in a motion prog with no PLC processing required. Drawback is that it executes in Linear mode so there will be some granularity to it that reduces as you make the increments smaller. It is essentially the same strategy you show in your code, but simpler. Each X Y point is calculated as needed instead of filling arrays ahead of time. 2) Use Circle mode to generate a true sin function (PPMAC interpolates a table for trig functions) by setting up a phantom or dummy axis. Again, simpler and the data points are calculated as needed instead of pre-processed. 3) Use a cam table to drive the Y axis from the X axis. The table will use 3rd order spline calculations between points, so you should get very good results with as few as maybe 21 points - easy to add more if you find fidelity is not sufficient. After thinking about it, this might be the easiest and best solution. You can fill in the cam table either manually or by calculation. You only need to fill data for one cycle as the table will wrap onto itself. (This is not typically what PLC0 should be used for, use a non-synchronous PLC for this and test or set a flag to know it is complete if necessary) 4) PPMAC either goes 'point to point' in which case you have to calculate each point including desired velocity & acceleration (why??, usually for external CAM program interface), or you generate 'Way Points' in a program and allow PPMAC to use its internal algorithms to interpolate points for each servo interrupt. This is where PPMAC's power resides. It has one of, if not the, best trajectory generator anywhere. Take the time to understand how to use its' capabilities and it will do virtually anything you can imagine. 5) Note that both 2) & 3) are interpolating a sin table. PPMAC uses a 2048 entry table and interpolates using 3rd order spline for all trig functions. Using the cam approach of #3, you are essentially interpolating a smaller table, so accuracy will vary.

Hi Steve, 1. I tried to make a sine trajectory move like y=a*sin(w*x+b), not just one motor move; 2. I tried to cut the wave into approximate equal length segment and get the points, then throw them into a linear loop move, in feedrate mode. But however big F is given, speed crashes occured at peak and trough of the wave. 3. What's more, speed should be limited deeply by length of segments and servo motor performance. How is CNC keep the speed of head when machining irregular curve? 1) You'll need to have a separate relationship for X & Y X(P22) Y(P188) ;P22 & P188 are dummy variables 2) Your system must be physically capable of following the frequency and amplitude of the programmed move. - Torque - Inertia - accel & vel limits - Physical range of motion - Properly tuned 3) Allow PPMAC trajectory generator to check and provide system limits in real time. Basic approach is to use FRAX and F commands. If the system cannot follow the prescribed velocity of the F command, then PPMAC can slow both axis so path is preserved. Expanding on Steves code example: P1=1 P2=0 P3=0 P4=1 P5=32.6 ;any number for desired feedrate LINEAR ABS FRAX(X,Y) While (P2<360) X(P3+P1*Cos(P2)) Y(P2) F(P5) P2=P2+P4 EndWhile Don't use this code as-is, it only illustrates the concept. For instance, the Y axis will move 360 linear units. First move will be to X(P3+P1) Y0 from wherever you start. You should see the velocity along the sine-wave maintain at constant 32.6 units/sec while the X&Y axis coordinate to exactly follow a sin path. Probably good advice to make P4 smaller so the path is calculated more frequently. Note also that Cutter Radius Comp (when used) will maintain the constant velocity F at the cutting edge, not the spindle center. Sounds like you're doing a CNC type application - you'll find PPMAC has a very capable set of internal routines to make your life easier. These capabilities have been very well thought out over 20+ years. For irregular curves the same thing will happen. PPMAC will coordinate axis so that path is followed at the F velocity (actually the path at the tangent edge of the cutting tool). A problem can occur when going around a small radius in the path with Cutter Radius Compensation turned on. This can cause the spindle center to require very high accelerations and/or velocity that may exceed machine capability. If this happens, PPMAC may not be able to stay on path. This is what 'Look Ahead' is for - PPMAC will identify this situation before it gets to that part of the path and slow down enough so that path fidelity can be maintained. Another way to do this: In the above example PPMAC is really making straight lime moves between 'way points' on an imaginary sin (cos) path. By making P4 small, this can for all intents and purposes be a true sine or cosine. But there is another method to use PPMAC for this. If you define a third axis (D) as a dummy (no electronics or motor), you can use CIRCLE mode to scribe a circle using the X and D axis while commanding the Y axis similar to the example above. The X axis will move in a Sine while the dummy D axis moves in a Cosine. Still use FRAX(X,Y) and F(). Do not include D in the FRAX statement.

Hi Steve, 1. I tried to make a sine trajectory move like y=a*sin(w*x+b), not just one motor move; 2. I tried to cut the wave into approximate equal length segment and get the points, then throw them into a linear loop move, in feedrate mode. But however big F is given, speed crashes occured at peak and trough of the wave. 3. What's more, speed should be limited deeply by length of segments and servo motor performance. How is CNC keep the speed of head when machining irregular curve? OK, so the X and Y motor commands must be separated rather than in one combined statement. Building off Steve's example: P1=1 P2=0 P3=0 P4=1 P5=38.521 ; vector feedrate for all axis listed in FRAX ABS FRAX (X,Y) While (P2<360) X(P3+P1*Cos(P2)) Y=P2 F(P5) P2=P2+P4 EndWhile Not great code, but should illustrate the basic concept. The X & Y move commands define the incremental relationship between the axis, while the FRAX command says to include the X&Y axis in the vector feedrate calculation, and the F command establishes the desired vector feedrate velocity. You can also use circular interpolation with a phantom axis to generate a sin or cos motion. You define an 'unused' axis (ex 'D') and command a circle using X & D axis while moving Y with a separate command. Or you could use a linearization table as a cam. Essentially same approach as above, but with PPMAC there are often many ways to do the same thing. Depending on your application, you may find one method to be preferred over another.

See the Feedrate command (F).

Would it be possible to report the evaluation and resolution of this problem here on the Forum for all to see? This looks like it would be interesting to me. Thank You

Great idea. Even though I am not an NC user, it is still informative to follow the product discussion and see how NC specific solutions are implemented in (P)PMAC. Would you consider opening a thread for ODT drives / amplifiers? That would be a good way to keep the ODT atmosphere abreast of the drive product family, assess the 'Buzz Level', and to expand awareness of new ODT and/or Omron drive products suitable for PPMAC.

It is my understanding that there are two different vendors used by DT for EtherCat stack implementation, Acontis & EtherLab. The 465 uses EtherLab and the CK3E uses Acontis. You indirectly noted this difference in your original post when you referred to the EtherCat functionality being better in the CK3E - unfortunately, it comes at a cost. The EtherLab implementation is fast(er) but requires more involvement to configure network communications. Acontis is a more 'user friendly' implementation, but has more run-time overhead. Perhaps this might explain the thruput difference you are seeing? Also, are you operating your amplifiers in Synchronous Position, Velocity, or Torque? Position will work best with slower updates, Torque mode allows all tuning, etc to be controlled within PPMAC (but requires faster updates) Attached is a document that I have found very helpful. Disclaimer: I've done a fair amount of homework into using EtherCat as a drive interface, but have not yet crossed that line. EtherCAT_Mode_Summary.pdf

We make it so hard for ourselves and customers.... and we earn the reputation that DT is very hard to work with.... ------------------------------------------------------------- Did I just get a breath of fresh air...?

I agree on the issue of tuning the various drives, some of them are really a pain compared to doing it at the DT level. Quick & precise. Much prefer to operate the drive in current mode. I'm tempted to fall back to a +-10v analog. (I can hear the "but it's not digital" chorus already)

Useful comparison, Thank You. - Do you see this as something that will continue to develop/improve over time? - Have read a paper you published that cautions the e-Cat standard only provides for a +-1000 count cyclical torque command. Is this limitation strictly observed, or do manuf's generally acommodate higher resolution? - In the case of a drive that could handle cyclical torque at 8k, is there an axis count where PPMAC/e-Cat becomes the limiting factor as the e-Cat Master?

I agree in principle, assuming you are referring to an e-Cat interface. I do have concern with closing the torque loop at 'only' 4k + transport delays. 1) Have you been able to close faster than 4k (8k)? 2) Can you offer further comments on your experience? Thank You

Difficult to understand your application description. Are you saying that you are moving a target in 3 dimensions to track position information from a sensor? If so, - what type of sensor - bandwidth of sensor * update frequency * lag time of measurement - how much position lag is permissible - what is the bandwidth of the device that the sensor is tracking Or maybe my interpretation of your question is wrong.

Thank You for posting this.

For clarification: Are you using the standard PMAC servo control algorithm, and just wanting to test run a simple motion program to confirm that the motion program is executing? - or - Are you replacing the standard Delta Tau servo algorithm with your own custom algorithm written in C and cross compiled for PMAC?