andyf

That did the trick. Thanks Curt!

Can someone please explain why L0 and L3 get overwritten when the following motion program is executed. There is nothing else running on my system nor any other active ssh connections: open prog 1 L0=0 L3=3 send 0 "L0 before home %d", L0 home3 send 0 "L0 after home: %d", L0 dwell 1000 send 0 "L3 before jog: %d", L3 jog 3 : 1024 send 0 "L3 after jog: %d", L3 close Output: -0: L0 before home 0 -0: L0 after home: 1 -0: L3 before jog: 0 -0: L3 after jog: 1024

There are no PLCs running in the system. Did you try running the same program on your end. I am seeing the same thing occur to the L0 variable after executing a "home" command in the program.

I was able to reproduce the problem using the following simple program: open prog 1 L3=3 home3 // Start at position 0 Motor[3].MasterCtrl=0 Motor[3].pMasterEnc=EncTable[4].a Motor[3].MasterPosSf=0.256 Motor[3].SlewMasterPosSf=0 Motor[3].MasterMaxSpeed=20 Motor[3].MasterMaxAccel=0.001 Motor[3].MasterCtrl=1 dwell5000 send0"L3 is: %d", L3 jog3:1024 send0"L3 is: %d", L3 Motor[3].MasterCtrl=0 close Output: -0: L3 is: 0 -0: L3 is: 43299

BTW, I modified my program to not use L3 at all, and now it works as expected. Please let me know if you are able to reproduce this issue with the L3 variable.

Steve, after debugging a bit, I found something very interesting. In the code below, L0, L1, and L2 hold flags, L3 to hold the motor number, and L13 is the offset to apply. When the code is executed, the value of L3 is changed from the coordinate system number to the motor position! Then in the rest of my program when I try to use L3 in statements such as Motor[L3].PosErr, I get nan. What is going on? send0"L vars %d %d %d %d %u",L0, L1, L2, L3, L13 jog3:(L13) pmatch // problem still occurs even without pmatch send0"L vars %d %d %d %d %u",L0,L1,L2,L3,L13 Output: L vars 1 0 0 3 2372 L vars 1 0 0 52390 2372

Thanks Steve. I have tried using jogx:offset when in normal mode, and it seems to hose the motion program. It appears that the correction is made, but after that the looping in my program does not work. I also noticed that reading status like Motor[x].PosErr returns nan after this. Is it not OK to use jogx:offset in this scenario? In normal mode I also tried using inc move mode and issuing an X[offset]. This prevents the motion program from getting hosed, but the motion response is strange. In one case an incremental move causes the motor change direction, move in the opposite direction very slowly, and then continue forward again at original speed. In another case an incremental move causes the motor to slow down for a while, then speed back up to original speed. Note that I do have speed and acceleration limiting in place.

Thanks Curt!

I have a slave motor following a master using position following. I need to correct for an offset between the two, and thus I am calculating that offset after a position capture, and issuing an incremental jog to correct. So far, I have been doing this in normal mode (MasterCtrl=1), using a jogx:offset amount. However, after reading the manual, it seems using "offset" mode (MasterCtrl=3) may be a better approach. Unfortunately, I cannot get the offset correction to work when using offset mode. 1) Why would offset mode be better than normal mode for this use case? Is one more accurate in applying the offset to achieve position lock? 2) When in offset mode, should I use jogx:offset or x=desired position to make the correction? In my tests, the former does not seem to work. 3) When using offset mode, if I am to use x=desired position, I need to calculate: desired position = reference position + my offset. How do I get the reference position?

The manual states that on an type 3 ASIC (i.e. ACC24E3) setting the CompA and CompB registers to the same value will cause the output to not toggle. However, I am seeing different with my setup, in which CompA=0, CompB=0, CompAdd=0, and my PhaseCapt at 0. In this scenario I still see the Equ/EquOut toggling back and forth when the servo loop is closed.

Yes, should our PPMAC card be replaced, we are interested in loading a project onto the new card without having to use the IDE.

I want to load project files (global includes, plcs, programs) to the Delta Tau without using the IDE. 1) Is there a command line utility on the PPMAC that I can run to load the entire project once the files are transferred there? OR 2) Does each file have to be loaded individually? Is there a reference for which command line program is used to load which file types (i.e. gpascii for plcs and motion programs)?

I have a running motion program that is looping and reading values from local memory. If another gpascii connection updates one of those variables, will the operation be atomic? I want to be sure the running program will not read only part of the value being written by the other connection.

Looks like I have a working solution now. Here is what I did... 1) The timing card is always generating the same 32KHz signal which is fed into an open encoder channel on Acc24E3. Another pin of the timing card is connected to the user flag of the rotating stage channel. This will be used to generate a reference pulse after start and after gear ratio change, and process it using position capture (see below). 2) Start motion program -Rapid move to reference position -Config position capture for user flag of channel -Config and enable following to master signal at initial gear ratio. -Loop checking for poscapt flag to go active... 3) Schedule timing card to generate a single pulse at reference time that corresponds to when rotating stage should be at reference position. 4) When pulse occurs, loop in motion program detects it via poscapt, compares the homecapt value to the reference position, makes offset correction. From this point on the slave is position locked to the master based on the reference pulse/position. I didn't use triggered time base because I wanted to use the same approach for the synching after start as I do when synching after rate change.... 5) User requests rate change...which is passed down to running motion program and applied as gear ratio change. Once applied, rotation rate is correct, but not in sync with reference time/position. 6) Repeat steps 3 and 4 Another approach I considered was to have the timing card master signal be the desired rate, and have the gear ratio always be 1. Thus I would not have to pass rate changes to the motion program, but instead just re-program the timing card to a new signal rate. However, rates such as 1/8192 could not be exactly programmed to the timing card. This raised the question as to whether position lock gets worse if I use a slower master signal (one I can exactly represent in timing card) and a higher gear ratio. Any thoughts on that?

Thanks Curt. I was able to make position following work with the trigger capture. I also tested changing the gear ratio successfully. However, for my application, changes in gear ratio have to occur at a precise time, and therefore I am left with s/w monitoring of I/O to trigger each change. Based on my tests, this introduces a slip in the position following, relative to the time at which the gear ratio change trigger was generated. Is there a more accurate way to switch rates? Either via external trigger processing in hardware or at a predefined position? For this application, the continuously rotating stage cannot be stopped to transition from one rate to the next (i.e. cannot freeze master signal again, and use trigger capture). After a change in rate, the rotation must return to a position locked state. However, that position is defined by mater signal change since the precise time at which the rate changed. I am thinking I may need to use external reference pulses (separate from the master signal), and use the position capture feature of the delta tau to make position adjustments via custom motion program.

Thanks Curt. Position following may work for us, but let me ask you a couple more questions: 1) Is there any support for "triggered" position following. That is, upon receipt of a trigger the following would be enabled. 2) If #1 is not possible, then it seems the best we can do is monitor for I/O and have a PLC enable following upon receipt of the trigger. Would this mean that slave position lock to master could be off slightly? 3) We will need to keep our master signal running, but change the gear ratio (MasterPosSf) occasionally. If we do this, and limit with SlewMasterPosSf, will the following algorithm automatically re-establish position lock (i.e. by over speeding, and then slowing down)?

Yes it is Gate3. So are you saying that Acc24E3[1].Chan[3].EncCtrl is a write protected attribute? When I look at ACC24E3[1].WpKey, it is now $0, but I am able to change Acc24E3[1].Chan[3].EncCtrl. When I did the motor setup, did that change this attribute to no longer be write protected via WpKey?

When I was setting up one of my encoder channels to process an external time base signal, I noticed that I could not change the value of EncCtrl (it remained 7). I was able to get around this by using Motor Setup to create a Motor that uses this encoder channel, even though I am not actually connecting a motor...just using the encoder channel. Once I did that I was able to set EncCtrl to the desired value. Is there a way to enable an encoder channel for use without having to setup a Motor for that channel?

Thanks Curt, that did the trick. I am curious now, what if the motor load is large/delicate such that I need to gradually bring it up to speed (Ta) or minimize jerk (Ts). What approach can I use that will still allow the servo to eventually sync up with the external signal?

Thanks Brad. You explanation matches what I expected. I just wanted to double check with you before documenting why we chose this method.

The tests I ran were at a speed of 8.192 mu/msec (1 rev/sec), and the FE peaks at +/- 8 mu. JogTa=-10 JogTs=-50. I used position loop interactive tuning to set the velocity feedforward. I understand that the motor cannot hit top speed at the instant the time base is activated via receipt of the start trigger. However, I need the motor to "catch-up" so that it arrives at specified positions in each revolution within some tolerance from the theoretical arrival time relative to the receipt of the time base start trigger. My understanding is that the servo loop would do this, and thus eventually catch-up to where it should be. I expect to see some difference (<5 ms) between actual and theoretical time of arrival at each position as the motor is rotating due to the latency of the triggers (start trigger and capture pos triggers) between the timing card and the Delta Tau. However, a difference of 40ms seems to0 large, and it gets worse the higher the JogSpeed. I did notice that the difference between actual and theoretical timestamps remains pretty much constant (+/- 1ms) for a move at a specified JogSpeed.

I am using external time base. I am looking at different ways to signal my motion program to start a move. I can generate a single pulse from a timing card at the precise time I want the motion program to start the move. The first method is to receive the start trigger on an input of the ACC14E DIO card. Thus my motion program monitors a variable mapped to that input. When the variable value goes active, the motion program executes the move. The second method is to use the Triggered Time Base feature of the Delta Tau. I have setup and tested this method as explained by the users manual. My question is...Does using Triggered Time Base actually result in the move starting more precisely than the DIO approach? I have run tests on both methods but cannot conclude that there is a difference (it may just be that it is too small, and lost in the jitter of the start trigger transmission). Based on what the users manual says, using Trigger Time Base will latch the external time base encoder position at the instant the trigger is received. Does this mean DeltaPos would be more accurate under this method than the DIO method for the servo cycle at which the start trigger is received? Thus perhaps there indeed is a very small difference between the two methods.

I have an external time base signal generated by a timing card that is fed into Delta Tau and used by a coordinate system for control of a motor. I am also using the Triggered Time Base feature to start an indefinite jog for that motor upon receipt of a separate single "go" pulse from a timing card. To test how accurate this master/slave setup is working, I used the Position Compare feature of Delta Tau several times per revolution and fed the EQU output pulses back to the timer card where they are timestamped. When I first ran my test, I noticed that the timestamped position compare pulses were about 40ms off what I would have expected. If I adjust the starting position of the motor to compensate for this, the offset goes away. My question is whether the existence of this offset is normal or not. I was expecting no offset to exist since I am using the Triggered Time Base.

Page 26 of the "Synchronizing Power PMAC to External Events" needs to be updated to reflect that the ACC24E3 comp registers have 12 bits (not 8 bits) fractional count value. Also, while you are in there, bottom of pg 27 should be corrected to read "setting EquWrite to 1 forces the channel's internal compare state to 0"

Curt, I finally figured it out. It was Coord[x].TimeBaseSlew being set to the default 0.00001. That was limiting the time based value used in the servo cycle. Once I changed it to 1.0, as suggested on pg 12 of the manual, whalla. Now when I run the tests things look very accurate! 5 minutes have gone by and practically no drift. Thanks for all your time helping me out via this post. Cheers!