I think the problem is the way you are setting up the timing in your "measure device" loop. That loop has no timing built into it whatsoever. You are relying on iteration counts to determine when you are going on to each state. The iteration number is determining which state you are in based on an awkward case structure. You've tied your states to iteration number rather than to time. If you change your timing, it forces you to redo your case structure and rebuild your "states".
There is some timing going on in that loop. Any given iteration is going to take as long as the code in it takes to run. But the only thing that could cause those iterations to take longer is the DAQmx code waiting for a sample to come in. This is where your timing breaks down. You start your DAQ tasks in the first loop with continuous samples. So during those 3 seconds, you've started accumulating samples at a rate of 10 Hz. By the time your code gets to the read portion, some of those samples may have already been acquired. You may have read 5 samples or so in the DAQ buffer before you read the first one. So that iteration will occur quickly, so will the next and the next, until the number of iterations of your acquisition loop have caught up to all the data that is acquired. From there on out, the loops will slow down to your intended pace of waiting for the sample to come in and then reading it.
What you need to do is set that measure device loop to be a state machine. Take the time before it starts and store it in a shift register, then compare the current time to that value and determine when all the transitions need to take place. You may want to read all the samples in the DAQ buffer right as the loop starts (rather than 1 at a time).
