mbalentine

The implications of this are interesting. Are you able to comment on available drive capabilities/limitations to operate in current mode at this update rate? Will there be ODT drive products to create a 'single source' solution based on higher speed eCat?

You may want more details than I am going to offer... 1) Why do you want to do such a thing? 1a) What type of amplifier interface are you using? I would think that a direct PWM such as a Brick would offer the best level of control for the transitions (but I am not that familiar with Ethercat) 2) Can you give some info on the difference of Force Constant and Pole Pitch between the two motors? 3) Obviously you are wanting to point both motors to the same feedback register in the ECT. The setup parameters for each motor will then be determined by the specific motor characteristics. 4) I would think that you do not not want to 'kill' either motor, but rather change between open loop and closed loop mode so that both motors are always active and commutating. I believe this will also eliminate the need for a 'pmatch' command and the delay required for it to execute. 5) You will need to calculate an initial output value for the motor transitioning into closed loop mode. This will need to be based on the output of the motor going out of closed loop and scaled appropriately based on the ratio of force constants. 6) It may be best to maintain a small open loop output on the motor transitioning into open loop mode. Think of it as an assist to the motor in closed loop. This will be more difficult if the load is noisy.

PPMAC is a little more flexible than the conventional looping practiced in traditional PLC hardware from other suppliers. A good overview can be seen in two sections of the May 2019 PPMAC Users Manual: - 'POWER PMAC COMPUTATIONAL FEATURES' [pp 516] opens with a section titled 'Computational Priorities'. This deals with repetitive (looped, sort of) tasks such as motion and plc programs. Page 65 lists tasks based on the various clock interrupts. - 'WRITING C FUNCTIONS AND PROGRAMS IN POWER PMAC' [pp 807] deals with executing compiled C code within PMAC. C code executes much faster than interpreted script and can be executed from a hardware capture interrupt. Danger in hogging too much of the available resources if you do too much, too often. 'Data Gathering' is another option for collecting data (no logic execution), but may not trigger often enough for your needs. Max frequency is Phase clock. See pp 33 in User Manual.

Just a quick FYI on phase direction. The problem you cite should have shown up in the Open Loop Test where the motor is phased forward and the position is displayed graphically. You can also observe your mechanism to see if it is moving in a positive direction. This is the point in commissioning where feedback, phasing, and mechanism direction are confirmed to all be in agreement. Very important to confirm agreement of motor & feedback to prevent a potential runaway condition. (phase algorithms will also fail since the movement is not what the algorithm anticipates) Once the motor & feedback are in agreement, the mechanism direction can be reversed by changing both motor phase AND encoder direction sense. Eric Hotchkiss pointed out a method available in PPMAC of reversing motor phasing without swapping wires here: http://forums.deltatau.com/showthread.php?tid=2928&highlight=phase Note that in these instructions the encoder direction sense is being changed along with motor phase direction. It is assumed these are already in agreement.

http://forums.deltatau.com/showthread.php?tid=842&pid=3169&highlight=biss-c#pid3169 Comment from 2012 regarding Biss-C I think is still relevant. Not in Gate-3, but can be accessed in ACC-84E Unless your Brick has the ACC-84 option, you may need a different feedback (???) Acc-84E manual Biss-C starts on page 125 (unfortunately for Turbo) http://www.deltatau.com/manuals/pdfs/ACC-84E.pdf?id=635787783277365390 Setup for the ACC-84E option on a P-Brick (with ACC-84E option) is covered in the Power PMAC Users Manual beginning page 128

In a recent posting you refer to (I assume same mechanism) needing more motor current, in part due to stiff bearings. This can affect the success of the two step phase finding algorithm. The algorithm looks at rotor (encoder) position and assumes magnetic alignment when a phase is excited, and then validates by checking if the motor moves an appropriate distance when a different phase is excited. If the delta is too big/small, the alignment cannot be trusted and the test fails. Causes are generally twofold: - physical obstruction, stiff mechanism, bias due to gravity. - Magnetic pole irregularities in the motor. This is always present to some degree and can cause random pass/fail results depending on which pole/magnet happens to be in position at start-up. Motor[x].PhasePosSf is used to determine the 'correct' movement of the rotor during phase finding. It may be possible to alter this value during phase finding to loosen up the pass/fail criteria but it must be returned to the proper value. DT should be consulted.

Thank You I should be good on inductance. Still some work to do, but I anticipate 5-15 mH. Is there any meaningful overhead penalty for doing a circle move vs sine calc?

I would like to use a Direct PWM drive as a single phase, variable frequency( 30~250 hz), current controlled supply. First thought is to use a 'virtual axis' with commutation as a brushed DC motor and write a sinusoid function to Motor[x].IaBias from a Motion prog, PLC©, or C. Would using a realtime PLC© have less overhead than a Motion prog? Is this the right overall approach? Any comments on how best to do this and/or considerations to keep in mind? Thank You

Please recall when using the setup software to commission the motor there was a test (Open Loop test) to confirm that the direction sense of feedback matched the physical rotation of the motor. This is very important because if the sense of direction for feedback and motor do not match, your system will be unstable. A stable system uses 'negative' feedback. If the direction sense of either motor or feedback is changed, then the system has 'positive' feedback and becomes unstable. This is why your motor is vibrating - also very possible is a dangerous runaway condition. To change whether you consider cw or ccw as forward (mechanically speaking), you must do two things: 1) Change the physical direction of motor rotation 2) Tell the feedback mathematics that you have done this, so that stability is preserved. To effect #1, swap two of the 3 phase motor wire connections. ABC -> ACB To effect #2, change the value in Gate3[0].chan[2].EncCtrl, as you have already done. Once the correct relationship is established (Open Loop test), never change just one, always change both together. .OR. You can leave the motor wiring and encoder direction definition alone and change the way your software defines forward & reverse. This can be a little confusing because you would be using a negative software command (X-2.34) to move mechanically forward. Same result, but probably better to do it the way you have begun.

Curiosity: If there were three motors configured in this way with 30k PWM, roughly what level of processor utilization (load) would that impose? 465? ARM?

Something I have done before for battery charge and other DC power supply applications (should have mentioned this before) is to use a good old fashioned SCR, brush motor, 4Quadrant, DC drive. - Cheap - Single phase at standard line voltages with fully adjustable output. - Three phase for more $$, less ripple - Line regen. No resistor / no heat / no 'chopper' / 100% regen capacity - Tachometer input can be used as voltage sense on PMAC side of bus filter, allowing fairly tight regulation (0.1-0.25%) - Can use accel/decel settings for controlled power-up & bleed-down of bus. - DIN rail mounting - Example would be a Bardac K680XRi for ~US$800. Fully digital, ~7A @ 0-100vdc. Should be avail in EU, but there are many manufacturers. This is just one example. https://bardac.com/dc-drives/k-series/ - BUT! You still have to add bus filtering. The notching that the SCR's deliver (and to protect against dI/dt faults) will require a series inductor (+R?) followed by R||C. I would be tempted to add a zener in series with the R. - The filtering is pretty simple and could be done on a terminal strip with standard components. - The drive provides a regulated 10vdc output that can be split with a simple voltage divider as a control reference (stability more important than precision) I'd estimate the whole thing at US$ 900-1000 As for the lab supply, I don't think a dead stable bus is that critical. You would be adding a chopper for regen. More important is that variation/ripple be << slower than your current loops in the PMAC. For very high precision, it may matter more than I realize. For the price, the unregulated supply you found with a chopper is worth a try. You can always add a little capacitance if needed. You'd be

Haven't needed to operate anything at 60v myself, and in looking I see that the choices are indeed limited. First off - as someone alluded to already - are you sure the Brick LV does not have a regen facility ???? Big omission in my mind, but given the range of potential bus voltages.... Here's what I would consider: 0) I share your concern regarding a switch mode supply. I wouldn't, unless I could add capacitance, a 'start-up' resistor circuit, and an isolating diode. Even then not my 1st choice. 1) Three phase unregulated supply with enough capacitance to absorb xx% energy with a +yy vdc rise (you have to define the xx% & yy bus voltage for your app). I would say the ripple reduction of a 3 phase supply is worthwhile, but at low voltage & low power, capacitance is pretty cheap. Slew rate of the bus should be many orders of magnitude slower than your servo loops, even with single phase. 2) Since the power supply is unregulated, feeding it from a Constant Voltage Transformer (1% voltage reg) will help. These can be expensive enough that you may want to consider 1 phase supply instead of 3 and add some capacitance. 3) Here's where it gets difficult. Looking for a freestanding regen bus module didn't come up with as much as I would have found 10 years ago. It was more common then. Even more limited for a 60 v bus. I did find this at Automation Direct. Regulates based on differential between supply & bus, across an isolating zener diode. Might be ok with a switcher (??) Provides some bus capacitance. https://www.automationdirect.com/adc/shopping/catalog/motion_control/stepper_systems/power_supplies_and_regen/stp-drva-rc-050?gclid=Cj0KCQjw9JzoBRDjARIsAGcdIDVZTdub9oTACM_fCXuh3UQRTS3kAcxth77_QjBt3Qg8TGBQh8qfSLgaAgKnEALw_wcB Cheap, rated 80v, 50W (100W with external resistor, 800W peak) https://cdn.automationdirect.com/static/manuals/surestepmanual/surestepclamp_datasheet.pdf https://cdn.automationdirect.com/static/manuals/surestepmanual/suresteppower_datasheet.pdf Automation Direct + Delta Tau Is that an oxymoron??? KB Electronics has a DC-DC drive (KBBC) that could be configured in a voltage feedback mode as a bus regulator. Likely would need a small inductance + power resistor so it looks like a motor rather than a resistive short. (dI/dt fault). Only rated at 48v, but with a voltage configuration setting of up to 1.25 rating allows 60v. But you'll need 65 or 70 to allow some capacitive energy storage before dumping. http://acim.nidec.com/drives/kbelectronics/products/variable-speed-dc-drives/battery-dc-to-dc If you have any volume on this KB can be pretty flexible. Relatively cheap, you might even consider one of their AC-DC drives as a regulated supply to avoid the CVT in #2) above. Kinda' a science fair project at this point.....

You have explained your difficulty precisely. If not familiar with the 'Nyquist criteria' check the attached link: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem This is a basic concept of digital signal processing that is universally accepted in applications ranging from A-D conversion to serial communications, including quad encoder interfaces. In general, to digitally sample a signal, the absolute minimum is 2x the fundamental frequency of the sampled signal. I generally prefer 4x for reliability. You are losing your signal integrity at ~fundamental=60% of the sample freq., which roughly agrees with Mr Nyquist's predictions not to exceed 50%. I would say you should not depend on being successful above 50mm/s, and that would be sketchy. Classic clash of speed vs resolution. [Clarification: your system is near the Nyquist limit, my comments are biased by my preference for a safety margin by using 4x margin] At 20mhz you'll need to be sure you have proper termination, very good cable, minimized length, & proper impedance matching to maximize performance.

Thank You for the follow up. Closure is helpful.

I tried to put together an example that is based on your application. It is bare-bones & likely has some mistakes. Hopefully it is good enough to help explain the concept of using the Kinematic approach. Perhaps this will help you understand the explanation and example in the User Manual and between the two it will make sense. Being only one axis, your application is a great way to learn this method. Best regards and hope your application is a great success. Kinematics How To.pdf

This has been identified as a design flaw within the Gate3 chip. An uncommutated analog motor operating around zero will occasionally fiip sign/magnitude, that is a small negative number may be clocked out as a large positive number, and converse. There are workarounds. Is there any documentation or comments on what the workaround might be?

Where is the 4.x manual?

I have some program idea about option #3,in every loop calculate the next position.But I not sure how to program option #1 and #2,could you give me some example?Thanks. Strongly do not recommend option #3. This was the solution 25+ years ago, but not today. If you will use the capabilities built in to PMAC all of the non-linearities become transparent and all you do in your program is tell the axis (NOT the actuator) what you want it to do. PMAC will control the actuator so that you don't have to. Think of it this way: Any solution will require you to develop the trigonometry that defines the relationship between the actuator and axis. Using option #1 makes this totally transparent to your programs. Just to be complete (I hesitate because I don't want to confuse you), there is an option #4. This is also a 'not recommended' method that would have limited stability. You could use dual feedback with a second encoder mounted directly on the axis. Your program commands will be relative to the 'load' encoder. This is how precision machine tools gain accuracy by using a secondary encoder directly on the table rather than inferring position from the motor. In your case though, the discrepancies will be many orders of magnitude greater and would affect stability. Tuning would need to be very conservative and thus have limited responsiveness. Learn how to do option #1. This is the best way and takes advantage of the excellent capabilities of PMAC. The Kinematics section has a better explanation and examples than I could do here. The manuals are very good.

It would appear that your tuning (PID) parameters are somewhat arbitrary. These should be arrived at by following the tuning procedure as outlined in the Users Manual and software. I generally skip the auto tune and tune manually (using the tools provided). It works very well. Other people use the auto tune as a starting point before doing a manual tune. Properly done, I would compare the results against any other system.

Option 1) This is exactly why PMAC has kinematic axis definitions available. Look in the User Manual for the section dealing with forward and inverse kinematics. As you already understand (by asking the question), the relationship is not linear and will depend on the actual position of the mechanism at any given point in time. So the task is to develop a non-linear relationship that will define the actuator position as a function of the desired axis position. This allows you to program desired axis motion and allow PMAC to transform into actuator motion. Equally important is a relationship that will define the axis in terms of known actuator position. This allows PMAC to properly initialize the axis by reading the actuator position. For a single axis as you describe, this should be fairly easy. Option 2) If this is a simple, single axis task you could use a linearization table (cam function) to 'correct' for the geometry changes through the range of motion. Not as good as #1 in my opinion, but with cubic interpolation turned on will do the job smoothly. Option 3) Again, if the application is simple.... You could even program your motion into a loop that solves the trig relationship each iteration. The 'While Loop' would need to execute fairly often. This is essentially a crude & limited way of doing #1, and not very good. Option #1 allows you to utilize all of PMAC's built in capabilities. With #3 method, your motion program will become more complex, and there will be greater error.

Would it make any difference what options are selected when running a backup?? I recall there are a few to choose from.... ie - quite possible to run a 'backup' that is not sufficient to make a full restoration.

Try the Power PMAC User Manual - SYNCHRONIZING POWER PMAC TO EXTERNAL EVENTS In the manual dated Oct 2017 I think what you want begins on pp 781

I would do the axis duplication in the editor by just copying all the Ivars and then do a block search & replace to update the numbers. Pretty easy peezy. To get started, you can use the Backup utility to make a backup file of your project (or a virgin PMAC, that is $$$*** then save & run Backup). This creates a text file that you can edit for your application, then download from within Pwin32. Hint: You can leave all the math in place for various assignment statements like axis definitions rather than a single number. Then you can readily see where the number comes from - PMAC will do the math at download. ex: #3->(8000*4*25/17)X or M1877=(477.316*22) I generally would break a project into 2(or 3) text files, one for configuration containing motor def, coordinate sys, userbuffer, Ivars, Mvar definitions, assignments, ModBus, etc. Be careful here as the order of some declarations matters. Again, the backup utility gives an excellent template to start from with things in their correct order where it matters. The other file(s) would have PLC, PLCC, & Motion programs. I use a 3rd party editor customized for PMAC language with column mode, Reg Expressions, custom macro's & file compare. PMAC's memory map is highly structured so being able to do structured editing can be very useful. Works fine to have files open in editor simultaneously while using Pwin32 for all the realtime PMAC stuff and to download the same files open in the editor. Edit - Save - Download, and I have a set of project files that I am 100% confident in. For initial configuration I would sometimes resort to copy n paste from the PMAC screens into my editor files, so you may not think this is all that slick.

yes on the ODT It may take a while but once you get a good understanding of the subsystems, the bigger picture will come together like an avalanche.

There is a wealth of info like this from ODT that will truly give you an education in motion control from the best technical people around. Having some of the very best expertise in motion, the manuals and literature are generally thorough yet readable, not an easy thing to do.