Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Triggered time base
#1
Hello,
I am currently trying to synchronize an axis on an external clock. The purpose is :
starting at a position P0, we want to be at
P0 + n * step_size at every tic of the external clock (after an acceleration phase of course, no step-by step motion, but a continuous scan) , the axis should also be able to deccelerate, and re-accelerate in the other direction to redo the scan in the other direction without loosing its synchronicity.
It is possible to receive an additional clock whose frequency is an exact multiple of the base clock. In my main use-cases, the base clock is 1KHz and the fast clock is a 128KHz.
Triggered time base seems to be the appropriate tool for that , so I input my 2 clocks on a spare motor coder lines (fast clock on A/B and base clock on C (as you guys suggested me on this forum (thanks again !)))

Then to test the validity of my setup, I decided to have a plc looking for rising edges of my base clock and when it sees one, takes the difference between the commanded motor.ActPos and the P0 registered at the start of the motion program and look at the modulo of this difference by step_size : (motor.ActPos- P0)% step_size

I was expecting to see something centered on 0, with a large amount of jitter due to my measurment method (110 us plc). but instead I have something like that :

modulo
A
|.......................W............................W...........................W
|.......................WMMMMMMMMMMMW...........................WMMMMMM
|.......................W............................W...........................W
|-------------------W-----------------------W-----------------------W------------------ 0
|.......................W............................W...........................W
|MMMMMMMMMW............................WMMMMMMMMMMMW
|.......................W............................W...........................W
|-----------------------------------------------------------------------------------> time

each W vertical line happens during a U-turn, this seems norrmal, there is no reason for the modulo for being meaningful during acceleration and deceleration

during constant speed paths, the error is not centered on 0 but has an offset, and this offset is different depending on the direction of my scan with a symetry .
Reply
#2
I thought this could be caused by my motor regulation, so I deceided that instead of plotting
(motor.ActPos- P0)% step_size
I would plot
(motor.DesPos- P0)% step_size
And I had a very similar result !
my following error was just adding a little noise over somethhing already not OK
if I zoom in on a constant speed motion the desPos modulo looks like this :
..../...../...../..../..../
.../|..../|.../|.../|.../|
../.|.../.|../.|../.|../.|
./..|../..|./..|./..|./..|
/...|./...|/...|/...|/...|
Reply
#3
Here are all the things I did to try to fix the problem :

1. thinking it was a plc jitter problem, I put my measurment code in the phase routine of a spare motor which runs at 144Khz. with that speed I was expecting during the constant speed a measurment jitter that would have the value :
commanded_motor_speed * measure_period = 5 um/ms * 7 us = 5*0.007 = 35 nm
but the jitter I observe is 500 nm
and the distance between the center of this jitter and the actual 0 as shown on the first graphic is also about 500 nm which makes for me spikes of up to 1 um in the desired position which is already taking all my acceptable error , so when I add my following error .. I am dommed (my motor usually performs at this speed with a following error below 400 nm)

2. I was thinking it could be the capture of my P0, but as the motor is still when starting and I take the P0= desPos, I have something perfect here.

3. TimeBaseSlew too low ? I put it to 30 (It was already at 1 as specified in the doc) and then 30000, not better

4. acceleration and decelration of the motor not Ok ? we are far below what the motor can take and I put 0 in invAmax, invDmax and invJmax

5. problem during the acceleration ad decceleration phases ? : I put a rearm request in the middle of every u-turn with a dwell 0 and a re-arming from a plc -> no change at all.

6. time base not liking the PVT moves ? : I re-wrote the same program with linear motions : same results
Reply
#4
Noticable facts :

1. the offset from 0 as shown in the first graph is always the same when I re-run my program , except for the first time when it is usually much worse (I did not dig into that, thinking it was due to a P0 capture problem in my code)

2. I used to have a PVT point at each passing point distant of step_size form the previous, now I switched to a single pvt point at the beginning of the line and one at the end (and trust PMAC's trajectory builder) . when I add so many pvt points, the distance to 0 of every line was growing of a constant value over time ! my steps were getting more and more far from 0 at every new line, this was repeatable if I re-run the program. now with less points or in linear , the distance to 0 is the same in both direcion and at every iteration (only the sign changes depending on the direction)

3. I used to make my unfreeze on a negative limit switch , now I switched to a C line of the simulated coder , this had the effect to make my distance to 0 bigger (was 500 nm before, is 1.2 um now)
Reply
#5
Thank you if you had the patience to read me up to here, I don't know if that behavior of the desPos is coherent, if I am at the limit of what the time-base system can offer, or if I am just missing an obvious point, but I don't manage to have this solution working for now. I can provide all my programs, plcs and configuration files if needed.
thank you very much, have all a very good day,
cheers,
Jeremy
PS : Sorry I used replies as paragraphs separators for clarity, if that is not OK with the forums guidelines, do not hesitate to tell me , I will put it back together
Reply
#6
Two things to consider:

First, it looks like a non-zero acceleration time could explain the offsets you are seeing. Try programming linear moves with TA0 TS0 TD0 and no segmentation (Coord[x].SegMoveTime=0).

Second, it may be important to understand that the trigger occurs partway through a servo cycle, so the first cycle after the trigger is a "partial" one. For example, if the trigger occurs 1/4 of the way through the cycle, the first cycle's "time" would be 3/4 of a full cycle, and so the position increment would only be 3/4 as much for this first cycle. (This is key for full synchronization.) I am not sure if your calculations take this into account.
Reply
#7
On the jitter issue:

Remember that your clock signals and PMAC's servo/phase clock inputs are fundamentally asynchronous. PMAC's "external time base" feature calculates the number of clock pulses received each servo cycle (with timer-based sub-count interpolation) and increments its trajectory time value by an amount proportional to this delta -- as opposed to its own internal time sense. This provides a software synchronization between the two independent clock systems.

Motor position values -- DesPos and ActPos -- are updated once per PMAC servo clock cycle, and to repeat, this clock is asynchronous to your clocks. So I think it would be very easy to get an effective beat frequency in your test sampling this way. This does NOT mean that there is an actual beat frequency like this in the real motion.
Reply
#8
(11-28-2018, 02:07 PM)curtwilson Wrote: Two things to consider:

First, it looks like a non-zero acceleration time could explain the offsets you are seeing. Try programming linear moves with TA0 TS0 TD0 and no segmentation (Coord[x].SegMoveTime=0).

Second, it may be important to understand that the trigger occurs partway through a servo cycle, so the first cycle after the trigger is a "partial" one. For example, if the trigger occurs 1/4 of the way through the cycle, the first cycle's "time" would be 3/4 of a full cycle, and so the position increment would only be 3/4 as much for this first cycle. (This is key for full synchronization.) I am not sure if your calculations take this into account.

Hello,

Thank you very much for your answers, I answer to number 2 , I will try number 1 during this morning :
I saw that in the power PMAC manual, but I thought it was not a problem for my use-case. I don't see what should be changed in my calculations to take that into account, I only thought that ; yes, the first deltaPos will be smaller , but that is good , that is to ensure that my t0 is properly defined on the trigger and not on the next servo cycle after the trigger, and then I don't see how it could impact the fact that if I asked
pvt(200)
A(0)(5000)
the moment when A crosses again position 0 should be almost perfectly aligned with the 200 th tic of my clock (and the 128*200th tic of my fast clock) , and even more perfectly if I consider the desiredPos instead of ActPos (with an error only due to my measurment plc but this one is much faster than a servocycle (144KHz)). I am certainly wrong in some way, but I don't see what I am missing.
thanks again,
cheers,
Jeremy
Reply
#9
(11-28-2018, 02:07 PM)curtwilson Wrote: First, it looks like a non-zero acceleration time could explain the offsets you are seeing. Try programming linear moves with TA0 TS0 TD0 and no segmentation (Coord[x].SegMoveTime=0).

OK, I just did that test, and I have the exact same profile, except for the high freq oscillations that used to occur during the acceleration times. but the offsets are still there, exactly symmetrics around 0 and have the same value . the jitter is also still here but that is not a surprise. I also plotted Motor[].desPos , it is perfectly triangular.
so to me this definitively looks like a t0 problem either in the measurment method or in the actual trigger.
I trigger with a plc0 running at 110 us, the program prepares the variables and freezes the time base . then the plc 0 waits for a global variable called armTimeBase to be manually put to 1. when armTimeBase is 1 it checks that the Gate1[4].Chan[3].ABC is < 4 (meaning that index is down) and as soon as it sees this, it puts EncTable[5].index1 at 2, so in principle the next rising edge of the clock should unfreeze it ...
Reply
#10
Now that I've had a little time to get back to this, I want to focus on some basics:

The purpose of triggered time base is to provide a very predictable and repeatable motion response to a hardware input signal -- with less uncertainty than a full software servo cycle. It does this by latching the count value of the clock in hardware the instant the trigger comes in. This count value is used as "t0" for subsequent motion interpolation calculations.

But as a "sampled data" (i.e. digital) system, PMAC cannot respond instantly to this event. You will have a finite time delay -- it looks like a full servo cycle -- in response. Your analysis seems to assume this should be zero delay. But again, the purpose of this feature is to get very repeatable response, and it looks to be doing that.

You mention the difference in response between using a flag input and the encoder index © input for your trigger. Remember that the flag input goes through an opto-isolator which has a delay in the tens of microseconds. Just another (very repeatable) delay you need to account for if you use this.
Reply
#11
(12-04-2018, 05:03 PM)curtwilson Wrote: Now that I've had a little time to get back to this, I want to focus on some basics:

The purpose of triggered time base is to provide a very predictable and repeatable motion response to a hardware input signal -- with less uncertainty than a full software servo cycle. It does this by latching the count value of the clock in hardware the instant the trigger comes in. This count value is used as "t0" for subsequent motion interpolation calculations.

But as a "sampled data" (i.e. digital) system, PMAC cannot respond instantly to this event. You will have a finite time delay -- it looks like a full servo cycle -- in response. Your analysis seems to assume this should be zero delay. But again, the purpose of this feature is to get very repeatable response, and it looks to be doing that.

You mention the difference in response between using a flag input and the encoder index © input for your trigger. Remember that the flag input goes through an opto-isolator which has a delay in the tens of microseconds. Just another (very repeatable) delay you need to account for if you use this.

YES !
once again your answer has been super usefull for my tests, now I do a sample movement in triggered time base, measure my delay during that sample , come back to 0 , rearm the trigger and prepare a move wich contain an offset proposritonal to what I measured just before , and bingo ! the following moves are perfectly centered !
Thank you very much !
Reply
#12
for those who might find interest in that discussion, the jitter problem has also been fixed .
the content of the discussion that lead me to the solution can be found here :
http://forums.deltatau.com/showthread.php?tid=2795
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)