Timed sequence doesn't work right with external timing source

[GS]

I'll describe first what I want to accomplish and then maybe someone can read further and suggest why the attached VI doesn't work. I have a SMU (PXI 4130) that takes differing amounts of time to set a current depending on if the setting spans a range boundary. I want to be able to make that SMU setting and then wait a specific amount of time (sometimes 1 msec). If the SMU takes a little longer to return then I want that extra time to come out of the wait time. To do this I figured I would need an external time source to control a timed sequence to give better than the normal 1 msec resolution. So now onto the problems I'm having.

I've got two problems here that I would really appreciate some insight on. The attached VI is the subject of both problems (as is the VI is worthless, but it illustrates the problem). Note that you need some type of DAQ board with a counter on it to run it.

I can't figure out why this timed sequence doesn't work with an external timing source. It works mostly as expected (see next problem) with the internal source, but fails miserably with the external source. Run the VI as is to get a baseline. Then connect the DAQmx Create Timing Source VI to the Source Name input of the timed structure. It seems like it should run exactly the same both ways.

Problem 2 (run with the internal timing source). The VI should take the same amount of time to execute regardless of the input to the Wait VI (within reason of course). That's actually the main impetus for this whole exercise. But according to the Actual End indicator it runs faster with a longer wait time.

George

[Chris_K_]

Hi George, I have been playing with the code that you have posted and I think I am seeing what your concern is with regards to the first problem that you stated.  Without running the code I would expect both internal and external timing to cause the VI to run in the exact same manner, however obviously that is not the case.  I am currently looking into this behavior and I will post you a response as soon as I have an answer for you. 

As for the second problem, If you look at the manner in which you have coded this VI, a 1ms wait in the first frame will lead to a calculation of 1999ms wait in the second frame, and thus 5 iterations of 1999ms or about 99,995ms total running time.  If you increase the wait in the first frame to say 50ms, then an overall all wait of 1950ms is calculated in the second frame so not the overall iteration time is now 1950 which, over 5 iteration leads to 99,750ms thus as you increase the wait in the first loop the overall loop duration will be less.  This is expected behavior.

Again I will post back once I have a clarification on the internal vs external timing.

Chris_K 

[GS]

Thanks for looking into this. I've been playing with it some more and still can't understand why it doesn't work - unless it's a bug.

Regarding the second problem. I guess I don't understand how the Start input at the end of the second frame works. In the case of the 5 msec delay in the first frame, a delay of 1950 msec is computed in the second frame. I understood this to mean that the third frame would start executing 1950 msec after the start of the second frame based on the help for this input:

Start—Specifies the time the next frame must start executing. Specify a start time value relative to the start time of the current frame in units of the frame timing source.

It seems that you took it to mean the timing of the overall frame. Which is correct? If your intrepretation is correct, then how can I do what I wanted which is this - delay a specified amount of time for the whole sequence regardless of how long it takes the first frame to execute (within boundaries of course).

George

[Brinoceros]

Hi George,

Your thread has come to my attention, and you certainly raise valid points!  The behavior of the Start input seems inconsistent with the Help documentation you quoted.  I tried this reading the Expected Start instead, and it gave a value relative to the previous frame as the documentation suggests.  However, when reading the actual start it seems that the Start input is relative to the start of the whole structure (as you noted). 

I will look at this a bit more and see what I can come up with for you.  And if you come up with anything more, feel free to share it!

[Brinoceros]

Hey George.  Here's what I have come up with for you:

Currently, the behavior of the Start input is in fact inconsistent with the documentation.  The Start input is supposed to specify a count relative to the previous frame, but instead is relative to the entire timed structure.  This has been reported to R&D (#95682) for further investigation.  However, it isn't to difficult to work around.  In one frame just read the Actual Start, add an offset, and wire that to the Start input for the next frame.

In response to your original Problem 1:  I believe this is functioning as expected, but maybe I am missing what you say "fails."  Perhaps what needs to be considered is that the Wait (ms).vi is a software timed delay.  This means that 50 wired into this VI may not produce a delay exactly equal to 50ms (Windows is not a deterministic OS).  So this 50ms delay will not necessarily equal 50 ticks for the timed structure when the source for timing is an actual hardware signal.  Does this explain what you are seeing?

Finally, I think you can accomplish what you are trying to do by playing around with the Input nodes of the frames of this timed structure, just a bit more.  Specifically try using the Deadline/Timeout inputs.  I think those Inputs will have what you are looking for!

I hope this helps!