Pulse Synchronization and the Labview DEBUG IDE

[noobie_programmer]

Dear Sir:

      I am seeking to understand the Labview DEBUG Integrated Development Environment (IDE) using a X series DAQ.    I am trying to ascertain whether 2 output pulses are "locked in" on the rising edge - synchronized - by visual inspection using the Labview DEBUG IDE, or, at least, know whether am I on the right path to rising edge pulse synchronization.   

My specific question is: 

-  When the yellow DEBUG light bulb button is depressed and you see your Labview program operate in slow motion according to the "dataflow model" - what are the required "visual indicators" that you typically see which indicate to you that your output pulses are synchronized on the "rising edge."    Can this be determined by visual inspection, at all?   Let say you are a professor and you are quickly glancing over a student's program at his desk, what are the visual indicators that you will look for to indicate to the student that he is on the right path to edge synchronization - if any do exist.  

     Let me explain, I see 2 separate data flow paths ("tasks") simultaneously arrive the while loop.  What typically happens, is neither pulse signal will enter the while loop, until the other signal has arrived at the while loop.   Is this an indicator that edge synchronization has been achieved?   

      I have attached a "screen shot" of a program as a model for discussion.

      When you look at your program in  LABVIEW DEBUG mode, must you visually see that the dataflow arrive at the signal generating icons that are located within the while loop arrive at the same time as a pre-condition for possible pulse synchronization?

      I realize that the answer to this question may appear to be obvious, however, I would like verification from a NI engineer confirming what are the visual indicators that must be present, if any.   I don't make assumptions about software that I don't write and test myself - to be safe.      

      I would like to thank you for your consideration.   

[Kevin_Price]

Let's start with No.

And it's actually No in many different ways for many different reasons.

1. Very generally - observing highlight execution in the debug IDE will *never* be a definitive method to determine whether pulses are in sync.  Forget that approach, you can't get there from here.

2. Evaluating hardware sync from program inspection alone would depend on sufficient knowledge of DAQmx to observe the details of task config and to follow through with a correct understanding of the timing implications.   

    When using LabVIEW, it's generally important to have a solid grounding in dataflow as well.  This affects the execution sequence of DAQmx function calls, which can affect sync as well.

3. The execution sequence observed during highlight execution is not necessarily exactly the same as what will happen during standard execution.  I don't know all the nuances, but as a simple illustration -- under highlight execution, you never see 2 things execute in parallel.  Under standard execution, things *commonly* happen in parallel, the workload spread across multiple cores.

Using principle #2, inspection reveals that sync is not guaranteed in the code screencap.  If the AO task happens to be started first, you'll be close b/c the first CO pulse will trigger the AO task.  But if the counter pulse task happens to start first, you won't know which of the continuous CO pulses triggers the AO task.

At a finer detail level, there will be some very small delay from the AO task being triggered until the 1st sample is generated.  You'd achieve better sync between CO pulse and AO update if you used the CO pulse as the AO sample clock rather than as the AO trigger.

Finally, I'd tend to expect errors on the AO task.  One error for defining a buffered task but only writing 1 sample to the buffer.  Another (possibly) for starting the buffered task before writing any data to it.  (This second error may depend on whether or not the CO task is already running when AO starts, causing an immediate trigger before you get a chance to write data to the task.  Or it may happen regardless.  At least I would say you're *prone* to it.)

Further issue: an infinite While loop with no way to terminate and thus no possible way to be informed of any task errors.

-Kevin P

[noobie_programmer]

Dear Mr. Price:

      I am very happy to have read your reply.

        It is my belief that I may have posed some questions that may be difficult
for you to answer in one sitting and I would prefer not to pose some questions
about "task" and "rising edge" pulse synchronization at this time because I 

believe that it would inconvenience you.

       I would like to pose what I believe to be simple questions first. However,
the questions that I pose may not actually be simple to answer due my lack of
knowledge of how Labview operates "under the hood" so to speak.

           It is my belief that my approach is fundamentally in error with regard to the
utilization of the analog signal source. I downloaded an example from a NI webpage
and I "modified" it. When I first read the title of the original program that I downloaded,
I thought that its performance may be sufficient for my needs.

        However, after conducting some tests at approximately 200 KHz I saw the slope of the rise time of the analog signal source decrease, while the slope of the rising edge of the pulse train signal remained constant.    I am led to believe that the analog signal source is inherently deficient for high frequency applications.

Can you tell me if this theory is correct, or not?

        If you believe that a digital signal source would remedy my slow rising edge issue, can you point me to a *.vi that contains all the required elements so that I can do a simple cut and paste and remedy my "slow rising edge" issue.  In ideal, I would prefer a digital signal source whose pulse width may be adjustable, however, in the interests of efficiency and simplicity, a digital signal that resembles a step signal would probably make this discussion go a lot faster.

         I am very grateful that you have replied to my post.   Your feedback is appreciated.

[Kevin_Price]

Please explain this thing you call a "slow rising edge".   Your earlier phrasing, "the slope of the rise time of the analog signal source" wasn't entirely clear to me either.  

Honestly, I *don't* particularly want to go through many successive rounds of so-called simple Q&A that may (or may not) eventually get you to the main things you really care about.  I personally tend to avoid such threads because of how often they go wandering off into the weeds.

So let's please jump to the end game.  What exact end result do you want from these CO and AO signals?  How closely do your edges need to be sync'ed?   And what kind of system are you working with to make all this important?

    I ask these questions b/c it's fairly common for questions to show up here where the user assumes they're basically on the right track and just need a little boost.  But then after lots of back & forth, it turns out that what they really *need* is to change tracks to a different approach that's simpler to implement and does a "good enough" job satisfying their requirements.

    I try to clarify at the beginning, rather than risk following down a path of the users' choosing when I already know the terrain but I'm not yet sure if they do.

I mean all this in friendly terms.  Just letting you know where I'm coming from.

-Kevin P

[noobie_programmer]

Dear Mr. Price;

        It is my hope that you will understand that I could not have obtained a definitive answer with regard my question about the Labview DEBUG IDE unless I had posed this question at this discussion forum.   What often appears to be "obvious" is not.   I am grateful to know the limitations of the DEBUG IDE.

      Knowing the limitations of the Labview DEBUG IDE now raises the question of verifying rising edge "synchronization" since this cannot be ascertained by utilizing the Labview DEBUG IDE.

      I have attached 2 screen shots of the "rising edge" outputs sourced from my *.vi using an oscilloscope. The rising edge, oscilloscope "screen shots" were taken at pulse train frequencies of 200 Hz and 200 Kilo*Hz.  Looking at the 200KHz oscilloscope screen shot will answer the question that you had raised earlier in your last post.

      If you look at the rising edges of the analog signal and the pulse train at 200 Hz, one may be "led to believe" that "rising edge" synchronization has been achieved and if you look at the rising edges of the analog signal and the pulse train at 200 Kilo*Hertz, you will clearly see that "rising edge" synchronization has not been achieved.

        I believe that there are 2 reasons why "rising edge" synchronization has not been achieved.  It was my belief that the "rise time" of any analog output signal would be limited by the signal source hardware itself, the digital to analog converter (DAC), located on the PCIe 6321 DAQ (X series)  that I am using for this experiment.

      It is my belief that a digital signal source would provide me better high frequency performance which is why I made this request:

"... can you point me to a *.vi that contains all the required elements so that I can do a simple cut and paste and remedy my 'slow rising edge' issue ..."

I was hoping that you would have a *.vi available, as the request that I am making is for a rudimentary operation, essential for the elementary operation of any DAQ.  It is my belief that you would probably know of one readily available at NI that would fit the needs of our discussion.

      There exists a 2nd reason why I do not believe that "rising edge" synchronization has not been achieved, however, I believe that discussion would be appropriate after I had substituted the analog source for the digital source and tested the *.vi again.

When you wrote:

"it turns out that what they really *need* is to change tracks to a different approach that's simpler to implement and does a "good enough" job satisfying their requirements"

It is my belief that I had already identified that I needed to change my approach, before you wrote your reply, when I noticed that the rise time problem using the analog signal source was probably due to utilizing a DAC, instead of using a digital signal source.  Unfortunately, the *.vi that I modified and uploaded to you was the only *.vi that was available to me.   A search for an appropriate *.vi(s) was conducted and none was found.

      I wanted to clean up the *.vi I was working on first, take care of all the "potential" issues that could hinder a meaningful discussion on the subject of "rising edge" synchronization, such as the "infinite While loop" that you had mentioned, before proceeding any further with this discussion.    An improvement in the while loop which would facilitate the reading of any possible error messages would most certainly facilitate our discussion.   Perhaps, you can link me to a *.vi that has remedy for the while loop structure that is currently in place.

       If you believe that my only option is to use an analog signal source, I would be interested in knowing why you believe this to be the case. I would like to achieve "rising edge" pulse synchronization at the highest frequency available to me - any improvement in the "closeness" between edges over 200 Kilo*Hertz would be an improvement over the current state.    Experimentally verifying the "limitations" of my DAQ will lead to stable future designs.

         I hope that I have answered all your questions and I look forward to reading your response on how to better improve the design of my *.vi.

[Kevin_Price]

So...

Maybe I'm not your guy.

The course of my career includes a relatively short stint in a highly academic environment.  My assessment of my time there?  Despite a 4.0 Master's degree in Engineering (at Purdue BTW, not some podunk no-rep place), I was pretty much considered a "mouth-breather", worthy of no intellectual respect.  My technical opinions (often NI-oriented) were regularly disregarded and overruled.  (Possible exception?: Hi, Scott S.)   Meanwhile, I've continued to have a well-respected track record on these NI forums and other work places.  So I haven't fully accepted that "mouth-breather" assessment.

And I consequently no longer hold academia in automatic high esteem.  In fact, as in most areas of life, I start with suspicion.  Prove to me you're worth some time, THEN I'll give you time.  In this thread, we aren't quite there.  But I'm not giving up either.

In your 200 kHz scope pic, I see a roughly 1-2 microsec AO rise time, depending on criteria.

You still didn't answer my (possibly mouth-breather) question: why do you care?  What makes you so concerned about the microsec-ish time it takes AO to rise from 0 to target voltage?  Really and truly -- what's the effect?   Yes, I *do* know it *can* matter.  But also, I know that it often doesn't.  Convince me.

Have your tried DO instead of AO?

Have you tried using the CO pulse output as a sample clock instead of using it as a trigger for your AO or DO task?

Have you characterized the impedance of whatever-it-is that you drive with your AO signal?  Do you know how THAT contributes to the signal's rise time?

Hey, I don't know everything, and I *know* I don't know everything.  I'm sometimes wrong on the things I *think* I know.  I'm just here looking to help, but also not accepting any obligation to see things through to conclusion.

-Kevin P