Placing the trigger 'dot' on a time waveform

[Bob_Schor]

Egad -- I meant to mention this earlier, but the only thing I can think of that is worse than sending a Picture of your Code instead of the Code Itself (i.e. a VI) is to send a Picture embedded in a Word Document.  I'm going to "throw a hissy fit" and not open any .docx files (I made that mistake once, but as I said, forgot to mention it).

Send me the VI, please, and I will be happy to look at it.  I see that you may also have other issues related to understanding how/what to do with the Trigger signal, but let's try to resolve getting the data input properly first.

Before you send your code, think about and clarify the scenario of your setup.  I understand that you have a digital pulse that may or may not "do something".  Here is what I think you might be doing (so correct any mis-impressions):

• You are using LabVIEW to generate TTL pulses (presumably using a DIO line on some piece of DAQ equipment) that is going somewhere and generating a "stimulus".  [You might also be generating this using an Analog Out, in which case it may or may not adhere to TTL standards, but you'll clarify].
• You are recording on two analog lines the following signals:  the behavior of some piece of equipment or subject that is receiving the stimulus generated by the TTL pulse, and the output of the Pulse Generator in the previous step, used as a Stimulus or Trigger.
• Even if Assumption 1 is totally false, that is, you are generating TTL pulses to provide Triggers, but LabVIEW isn't generating them, LabVIEW is still monitoring them as in Assumption 2.
• You now want to do Peak Detection on the Trigger channel, determine when the Pulse starts, and "mark" the "Analog" (or "Response") channel with a Red Dot. 

Some observations -- if the Trigger Pulse is providing the timing of interest, you don't really want to do peak determination, you want to determine the Positive Edge time, a much easier task, but a different one, with different assumptions.

Bob Schor

[Coryman]

Sorry!!!!  Eventually, my vi will take in data from an SCC 2345 front end with accel modules and one analog voltage input module for the tach.  I have checked, and as long as I turn off the ICP power output on the module, the ACC01 input modules act just like analog voltage input modules.

I redid my experimental vi so that I am using the same waveform generators you use.  What I have now is the trigger dots are overlaid at the correct time spacing, but they are sitting at amplitude of zero, not riding on the sine wave.  This is VERY close to what I want.  I am sending the vi.

[Coryman]

Expand the graph out to a max of 0.1 on the time line.  You will see the red dots sitting in space.  The need to be sitting on the sine waveform.  So I have been trying to get the dots to get their amplitude from the sine wave information, but when I do that, I get a sine wave of data and the dots end up riding their own sine wave that is approximately 1/5 the frequency.

Ron

[Bob_Schor]

OK, this is really pretty interesting.  You made a very strange Trigger Signal, huge amplitude, strange phase, I'm not sure what it was supposed to be doing, but then you found the peaks of the trigger.  But you already know where they are, they are leading the sinusoid by 45° (because you told them to), but it might not show because you didn't set the Reset Input to True (which is needed to set the initial Phase).

Here is VI from Bob.  I'm sorry it's only a picture, but I'm currently using LabVIEW 2018, and I think you are on 2015, so my VI wouldn't work on your version.  I'll explain the changes and "why".

First, notice the True going into the top of the two Generators to make them use the phase.  I made the "Trigger Phase" -90 so it would coincide with the peak of the sinusoid.  I also widened the Duty Cycle -- at the higher frequency of 60 Hz, and at 1KHz sampling, you could have the points "miss" the 5% duty window and not get a pulse on some cycles -- 10% fixed that.

Now, I'm just using the Trigger as a "pulse", so I want to know when it goes positive "rising edge".  I just subtract adjacent edges and if they are >0, I say "Plot it", else I make it NaN.  Note this is "sloppy math" -- one should never expect that subtracting Floats will give you 0, but sometimes you can be sloppy.  Note that to handle the 0th point, I say the preceding point was at infinity.  Oh, yes, I also changed the size and offset of the Pulse to match the Sinusoid, so the Pulse now sits on the Peak.

So I'm going to try one more time to see if I "get" what you really want.  

You have two signals.  One is a Stimulus (or a Trigger), the other is an Ongoing Response (data).  The Trigger is a pulse of some size, being sampled at the same time as the Response -- what you want to see is a plot of the Response, with a Red Dot on the Response at the point of the Trigger.  Is that correct?

So we proceed as before, but with Gaussian Noise instead of a Sinusoid (so you'll Know Its Real).  I modified Trigger by resetting the Phase to 0, and also initializing the For Loop's Shift Register to 0 (so we catch the first pulse).  The code is the same, except we put in the "Trigger" array the corresponding Signal point (which we have to bring into the For loop).  The other change I made was to make the Red Dots into Red Squares (no politics here, the Squares are a little bigger and easier to see).

Is this what you are looking for?

Bob Schor

[Coryman]

Bob,

Sorry, but no.  I have attached a png of what I am looking for.  The last vi I sent you was almost spot on.  All I need to do is literally 'make' that dot part of the sine wave.  All of your examples place the dot somewhere in the vicinity of the waveform, but it's not still 'in' the sine wave.  

And, yes.  I need to use signal generators because I don't have a data acquisition front end or a rotor kit.  So, I need to use signals and as a result I know what the signals are.  When my vi takes data in the 'real world' it won't know amplitudes, frequencies or phases.  I do know that the frequencies will be exactly the same and I know the trigger pulse will be large (over 1 volt), where the sine wave signal will be small (approx. 200-400 mvolts).  So, please look at the attached png file.  One other thing about the picture.  It shows a trigger pulse that is negative.  That depends on the trigger type utilized and doesn't change what the sine wave with the trigger point on it looks like.  That will be adjusted up front when the user inputs his hardware specifications.

Thanks,

Ron

[Coryman]

Sorry, I missed your second code at the bottom of your reply.  Yes, now the trigger falls on the data, but when I tried a sine wave, there is still a small 'ripple' in the position of the trigger dots.  It's almost like they are riding on a low frequency sine wave of their own.

[Bob_Schor]

I think you are seeing an artifact, but without seeing the code, I can't explain it.  Why don't you just attach the VI that made the picture?  That way I could run it, see the Front Panel, look at the code, fix (and explain the fix) the code, and we'll both learn something.

And now I understand (better) what you want.  You have two "free-running" signals, a Trigger (which can be either positive or negative going) and a Signal (and we might as well say you are interested in either the positive or negative peak, why not, it's only another Boolean switch).  I'll assume you want to plot both Signal and Trigger, but also want to put a Red Dot (or Square) on the Signal at the point of the Trigger, and maybe a Blue Dot (or Square) on the Signal at the point of the Peak.  As a bonus, we could also save pairs of times for Trigger and Peak.  Note that thus far we've been dealing with a very finite (1000 points) simulation -- I presume you want a Continuous Record controlled by a While Loop, which only adds a little complication.

Before Barking Up Another Wrong Tree, I'll wait for your response (and the VI requested in the first paragraph). 

Bob Schor 

[Coryman]

Bob,

The sine waveform is captured by the trigger, so at time 0, the trigger is at it's max positive amplitude, and also at the correct time point to overlay the sine wave.  I have attached a very simple png that I made by plotting the sine wave and the trigger (square) wave in the same plot.  So, all I need is for a vi to zero out the 'dots' on the baseline (which you already have figured out), make a new sine wave where the trigger dot is overlaid at the correct time point on the sine wave.  Then I overlay both the original sine wave and the 'trigger dot' sine wave.  I almost had this a few vi iterations ago with your vi that zero'd out the baseline dots, but the trigger dot was not riding the sine wave at the correct amplitude.

[Bob_Schor]

Success.  Here's a Noisy Sinusoid and an (unplotted) Trigger Signal (a Square Wave with the same period as the Sinusoid having a 10% duty cycle and using the Rising Edge as the "Stimulus" time.  Peak Detection was used to create a "Red Square" overlay to show the peaks, and the Rising Edge was used to create a "Green Square" overlay to show the triggers.  I leave it as an (easy) Exercise for the Reader to also output the times of the peaks, triggers, and "Response Time" (Peak - Trigger).

You were worried in an earlier post that your Trigger points seemed to have some "sinusoidal" drift, as do my Green Dots.  There's an explanation that you should think about, and if you can't figure it out, I'll tell you the Experiment to do with this Demo that will make it all clear.  Since you are using LabVIEW 2015, the Demo is (I hope) in LabVIEW 2015.

Bob Schor

[Coryman]

Bob,

They don't call you a proven zealot for nothing!  I will be working with relatively clean sine waves, even in the real world.  I kicked your 'noise' down to 0.02 and the ripple in the trigger pulse was gone.  I will follow up on your suggestion to check the example.  Man, that is a bunch of code to perform what every oscope does.  It's called the Z axis in a scope.  You put your one or two channels into the scope and your trigger into the Z channel and the trigger shows up as a 'blip' on the signals. That's what was used originally to do what I am trying to duplicate in LabVIEW.   Again, my thanks for your persistence!

Ron