capturing edge triggered or not?

[leopoldmaccon.de]

Hello, I have seen different descriptions in the manuals on how the capturing encoder positions works: ACC24E2A.pdf says on pg 37: The trigger is armed when the position capture register is read. After this, as soon as the Compact MACRO Station sees that the specified input lines are in the specified states, the trigger will occur — it is level-trigger, not edge-triggered. Turbo SRM.pdf says on pg 226: The trigger is armed when the position capture register is read. After this, as soon as the Servo IC hardware sees that the specified input lines change into the specified states, the trigger will occur -- it is edge-triggered, not level-triggered. I'm a bit confused: both manuals are talking about the same hardware?! So what is the truth? Edge-triggering would be nice, it would save me a lot of code and time for waiting for the best time to arm the trigger. Dirk

[steve.milici]

[quote='leopold@maccon.de' pid='468' dateline='1277219796'] Hello, I have seen different descriptions in the manuals on how the capturing encoder positions works: ACC24E2A.pdf says on pg 37: The trigger is armed when the position capture register is read. After this, as soon as the Compact MACRO Station sees that the specified input lines are in the specified states, the trigger will occur — it is level-trigger, not edge-triggered. Turbo SRM.pdf says on pg 226: The trigger is armed when the position capture register is read. After this, as soon as the Servo IC hardware sees that the specified input lines change into the specified states, the trigger will occur -- it is edge-triggered, not level-triggered. I'm a bit confused: both manuals are talking about the same hardware?! So what is the truth? Edge-triggering would be nice, it would save me a lot of code and time for waiting for the best time to arm the trigger. Dirk [/quote] This is a typo in the Turbo SRM - it is level triggered.

[leopoldmaccon.de]

Hmm, not the answer I'd like to get ;-) Thanks nevertheless

[curtwilson]

The PMAC(1) ASICs have edge-triggered capture. We had several complaints that if you were already in the triggered state when you started a homing search or similar move, you would go on "forever" (at least into the limits). So in the PMAC2 ASICs, we used a level-triggered capture. In this case, if you are in the trigger state when you start such a move, it will trigger immediately. Of course, there are trade-offs and so advantages and disadvantages to both approaches. Curt Wilson VP Engineering

[leopoldmaccon.de]

Hello, [quote='curtwilson' pid='476' dateline='1277395128'] So in the PMAC2 ASICs, we used a level-triggered capture. In this case, if you are in the trigger state when you start such a move, it will trigger immediately. [/quote] And this is the problem in my case: I have to measure the time between two external pulses (between index pulse of one axis and an external trigger) to synchronise the axis to the external event. Due to high precision requirements (~0.01°) it is not useful to capture just any time at the high level of the pulse. Right now I use a relative complicated plc to check the actual state of the pulse and to make sure afterwards, that the activating of the capturing does always take place at the low level. It works, but it is relatively slow. The order of the pulses is undetermined, so I have to wait a lot for the right state. This would be done with a real edge triggered capturing. Is there an easier way to measure the time distance between two external input pulses? I thought about using the MLDT-measurement, but this always started by the internal clock, so I would have to use two of these inputs and calculate. - I have just two standard ACC24E channels per axis, one is used for the common encoder, the other one measures the time as an up counter with 2MHz clock (external) and several capture inputs. Any hint is welcome - Dirk

[steve.milici]

The servo gate can be used to get the time between pulses as timed by the gates SCLK (set by I7m03). set the decode to pulse and direction decode and wire to the pulse to the encoder "A" channel the B channel is the direction. The first servo-gate y register is the "Channel n Time between last two encoder counts" in SCLK cycles - see Y$78000 in the memory map (Turbo SRM). [quote='leopold@maccon.de' pid='511' dateline='1278952872'] Hello, [quote='curtwilson' pid='476' dateline='1277395128'] So in the PMAC2 ASICs, we used a level-triggered capture. In this case, if you are in the trigger state when you start such a move, it will trigger immediately. [/quote] And this is the problem in my case: I have to measure the time between two external pulses (between index pulse of one axis and an external trigger) to synchronise the axis to the external event. Due to high precision requirements (~0.01°) it is not useful to capture just any time at the high level of the pulse. Right now I use a relative complicated plc to check the actual state of the pulse and to make sure afterwards, that the activating of the capturing does always take place at the low level. It works, but it is relatively slow. The order of the pulses is undetermined, so I have to wait a lot for the right state. This would be done with a real edge triggered capturing. Is there an easier way to measure the time distance between two external input pulses? I thought about using the MLDT-measurement, but this always started by the internal clock, so I would have to use two of these inputs and calculate. - I have just two standard ACC24E channels per axis, one is used for the common encoder, the other one measures the time as an up counter with 2MHz clock (external) and several capture inputs. Any hint is welcome - Dirk [/quote]

[leopoldmaccon.de]

That is a good idea, but... I have to get the time between pulses on different lines. Something like: "The index pulse of my axis has to occure 12ms after the external reference pulse connected to the user flag input" This is needed for controlling the position of a motor inside one revolution in conjunction to the external reference at higher speeds (>10000rpm). In my solution I use the possibilities of switching the capture line, but this is relatively slow and I miss some reference pulses. Nevertheless - using the pulse/direction decoding will make my pulse frequency measurement easier - thanks for that. Dirk