Jump to content
OMRON Forums

URGENT: Jog command shaping issue


windell747

Recommended Posts

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

Link to comment
Share on other sites

  • Replies 8
  • Created
  • Last Reply

Top Posters In This Topic

Hi,

 

Can you post the motion program or PLC that is governing this?

 

Are you using Coord[x].SegMoveTime > 0? If you try to blend between linear/pvt, you must have SegMoveTime > 0 (typical settings are 2-3 msec). You do not actually need to stop between the linear and pvt moves. Does your application require an abort here?

 

Are your current loops and servo loops reliable/stable for the motors involved?

 

Also something to note when transitioning to/from a PVT to a linear move, such as a jog or an actual linear move in a motion program, you need to make sure the commanded jog speed equals the PVT commanded speed for that motor at the transition point. Here's an example program:

 

inc;
pvt1000;
x20:30;
linear;
x30 f30;
pvt1000;
x20:0;

 

And the example plot:

 

plot.jpg.43e0f26eb3876c4f12753ca192346a60.jpg

Link to comment
Share on other sites

Thanks so much for responding. I'll respond inside your reply.

Hi,

 

Can you post the motion program or PLC that is governing this?

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

 

Are you using Coord[x].SegMoveTime > 0? If you try to blend between linear/pvt, you must have SegMoveTime > 0 (typical settings are 2-3 msec). You do not actually need to stop between the linear and pvt moves.

 

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.

 

Are your current loops and servo loops reliable/stable for the motors involved?

 

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.

 

Also something to note when transitioning to/from a PVT to a linear move, such as a jog or an actual linear move in a motion program, you need to make sure the commanded jog speed equals the PVT commanded speed for that motor at the transition point. Here's an example program:

 

inc;
pvt1000;
x20:30;
linear;
x30 f30;
pvt1000;
x20:0;

 

And the example plot:

 

 

 

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Once you include the header file for global shared memory pointers:

 

#include

#include

 

And initialize the library in your code use the pointer reference to the structure elements:

 

int main(void) {

 

//-------------------------------

// . . .

//-------------------------------

 

double sometvar;

 

//-------------------------------

// . . .

//-------------------------------

InitLibrary () ;

 

//-------------------------------

// . . .

//-------------------------------

 

pshm->Motor[2].JogTa = 10.0;

 

sometvar = pshm->Motor[2].JogTs;

 

//-------------------------------

// . . .

//-------------------------------

 

CloseLibrary();

 

return 0;

}

 

 

To stop the program use the on-line quit command:

q

pause

 

This will stop gracefully at a programmed point

Link to comment
Share on other sites

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

 

Once you include the header file for global shared memory pointers:

 

#include

#include

 

And initialize the library in your code use the pointer reference to the structure elements:

 

int main(void) {

 

//-------------------------------

// . . .

//-------------------------------

 

double sometvar;

 

//-------------------------------

// . . .

//-------------------------------

InitLibrary () ;

 

//-------------------------------

// . . .

//-------------------------------

 

pshm->Motor[2].JogTa = 10.0;

 

sometvar = pshm->Motor[2].JogTs;

 

//-------------------------------

// . . .

//-------------------------------

 

CloseLibrary();

 

return 0;

}

 

 

To stop the program use the on-line quit command:

q

pause

 

This will stop gracefully at a programmed point

Link to comment
Share on other sites

  • 3 weeks later...

I'm still having this trajectory over acceleration problem and its very hard to debug as it isn't easily reproduceable.

 

I've put in a small delay of 20 ms between when the abort is called and when the next jog is called. However, I'm still getting a few trajectories which are 3 times what the Ta specifies. Again the rate is 1 time in maybe 500 times.

 

As another thing to try, I am implementing the Motor[x].InPos fix right now where I wait until this flag goes high before sending the jog after the motion program is stopped. However, I'm not sure it will solve the problem since the Motor[x].InPos flag goes high when a Motor[x].InPosBand condition is met so technically the motor is still decelerating when the next jog is issued. So right now I'm not seeing how waiting longer helps with the trajectory for the next jog. Maybe I'm humbly looking over something?

 

Can you give me some suggestions for things to print out when the jog is called to debug why the trajectory sometimes doesn't follow the Jog.Ta setting?

 

thanks,

windell

Link to comment
Share on other sites

The Motor[x].InPos status bit is set to 1 when all of the conditions for “in position” are satisified: the motor is closed-loop, the desired velocity is zero, the move timer is not active (no move, dwell, or delay being executed, the magnitude of the following error is less than or equal to Motor[x].InPosBand, and all of these conditions have been true for (Motor[x].InPosTime - 1) consecutive servo cycles.

 

Let's continue this as a technical support issue - rich text email will allow better information exchange:

smilici@deltatau.com

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...