windell747

Thank you Charles and Curt! So here is a summary of what I've gathered The jog uses the instataneous velocity, acceleration, and jerk at the time its called. When called consecutively, it plots a trajectory according to Jog.Ta and Jog.Ts to the latest position that was sent in the latest jog. The end conditions are set to 0 velocity, 0 acceleration, 0 jerk at that endpoint. Is this all correct?

Aloha, What happens when a jog command is sent with a position and then 50 ms later another jog command is sent with a slightly incremented position? The position of the motors are still far away from the first jog requested position as it is accelerating and making it there. 1) Do the consecutive jog commands just update the endpoint for the jog? 2) Or does it interrupt the previous jog and start a new one? I'm trying to see how continuous the motion is. Pretty much we do this to accelerate to a target varying in position with time, but it is moving slowly. I'll say that I'm working with a current set of code already implemented on our system and if I were to rewrite the code, I would do things a bit differently. windell

Thank you very much! When I change the password to the PMAC, for some reason the IDE no longer can connect via FTP. Do you know why this happens? When I change the password back then it's fine.

Is it possible to get a response from DT on this issue? much thanks, windell

Hello, I just tried and it seems that I might be doing something wrong because neither the old or new password works when I do the following ftp://root@pmac2.... (in browser) Am I supposed to use a different name? to ssh in I use root and the password i set it to and it works fine. I'm it is neither the passwords I set, i have no idea what the password would be.

I changed the password on my PMAC following the instructions found on another post here http://forums.deltatau.com/showthread.php?tid=1979 The issue that I'm getting now when I try to upload my code is that the IDE tells me "Could not Connect to Power Pmac FTP client, ...." I believe that this is because I changed the login password on the PMAC. Is there a place I that I can change the FTP configuration in the IDE? Right now I had to change the password back in order to upload new code. thank you, Windell

Thank you very much Charles, Steve, and CNCguru. Charles-I just took a look at the entry in the SRM and I see what you're saying. Thank you for pointing the InPos flag out to me. Steve-Right now It looks like most of the time not waiting for the InPos flag to go high has been ok. What you're saying about using the current velocity, acceleration, and jerk is interesting since I believe we're doing this a lot. I'm trying to investigate why rarely, the trajectory isn't coming out right. Question: The velocity, acceleration, and jerk that is used for the jog trajectory, are theses values the last values from the trajectory of the abort slowing the telescope down or are these from the measurements that the encoders are giving at the time of the jog. The reason I'm asking is I'm wondering if encoder noise could be causing the velocity, acceleration, and jerk calculations to be wrong and is causing the trajectory planning to be wrong for a fraction of the jogs that are sent soon after the pvt. Cncguru-The decision that I've put in before the jog is the following while(GetInPos(pHAAxis) == 0); where GetInPos is a function that looks at that in position bit. This is a bit awkward, since the time for this while loop could take a variable amount of time depending on how long it takes the telescope to decelerate to a stop. I just implemented it in my code and sometimes it takes a whole 1 second to complete, which is a bit slow for me (I need to respond to incoming commands on a 50 ms basis). How did you implement your decision to move on and send the jog?

Thank you very much Charles! I'm happy to hear that the linear and jog have identical acceleration profiles! I'll try the pvt to jog idea first and see if that fixes our problem. I do think transitioning from pvt to linear is a much better and smooth idea. It would require me to change our code a fair bit though so I'll try the change with less risk first. thanks again! windell

Thank you Charles. I really appreciate your patience. Also thank you for the pseudocode. I believe that I can use it to help with stopping the motion program. I did a check of the AbortTa ad AbortTs variables and they're set fine and don't change at all over time. Part of my problem is that I didn't make the connection that a linear and jog share the same shape. How do you limit the acceleration between two What we really like about the jog command is that sending it creates a constant acceleration trajectory between the endpoints. This is a hard requirement for me. I did a read of the command in the software manual and it didn't mention anything about setting the acceleration profile for a linear command. Question: 1) Lets say that we throw out the idea of blending the motion because you say that only linear mode can blend with pvt. It doesn't seem that I can limit the acceleration easily using a linear mode unless I write my own trajectory profile function (maybe i'm overlooking something?). 1) How do I properly do the transition between and pvt and jog? Sometimes we're locked in our own world over here so how you've seen it done before is fine. 2) For example, do I send X(current_position):0 and then stop the motion program (or just raise a flag to hold the motion program in while loop or something until pvt mode goes on again) 3) Then would I wait a certain amount of time before sending a jog or I can send it immediately? Please keep in mind that this problem occurs only 1 in 500 transitions on average between pvt and jog so it is an intermittent problem and occurs when the trajectory of the jog doesn't shape properly and overacclerates the telescope. In fact right now we have not had a problem in the past few nights, but it always comes back. Upon checking the logs, all the position values are correct, the problem is occurring in the trajectory generation for the jog.

Hi All, Thanks in advance for your help. Below is a description of a bug I'm working on and some questions I have. I know that I've asked this question before, but through the process, I didn't feel that I got quite a clear answer, so I'm reposting with a clarified explanation to try and get the best possible help. Thanks in advance for your help! sincerely, windell First some background. Attached is a motion program for one of the axes of our telescope. All macros are mapped to p-variables that interface with a C program, but I think they're names describe them pretty well. Step 1: We start this motion program using the "r" command. There it waits the while loop until the "P_PVT_HA_READY" flag goes high. This flag goes high once we have two position commands (we're calling them "buffers 1 & 2 are filled") for the same axis. The two position commands are linearly interpolated into 10 intermediate points which are stored in p-variables. these commands are sent to the pvt function via the motion program in an infinite while loop as more position commands come in and the buffers are loaded. Step 2: Then when we want to stop the pvt mode and issue a jog(do a large movement over to another star), we just issue an "abort" for the motion program. Step 3: then we change encoder feedback to use the absolute encoders. Step 4: then we issue the "jog" to the new star position Problem description: Where we are having a problem is the transition between stopping pvt mode and then issuing a jog. Sometimes (1 in 500 times) the jog doesn't create the trajectory properly and over accelerates the telescope axis even if the JogTa and JogTs variables have been untouched. Questions: 1) By aborting the motion program, we're abruptly stopping it in the middle of issuing pvt commands. Is this a bad thing to do? What is a better way to do this? Is it possible to get an example? 2) When stopping the pvt mode, should I have the motion program have a flag in the while loop that issues something like the following: X(current_position):0 before ending the motion program? 3) if the motion program is ending abrupting via the abort command, then there is little time between the previous pvt command and the following jog command. Would it be good to put a delay in between stopping the motion program and issuing a jog say 10 ms? 4) Blending isn't necessarily a requirement, but when going between pvt and jog, it would be nice to do this smoothly to prevent discontinuities in the currents, how do I do this properly? Do you have an example? thanks, windell ha_pvt_p1.pmc

Thanks steve. I was able to access the shared memory perfectly! Much appreciated :)

Thanks Shansen! I think I got it to work. I put an extra space by accident in between the "/" and the "." in that cd command. It seems that the password has stayed now. I just tried uploading new code however, and I'm getting the following error "Could not Connect to Power Pmac FTP client, ...." I think this is because I changed the password because it started only after I had changed the password. Any ideas? thanks, windell

When the Motor[x].FeFatal goes high, I would like to record the magnitude of the offending following error. Right now I'm storing the following error in my C program, but I realize that I am catching it too late since my C program loops at only about 1 kHz and the servo loop runs much faster. Can someone tell me how I could record the magnitude of the offending following error at the time that the FeFatal flag goes high? I know it should be whatever I've sent the limit to, but I just want to make sure. Thank you, Windell

Thank you shansen. When I run your first "cp" step I get the following error. /# cp -a * ../etc/ cp: writing `../etc/bin/bzcat': No space left on device cp: writing `../etc/bin/gunzip': No space left on device cp: writing `../etc/bin/bzip2': No space left on device is there something that I am doing wrong?

I am having the same error "Could not Connect to Power Pmac FTP client, Please make sure that you have a valid IP address." Help would be greatly appreciated! Thanks,

First of all, thank you for your help. I realize that helping at the distance like this can be a challenge. Today I looked at another jog that produced a trajectory that had an acceleration profile that was way too great and caused another over current trip. We have set the following Motor[0].JogTa = -1.97 Motor[0].JogTs = 0 Motor[2].JogTa = -2.4 Motor[2].JogTs = 0 This corresponds to a constant acceleration for each axis of about 500 arc-sec/sec/sec (different gear ratios). However, the trajectory created when the jog was called was a 1500 arc-sec/sec/sec path which of course drew too much current for the telescope to follow. This problem only occurred for 1 of 500 jogs that were issued last night. All the others had the right acceleration. Here is what I would like to do to try to debug this situation: 1) I want to do a check on the Motor[0].JogTa and Motor[2].JogTa variables and confirm that they haven't changed before each jog command is sent. If they have changed, I will write an error to a file and rewrite the variable to set it to the right value. I have read the manual section on accessing the shared memory and such, but I'm still confused how to access this variable and how to set it from within a C program. Can someone give me an example on how to do this? 2) How do I properly stop the pvt program so that I can then issue a jog? Thanks so much for your help! windell

Hi Curt, I am in the process of figuring out a way to sync our PMAC to UTC time as well. Idealy I would like to send commands to the PMAC with a timestamp ahead of time and have the PMAC execute those commands on those timestamps. Right now were synchronizing the PMAC based on times that commands are sent and knowing that they're supposed to be sent at 50 ms intervals (the time stamps aren't sent with the commands). What is the simplest way to sync the PMAC to UTC time that has been proven by any of your customers? thanks, windell

Hi, I would like to upgrade the firmware of our PMAC and looked through the manual a bit for a procedure, but didn't find one. Does anyone have a procedure? Is there anything special that I need to do before upgrading the firmware? I'm assuming that I will need to reupload the configuration file? Will I need to recompile the custom C program that I have running on the PMAC? Thanks, windell

Thanks so much for responding. I'll respond inside your reply. The code is quite weildy since there is a bit of distance between the higher level code to where the commands are actually sent to the PMAC. What I will do is copy and paste a part from the higher level code as well as the supporting functions. The supporting functions are where the commands are sent to the PMAC. The general flow is: (this is outlining the TCSTrack() function pretty much) 1) Outside Computer sends a "track" to higher level PMAC code with encoder values. 2) PMAC higher level code commands PMAC to jog to the encoder values sent by the computer using the absolute encoders. 3) Outside Computer sends at 20Hz, tracki command with encoder positions telling PMAC to use the incremental encoders and use the PVT mode to track a star. The PMAC high level code then switches encoders to using the incremental for feedback (using setencoderfeedback()) and enables the PVT motion program via the startpvt () and getprogrunning() functions. 4) The trackis keep coming in at 20 Hz. If there is a large change in the encoder position, the PMAC changes encoders back to the absolutes and stops the motion program via the stopmotionprog function. 5)Then with PVT not running, the PMAC runs a jog to the new position. 6) When at the new position, the high level PMAC code commands the PMAC to run PVT mode againby using startPvt function and getprogrunning(). 7)When No I don't know anywhere in the code where Coord[x].SegMoveTime is set. I also just checked with the PMAC and it is 0 for both coordinate systems. Yes, they servo loops and gains we've been using have been stable for quite some time. The only times the telescope goes unstable is when the command shaping doesn't work for the jog and gives a trajectory that is too quick for the telescope to respond. Is there a log that is stored on the PMAC of all the raw commands sent to the PMAC? If not is there a way that I can have the PMAC keep a log of everything that it received from the higher level code? I pretty much want a list of commands like the above so that I can see the end result of the higher level code and what it is giving to the PMAC API. code_for_DT.c

Hi, When issuing a jog command to our PMAC about 1 in 500 times the jog command fails to command shape the commanded position by the Ta variable. This one time, the acceleration was great enough to cause instability. Fortunately there was an over acceleration safety in place to stop the motion. This jog is usually occurring immediately after the pvt mode has been running. To transition to the jog, a "abort" is given and then the jog is issued afterwards. There is no place in my code (custom written C program) were the Ta and Ts variables are modified on the fly. The only time they are set is using the setup variables. Questions: 1) I expect this behavior to continue unless I make a change. How do I poll the Ta and Ts variables overtime I call the jog command so that I make sure that it is indeed unchanged when the problem occurs? 2) How do I reset this variable to another value within my C program if it is changed for some reason? 3) The firmware running right now on the PMAC is 1.5.8.0. Could a firmware upgrade solve this problem? If you want to see what is happening, I've attached a plot of the data that I take throughout the night. The first two plots show the red line which is the commanded position for each axis. You see that in the second plot, the red line follows a much faster profile when both Ta variables are about the same. The telescope tries desperately to follow with a large current increase and then goes unstable. Thank you very much! windell tlm_20150716m8m9m10_pt2.pdf

Thanks Charles and Wilson for your invaluable input. I'll answer both your questions in a single response. We use the incremental encoder during slow motions for both the dec and ha axes. On the hour axis the incremental encoder is mated via a friction drive and directly observes the HA rotation. The absolute encoder is mount to a pinion gear that also drives the HA axis. Historically it was done this way because the incremental observes the HA motion directly without backlash. The gear reductions are such that we get about 200 counts on the incremental for every count on the absolute (absolutes: approx 1000 counts/arc-sec, incremental: 200,000 counts/arc-sec) so the added resolution provides tighter control during star tracks. We have not done a study however that indicates that this resolution in in fact required. Due to slight misalignment between the HA axis of rotation and the axis of rotation for the encoder, the incremental every so often slips by a few counts. I honestly haven't evaluated if were missing counts due to moving the telescope too fast, but that would be good to look into. It would seem that we're ok since for the most part, the motion seems to be conserved. Unless the bumps are really do to moving too fast on the incremental. When we do quick motions between the star tracks, we switch the motor position register to read the absolute encoder so effectively we erase the "bump" due to the slip. I hope this answers your questions. Thanks again for your help!

Thank you very much Charles. This is extremely helpful. I still have yet to try the code out, but do you know if there is a difference in the encoder readings at the switch, will there be a spike in the following error? I guess I'm not sure how the following error is calculated and when.

My control loop uses as feedback two different encoders, but at different times. For higher rates, it uses and absolute encoder, but on slower rotation rates it uses an incremental encoder which has a much finer resolution. Right now the motor position register is switched between the two different encoder registers. The scale factor of the incremental is set so that the absolute and incremental encoder registers read about the same. However, over time the incremental slips and the registers become off from each other. Therefore when switching the motor register back to the absolute position, there is a fake jump in position. The servo loop sometimes sees this jump and responds slightly (but usually not much) also the following error jumps. I was thinking about doing the following algorithm, but I don't know how to exactly implement it(indicated by "***DONT KNOW***"): 1. Stop using the motor register feedback ***DONT KNOW**** 2. Disable following error calculation temp = Motor[0].FEFata;l Motor[0].FEFatal = 0; 3. Change the assignment of the motor register to different encoder. 4. Enable following error calculation Motor[0].FEFatal = temp; 5. Start using the motor register to feedback. ***DONT KNOW*** 6. Continue operation like normal. Does anyone know how I do this properly? Also is there anything that I might be overlooking? thanks windell

Hmm...Maybe I'm doing something wrong. Here is what I wrote in the terminal motor[1].pAbsPos=0 hmz However, the counter still reads 166708408.33 ... Am I not doing something properly?

Hi, I'm sending position commands to the PMAC in the form of step input and 99% of the time it uses the Motor[x].JogTa paramemeter to limit the acceleration (Motor[x].JogTs=0.0). However, there is a 1% time when the PMAC seems to disregard this setting and allows spikes in the acceleration. For me this is causing overvoltage problems on my power supply side and following errors. Does anyone know what could cause the PMAC to disregard the Ta setting and how can I prevent this from happening? I've attached two files showing a good case and the bad case. In both files, look at the second plot. In the good run you will see the commanded position (red trace) accelerate nicely to a step command (bluish trace). However, in the bad run, you will see the commanded position jump all over the place in response to a step command. The firmware version is 1.5.8.0. Settings: Motor[0].JogTa=-3 (HA axis) Motor[0].JogTs=0 Motor[2].JogTa=-2.5749967 (DEC axis) Motor[2].JogTs=0 Thanks, windell goodmove.pdf badmove.pdf