07-31-2012 07:34 AM
Thank you so much for your help.
But another question: Is it possible to define the number of pulses in a retriggerable single pulse task, in order to limit the number of retriggers?
08-01-2012 09:28 AM
See the frequency divider based on retriggerable pulses.
It uses internal output to route one counter to start another.
Also it tracks the change of the period and applies updates not on every iteration.
08-01-2012 10:18 AM
Konrado,
I've got just a few minutes while running a verification test.
There isn't really a simple way to limit the # of re-triggerings to do with a single pulse task. If you want to throw another counter or two at the job, there may be a way to do some further levels of timing signal indirection to get you there. However, I'm starting to wonder if I'm missing the forest for the trees because I'm not familiar with your field of study, and don't have a good sense of why you want to do things in the way you're outlining.
I would usually have recommended that you follow after Alexander's pulse-dividing method that uses retriggerable single pulses. However, those will be harder to limit to a specific #. The technique that would usually be used is a "pause trigger", but that won't be possible when the same input pin is already in use as a start trigger.
In this particular circumstance, my weirder method with the continuous pulse train may actually be a better choice. You could set up one more counter to generate a pulse with low and high ticks specified in # of trigger signals. Then you'd configure the continuous pulse train task I showed to use that additional counter's output as a pause trigger. With that sort of setup, you could have hardware control over the # of retriggerings you do.
However, before you try that, I'd highly recommend that you step back, take a deep breath, and start drawing up some timing diagrams of the signals you expect to measure and generate. I'm getting the feeling that we've incremented our way into a more complicated solution than the problem really needs. I could easily be wrong since I don't really know your context, but I've learned to treat such complex solutions with suspicion.
Gotta go, my test is 2 min from finishing.
-Kevin P
08-21-2012 07:43 AM
Hi, sorry for my late reply! I got it finally to work (without defined retriggers) but there are still some problems with the spectrometer. I think this is due to the fact that the spectrometer runs into a internal timeout but I don't know why. Furthermore there is still a lot of false triggering when changing to the next sample with a different delay.
So it's really time to take a deep and think about my program. At the moment I have a flat sequence with some for loops defining the number of measurings as well as the while loops for the triggering...
Well that's I want to do:
1. All the necessary data comes in a cluster from a different vi
2. Initialize: Create folders, calculate positions for the step motor and move it to the initial position, open spectrometer and so on
3. Start the speed measuring and calculation of delays
4. Measure the spectrometer dark current
5. Move step motor to the first position
6. Start retriggerable task for lamp and spectrometer
7. Measure at step motor position first sample, second sample and so on
8. Move stepmotor -> 7
9. Stop retriggerable task for lamp and spectrometer
10. Save data and wait for a specified time
11. Back to step 5
12. In the end: Close the spectrometer, stop the speed measurement and so on
Furthermore the data has to be displayed:
1. The actual scan
2. Step motor position dependent absorption for the actual scan as well as the former scans (by option)
So much for the theory. I thougt that maybe a produce/consumer patttern would fit but I have no idea how to realize this. Of course I have read a lot but I don't know how to do the triggering stuff and so on.
I would be so grateful if somebody could help me with the design of my program.
Thank you so much!
08-22-2012 01:15 AM
Hi, it's me again.
I have attached my main vi that you can see how I deal with this at the moment. Of course all the subvis are missing but the working principle should be clear.
Now I try to do two things. First I want to separate the data aquisition from the display and file I/O, second the data aquisition has to be seperated from the lamp and spec triggering.
Especially the second point seems to be very important because my spectrometer runs into some internal timeout (not because there is no trigger) after some minutes or hours (the exact time is not reproducible, but it does happen) and crashes my whole system. I don't know why but I hope so much that a more sophisticated vi pattern will solve this problem.
May you help me with this?
Thanks!
08-23-2012 12:29 AM
I think it would be better to move this to a new post because it is a different topic and it will be seen by more people.
Thanks all for your help with my trigger issue!