02-23-2014 04:47 PM
Hi everyone,
I'm completely new to this forum, thanks in advance for any suggestions. I have two state machines that I am using to move XY translation stages, fire a laser, and read motor position. The first state machine is used to move the motors to the position that is read from a pre-written file. That seems to be working ok. The second state machine askes if the motor is moving and if it is between a specified range. If it meets the correct conditions, the state machine then moves to the "fire" state, where a pulse is sent from my Measurement Computing USB_1208FS dAq and fires the laser. The trouble i'm having is, I can't get the laser to fire more than 30Hz. I look at the signal being generated by the dAq and it's coming out about every 32mseconds. As I understand it, this is how fast the state machine is running. My question is, looking at my vi, are there any huge mistakes that I've made that would slow down this operation? Thanks, I'm using motors and stages from ThorLabs, so without the drivers (which can be downloaded for the TDC001 t cube motor controller) the vi might not look right.
02-23-2014 08:35 PM
In your Fire and Read Energy state, you are configuring your DAQ port in every iteration of the For Loop. Why? Port configuration can be a time consuming operation.
Your DAQ ports should be configured when the program begins.
02-24-2014 12:46 PM
Thanks for the suggestion RavensFan. I tried pulling the config vi out of the state machin (out of the while loop) and it stopped firing the DAQ. I agree that it's probably using up some cpu, but in the past I would have the same block (config and DOUT vi) inside a FOR loop that would run 50 times with a 20ms wait (50Hz) and it would run no problem. I'm thinking it might be the property nodes that ask the motor if it's running or not that's taking up most of that 30ms time.
02-24-2014 01:18 PM
Next step is figuring out what time some of those functions are taking. Put in Timer functions throughout the code before and after sections you are concerned about. (You may need to put them in single frame flat sequence structures with wires running through them to control when the timer value is captured.
Subtract the Before time from the After time. See where the time is being taken.
02-24-2014 01:33 PM
I placed the motor positioning vi and the motor moving vi in a flat sequence seperate from eachother. I then placed a "Tick Counts" in each of the frames and subtracted them from one another which gave a value of 16mseconds. Since these two property nodes set the condition for when to enter the "Fire & Read Energy" state, (which fire the DAQ) I thought if I removed one or the other it may speed up the firing rate. Removing either of these nodes increased the rep rate from about 30Hz to 60Hz. Unfortunately I need both of these conditions to be met, so maybe I'm stuck at this rate?
02-24-2014 01:41 PM
I also measured the time between the daq config and DOUT vi, which was between 1-2mseconds.
02-24-2014 07:22 PM
How quickly do you need that loop to iterate? How fast is the motor moving?
It seems like the motor would not move so quickly that you need to detect that it got within position within 30 msec.
Do you need two different state machines? It seems that the the X moves are inherently linked to the Y moves.
How many times is the laser supposed to fire? Right now your For Loop fires the laser only twice, then goes back to the state where it determines if X is moving.
02-25-2014 09:36 AM
How quickly do you need that loop to iterate? How fast is the motor moving?
I would like the laser to fire at twice it's current rate. So, 60Hz (about once evert 16 mseconds)
The motor ramps up to a speed of 0.5mm/second, but only travels 2-3mm.
It seems like the motor would not move so quickly that you need to detect that it got within position within 30 msec.
I'm using these components to basically lithograph a sample. The position is crucial and so iterating the position vi as quickly as possible is a must.
Do you need two different state machines? It seems that the the X moves are inherently linked to the Y moves.
This is certainly true, however, I originally had everything in one state machine and the DAQ would pulse the laser very sporatically. I found that seperating the two made things run much smoother.
How many times is the laser supposed to fire? Right now your For Loop fires the laser only twice, then goes back to the state where it determines if X is moving.
The For Loop was an attempt to double the firing rate (a failed attempt). The DOUT (pulse the laser) case only takes about 1msecond to complete, so I thought if I added two pulses with a wait time, I could potentially double the rep rate. It didn't work out.
02-25-2014 11:30 AM
Are there times where you want the motor to move, but the laser to not fire?
I think you need to decouple the laser further. Let it operate entirely within its own loop. Don't do any motor communication in that loop.
Keep all the motor communication in its own loop. When the motor communication loop detects that it is in a position to turn on or turn off the firing of the laser, then it can send a notifier from the motor loop to the laser loop. If you need to determine when then the motor is in position more rapidly than 30 msec, then you are going to have a problem because the motor comms aren't allowing you to update the motor position that fast. But how far does the motor move in 30 msec? How does that relate to your desired position accuracy for when the laser turns on and off?
The motor comm code you have seems to have some commands to issue an absolute position move, and also have a boolean to tell it to wait. What if you used those? You can precisely tell it how far to move, and have the code waits until it gets there. When the code comes back, then you can issue the command to turn on or turn off the laser.
02-25-2014 01:30 PM
I'll try this, should I use a local vairable and the notifier?