LabVIEW
DAQ trigger for labview
Hi Dushyant,
I went ahead and drew a diagram based upon your description. If there is anything incorrect please let me know. During the time that the motor is operating between positions A and B, you are generating TTL pulses. Do you have the ability to control that no pulses occur before A, and that they do not occur after position B has been reached? If this is the case, I believe that you will want to use your TTL signal as the sample clock and not as a trigger. By defining your acquisition to use an external sample clock of approximately 1kHz (1/1ms), the acquisition of points will not occur until the first pulse is received and will stop acquiring when no additional pulses are received. What DAQ device will you be using in your application?
Regards,
Andrew W
National Instruments
I went ahead and drew a diagram based upon your description. If there is anything incorrect please let me know. During the time that the motor is operating between positions A and B, you are generating TTL pulses. Do you have the ability to control that no pulses occur before A, and that they do not occur after position B has been reached? If this is the case, I believe that you will want to use your TTL signal as the sample clock and not as a trigger. By defining your acquisition to use an external sample clock of approximately 1kHz (1/1ms), the acquisition of points will not occur until the first pulse is received and will stop acquiring when no additional pulses are received. What DAQ device will you be using in your application?
Regards,
Andrew W
National Instruments
Message Edited by TheWoost on 08-07-2007 01:08 PM
Hi Dushyant,
You are essentially wanting to merge software and hardware timing together, and given the requirements of your application I don't think you can achieve the precision you want with a finite (N sample) acquisition. Ideally, your motor controller would produce a digital pulse when the motor reaches position A, and then you could trigger your analog acquisition with this digital pulse. However, it appears as though you are obtaining a device status via GPIB, and then with this status you are determining whether or not to start the acquisition.
If possible I think your best bet would be to obtain a timestamp when your motor crosses points A and B, while during the whole program execution performing a continuous acquisition with your DAQ card (such as that I reference in my earlier post), and then go back at a later time and throw away the data before the timestamp for position A and after the timestamp for position B. From a programming standpoint, the part of your code pictured below actually becomes an infinite loop if the original value passed into it is "False", so you will want to modify this portion of the code. In addition, please be very careful with using local variables in your code as you may run into situations where you read from the variable when it has not yet been updated. Given the level of control you need from this application, using too many local variables can make debugging a nightmare.
As far as modification of your motor controller code, perhaps contacting Newport or posting the GPIB forums would be more suitable. My overall recommendation would be to have parallel while loops running, one of which is handling the motor controller code and the other that is performing the data acquisition.
Regards,
Andrew
You are essentially wanting to merge software and hardware timing together, and given the requirements of your application I don't think you can achieve the precision you want with a finite (N sample) acquisition. Ideally, your motor controller would produce a digital pulse when the motor reaches position A, and then you could trigger your analog acquisition with this digital pulse. However, it appears as though you are obtaining a device status via GPIB, and then with this status you are determining whether or not to start the acquisition.
If possible I think your best bet would be to obtain a timestamp when your motor crosses points A and B, while during the whole program execution performing a continuous acquisition with your DAQ card (such as that I reference in my earlier post), and then go back at a later time and throw away the data before the timestamp for position A and after the timestamp for position B. From a programming standpoint, the part of your code pictured below actually becomes an infinite loop if the original value passed into it is "False", so you will want to modify this portion of the code. In addition, please be very careful with using local variables in your code as you may run into situations where you read from the variable when it has not yet been updated. Given the level of control you need from this application, using too many local variables can make debugging a nightmare.
As far as modification of your motor controller code, perhaps contacting Newport or posting the GPIB forums would be more suitable. My overall recommendation would be to have parallel while loops running, one of which is handling the motor controller code and the other that is performing the data acquisition.
Regards,
Andrew
Message Edited by TheWoost on 08-10-2007 04:18 PM
