Repeated Data Gather

[windell747]

Aloha,

 

I have a trajectory generation issue with the jog that over accelerates the telescope and only occurs once every thousand or so jog calls. It is not predictable when it will occur. However, I want to do data gathers before each jog is called for X amount of servo cycles and stop. Unfortunately, since I don't know when the fault will occur, I will need to come up with a way to either store consecutive data gathers for the entire night (~500 jogs calls) or gather for the maximum amount of servo cycles and like a fault doesn't occur during that time, I overwrite the gather buffer. If it does occur during the set amount of time, then I store that data gather somewhere.

 

I've read up on the Data Gather section in the Power PMAC Users Manual and looked at the training slides and it doesn't seem to go this advance.

 

I'm wondering if anyone has an example of how to do this?

 

thanks,

windell

[Omron Forums Support]

Our built-in gathering function probably will not work for this. I suggest you log the data manually into external storage through a C program. There's an application note on the forum describing this.

[Omron Forums Support]

Well technically you can use our built-in gathering features, but you have to trap your condition smartly and probably fork() in a C program and toggle the Gather.Enable smartly too. Or you could manually write structure/variable values into a C file that you create and ignore our gather feature entirely, but you would probably have a little bit more jitter on the sampling period than you would if you used built-in data gathering. This would be a simpler approach but less deterministic.

 

Give us more information on what kind of determinism you need and we can help you better.

[windell747]

Hi Charles, Thank you for your help. One of the road blocks is debugging the issue with the jog call that generates a trajectory that violates its own JogTa setting. The trajectory remains parabolic (Ts=0 for us) but just simply is too quick and generates a following error.

 

1) We currently have a separate background program that runs all night and logs Motor[x].DesPos (as well as a lot of other data) at 50 ms intervals, but the issue is that it has been difficult to effectively work with deltatau to resolve the issue because we don't use the high resolution Gather function. Instead we use the data logging by our separate process and currently have an offline program that we use to parse it manually when there is a problem to troubleshoot. If I can get a list of items of what DT would need to more effectively debug my situation so that I can provide the necessary data at the sample rate that you would desired then that would really help me.

 

For faster sampling than 20 Hz maybe up to 100 Hz, I likely will need to create yet another separate process that samples for only a small window and has some smarts since continually recording data at a rate faster than 20 Hz might be storage repohibitive if doing so for the entire night.

 

2) Can you point me to where the application note that you are referring to is located?

 

thanks,

windell

 

 

 

Well technically you can use our built-in gathering features, but you have to trap your condition smartly and probably fork() in a C program and toggle the Gather.Enable smartly too. Or you could manually write structure/variable values into a C file that you create and ignore our gather feature entirely, but you would probably have a little bit more jitter on the sampling period than you would if you used built-in data gathering. This would be a simpler approach but less deterministic.

 

Give us more information on what kind of determinism you need and we can help you better.

[bgoskouie]

PowerPMAC rotary gathering buffer is the made for these situations (i.e. gather.enable=3)

[Omron Forums Support]

If you use my suggested technique of logging to a USB device, you should not have storage limitation problems. You can plug in a USB hard drive, for example. The application note is called "Saving Files on Power PMAC or External Media" and is on the FileDepot on our forums (this site). It gives C examples. You just need to spawn a thread to run the code in the example (adjusted to log the data you want rather than the arbitrary P-Variables listed in the example) at the instant you want to start gathering.

 

I am confused about your first statement. It is impossible to command a jog beyond JogTa. You simply cannot do it. Power PMAC looks at your JogTa setting when generating the trajectory and it is an absolute limit in the command.

[windell747]

I certainly understand what you're saying about the JogTa limit because that is the way I interpret the setting when I read the SRM.

 

Background:

However, I have empirical evidence where 1 on 500 or so jogs will have a DesPos trajectory that violates its own acceleration limit by 2 to 3 times. Of course, I understand that it is not intended to do this, but I've tried all of your suggestions about things to check and monitor and the problem still remains.

 

What seems to be a trivial thing is seems to not be so simple. Here are three threads in the past that I've raised about the issue. Initially, I had a race condition where large steps were making it into my pvt commands, but now I am certain that there is no race condition and the motion program is aborted before the jogs are called.

 

http://forums.deltatau.com/showthread.php?tid=1972

http://forums.deltatau.com/showthread.php?tid=1987

http://forums.deltatau.com/showthread.php?tid=1884

 

What I've done:

What I've gathered through conversations with Steve is that when a Jog is called it uses measured velocity, acceleration, and jerk values as the initial point for the Jog and propagates that forward. So encoder noise could create an issue so that the jog will plot a trajectory from a false velocity that was calculated due to noise.

 

However when I speak with Curt, he says that encoder noise isn't an issue for the Jog trajectory since it is based on the last DesPos value right before the jog is called.

 

So I'm a bit confused about the conflicting information. It seems that I'm missing part of the puzzle.

 

What I'm doing now:

From my previous conversations with you, you were saying that jogs aren't meant to blend with pvt commands. I understand this so I'm currently following your old suggestion to use linear mode and not stopping the motion program. I'm rewriting some of our code now to use linear mode as opposed to jog calls. So that is the status.

 

Example:

To provide you with a clear example of what I mean, I've attached a screen shot of a fault that we received on the night of 4/7.

 

You will want to look at the red trace for the hour angle axis (the second plot). The red trace is the value of Motor[0].DesPos with time. The Y-axis is in degrees. X-axis is in seconds (Linux time). You'll also see that in the 5th plot, the current for the hour angle axis also saturates to 20A for this brief time. This current maxing out is the first sign that the trajectory is not right. When you go through the numbers, you get

 

(2*(4.149638-4.12615 deg)*3600 arc-sec/deg)/(.123201 sec) = 1372 arc-sec/s^2. At 1035 motor units/arc-sec, I convert to milliseconds/motor unit we get a value of 0.7 ms^2/count. The value we have set for JogTa for this move is -2.41 ms^s/count.

 

I'd be happy to speak with you on the phone to work directly with you on this issue.

 

thanks,

windell

 

 

 

If you use my suggested technique of logging to a USB device, you should not have storage limitation problems. You can plug in a USB hard drive, for example. The application note is called "Saving Files on Power PMAC or External Media" and is on the FileDepot on our forums (this site). It gives C examples. You just need to spawn a thread to run the code in the example (adjusted to log the data you want rather than the arbitrary P-Variables listed in the example) at the instant you want to start gathering.

 

I am confused about your first statement. It is impossible to command a jog beyond JogTa. You simply cannot do it. Power PMAC looks at your JogTa setting when generating the trajectory and it is an absolute limit in the command.

[Omron Forums Support]

PPMAC only uses actual position/velocity when your motor is currently open loop. This means the first values used when closing the loop are the last "measured" ones. If your motor is closed-loop before you command the jog, then desired values will be used as starting values for the jog.

 

It is not possible for the desired values to exceed your limits. What you are seeing is probably the servo loop reacting to encoder noise. You can see this simply by plotting actual velocity and desired velocity. If the "spike" in actual precedes the "spike" in desired, you know the origin is encoder noise and the servo loop is just reacting.

 

Have you tried using a MaxChange filter on your encoder conversion table? This would filter out random blips on your encoder. Set EncTable[n].MaxDelta equal to a value slightly higher than the maximum Motor[x].ActVel you expect on that motor.