help with RTSI

[whatsthis4]

I'm using labview 5.1.1 on windows98. The bmp diagram attached is for integration of RTSI with DAQ.

Currently my program is exactly the same as displayed but with "dont drive RTSI line" as the source (it was just a guess) and all other inputs accounted for. I have several questions:

(1) Motion occurs smoothly but no data is displayed on the waveform graph. The output to the graph on the vi diagram is always displayed as "#0X1" which I'm assuming is zero data points. Does anyone have any idea why this might be the case, and how does one choose the source/destination on the Select Signal VI?

(2) I was wondering why the number of scans should be set to a quarter of the target postion as suggested in the diagram?

(3) I am planning sinusoid
al motion on an axis and the implementation of start and stop program flexmotion functions instead of a single move, and would like to know how important the relative positioning of program storage, commencement and termination would be in this block diagram.

(4) In this case then, how do I get motion and DAQ to stop after a specified time? Does the time limit have any bearing on this?

Thank you all for your time

[RIO-Todd]

Greetings,

I work with our data acquisition devices and so I will try to help you with the DAQ section of your questions.

1. You will need to send a signal over the RTSI line or the DAQ device won't be receiving an external clock. The source of the Select Signal VI will need to be an encoder signal that will be routed to a RTSI line. The DAQ device will then be configured to use that RTSI line as an external clock. Therefore, if you aren't routing anything to RTSI 0, the DAQ device will never acquire data.

2. You are routing one of the encoder signals thru RTSI to the clock of the E Series device. With encoder signals, 4 counts of motion correspond with just 1 pulse of an encoder signal. So, if you set the target position to 4000, the encoder signal
you're routing over RTSI will only be pulsing 1000 times. That means that the DAQ device will be taking 1000 readings and so if you want to take every A/D reading, you'll want to set the number of scans to acquire to be 1/4 of the target position.

3,4. With regards to stopping the DAQ device -- the DAQ device will keep acquiring data if you are giving it an external clock. Therefore, if you alter the motion part of the code and still want to sychronize with DAQ, you still just need to share an encoder signal over RTSI. If you know how many total position movements will occur, you will just need to take that total position number divided by four to determine how many scans to acquire with DAQ. I hope this helps.

Regards,

Todd D.

[Anonymous]

Hi there,



I have previously used an encoder as sampling clock to get displacement
equidistant measurement instead of time equidistant measurements.



ONE BIG PITFALL: The clock cannot distinguish forward movement from
backward movement - hence jitter becomes a problem.



Regards

Hans Christian Olesen




"toddd" skrev i en meddelelse
news:5065000000050000000A1E0100-1042324653000@exchange.ni.com...
> Greetings,
>
> I work with our data acquisition devices and so I will try to help you
> with the DAQ section of your questions.
>
> 1. You will need to send a signal over the RTSI line or the DAQ
> device won't be receiving an external clock. The source of the Select
> Signal VI will need to be an encoder signal that will be routed to a

> RTSI line. The DAQ device will then be configured to use that RTSI
> line as an external clock. Therefore, if you aren't routing anything
> to RTSI 0, the DAQ device will never acquire data.
>
> 2. You are routing one of the encoder signals thru RTSI to the clock
> of the E Series device. With encoder signals, 4 counts of motion
> correspond with just 1 pulse of an encoder signal. So, if you set the
> target position to 4000, the encoder signal you're routing over RTSI
> will only be pulsing 1000 times. That means that the DAQ device will
> be taking 1000 readings and so if you want to take every A/D reading,
> you'll want to set the number of scans to acquire to be 1/4 of the
> target position.
>
> 3,4. With regards to stopping the DAQ device -- the DAQ device will
> keep acquiring data if you are giving it an external clock.
> Therefore, if you alter the motion part of the code and still want to
> sychronize with DAQ, you still just need to share an encoder signal
> over RTS
I. If you know how many total position movements will occur,
> you will just need to take that total position number divided by four
> to determine how many scans to acquire with DAQ. I hope this helps.
>
> Regards,
>
> Todd D.

[whatsthis4]

Thanks for your quick reply. It was quite helpful. Would it possible to acquire daq (about 500msec max ) before any motion has begun, given that daq is clocked to position?


Chris

[Anonymous]

Hi Chris,

As I understand it you have routed the encoder signal over the RTSI bus to
the DAQ clock and uses external clock for the scan clock. This is done to
get the same distance (radians and inches) between the samples. Now you want
to prior to the distance equidistant measurement to make a 500 ms time
equidistant measurement. I don't know your system and that might be why I
don't se the logic in this. You say you want to clock the DAQ to position
????. It could be done by rerouting the scan clock back to the internal
clock first and then to the external clock (the encoder) but I don't think
it could be accomplished "bump less" As far as I remember you can only
change the scan clock source "offline" so you have to stop the DAQ and
restart it when the clock source has been routed to the encoder.

Another approach to accomplish what you want is to make synchronous sampling
of the analog channels and the counter values. Then you have two (or more)
time equidistant measurements - one for the encoder position and one for the
analog channel. Afterwards you can use the encoder position as x-value. This
approach also solves the problem I mentioned with jitter because you have
all positions of the encoder measured. It also gives you the possibilities
of using triggers and utilizes the functions with pretrigger scans. The
drawback is that it's a bit tricky to make the code for synchronous sampling
of Analog inputs at counter value. I started a project of this some years
back but never finished it so I don't now exactly how to accomplish this
setup. I'm sure it can be done. Some thing like this - Use the scan clock
from the AI DAQ to gate the counter and make buffered DAQ on both. Then use
read buffer and take good care when setting the read position so they run
synchronously.



Best regards

Hans Christian

"whatsthis4" skrev i en meddelelse
news:506500000005000000A31F0100-1042324653000@exchange.ni.com...
> Thanks for your quick reply. It was quite helpful. Would it possible
> to acquire daq (about 500msec max ) before any motion has begun, given
> that daq is clocked to position?
>
>
> Chris

[Anonymous]

Hi Chris,

Take a look at a this counter example: Measure Buffered Position (NI-TIO).vi

In the "gate setup" VI it must be possible to get the counter gate from the
scan clock of the AI DAQ device.

Regards Hans Christian


"whatsthis4" skrev i en meddelelse
news:506500000005000000A31F0100-1042324653000@exchange.ni.com...
> Thanks for your quick reply. It was quite helpful. Would it possible
> to acquire daq (about 500msec max ) before any motion has begun, given
> that daq is clocked to position?
>
>
> Chris

[whatsthis4]

Hi there again

I now have an even more pressing problem...!

The DAQ rate on my E-series is not high enough for my purposes! As far as I understand, acquistion is (currently) determined by the encoder pulses (4 counts of motion per pulse). I need the DAQ rate to be higher (eg - daq at every count) without changing any characteristics of my motion profile. Is this possible?

If this is not possible then the alternative I am interested in is timebased....

1) Starting DAQ on my E-series, then approx 100-200ms later, start my motion (stored as a program) - maybe this gives you a better idea what I was trying to do before

2) Or starting DAQ and motion at EXACTLY the same time (time based daq as well)

How would I go about this?


Once again thank you for your time

Chris

[Anonymous]

Hi Chris,



If a gate rate of the same rates as the encoder counts (4 times the numbers
of pulses) is enough you need to take a look at the following application
note from NI:



http://zone.ni.com/devzone/conceptd.nsf/webmain/6F25CBA2CD73417786256869005E5FC3/$File/AN084.pdf



This note explains how to convert the quadrature encoder signals into a
single pulse signal. There you have distance equidistant clock signal based
on the count frequency (4 times the pulse frequency). BUT still you have the
problem with jitter. Are you familiar with what jitter is?



If you use the time based solution I see no problem starting the DAQ before
you start the motion program. In the matter of fact you should do that. Take
the AI scan clock and route it to the gate of the counter and make a
buffered acquisition of both the AI and the counter. Take care when you read
the buffered data to make sure the reading from the buffers are done
synchronously. You could make some functionality to have the motion
program/system trigger the DAQ system 200 - 500 ms before actually motion
starts.



With the hope of your success

Hans Christian Olesen





"whatsthis4" skrev i en meddelelse
news:5065000000050000001E200100-1042324653000@exchange.ni.com...
> Hi there again
>
> I now have an even more pressing problem...!
>
> The DAQ rate on my E-series is not high enough for my purposes! As far
> as I understand, acquistion is (currently) determined by the encoder
> pulses (4 counts of motion per pulse). I need the DAQ rate to be
> higher (eg - daq at every count) without changing any characteristics
> of my motion profile. Is this possible?
>
> If this is not possible then the alternative I am interested in is
> timebased....
>
> 1) Starting DAQ on my E-series, then approx 100-200ms later, start my
> motion (stored as a program) - maybe this gives you a better idea what
> I was trying to do before
>
> 2) Or starting DAQ and motion at EXACTLY the same time (time based daq
> as well)
>
> How would I go about this?
>
> Once again thank you for your time
>
> Chris

[Anonymous]

Hi Chris,

Also tak a look at this snippet from NI Developer zone:

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RNAME=ViewQuestion&HOID=506500000008000000233C0000&ECategory=Measurement+Hardware.Counter%2FTimer

Regards
Hans Christian

"whatsthis4" skrev i en meddelelse
news:5065000000050000001E200100-1042324653000@exchange.ni.com...
> Hi there again
>
> I now have an even more pressing problem...!
>
> The DAQ rate on my E-series is not high enough for my purposes! As far
> as I understand, acquistion is (currently) determined by the encoder
> pulses (4 counts of motion per pulse). I need the DAQ rate to be
> higher (eg - daq at every count) without changing any characteristics
> of my motion profile.
Is this possible?
>
> If this is not possible then the alternative I am interested in is
> timebased....
>
> 1) Starting DAQ on my E-series, then approx 100-200ms later, start my
> motion (stored as a program) - maybe this gives you a better idea what
> I was trying to do before
>
> 2) Or starting DAQ and motion at EXACTLY the same time (time based daq
> as well)
>
> How would I go about this?
>
> Once again thank you for your time
>
> Chris