Analyze a signal starting from the last sample backwards?

[Fascinated by Electronics]

Hey all,

This forum has been extremely helpful to me thus far in terms of learning LabVIEW. I have some more questions concerning some signal analysis of our sample loader motor currents.

As it stands now, I am not sure if I can post my entire VI due to confidentiality issues. However, I can describe is as much detail and as many posts as necessary to make it easier for the forum gurus and experts to help me. I will also post some screenshots with notes to describe things in more detail.

The question I have is this: Is it possible to write code such that a signal interval is extracted starting at the end of the collected samples and then moved backwards? That is, If I have Signal A and I collected data for it from T0 to T=25.2 seconds for example... Can I program code such that the signal from 25.2 Seconds back to say 16.7 seconds is extracted????

The reason I am asking this is because there is no way to predict how long our overall collected data set will be..... because there is no way to predict which sample load will jam up during the load... it could be sample load #2, #17, #4, etc. that gets jammed up, and thus our usable data collection ends with the sample number that it jammed on.

There are some distinctive differences between a good sample motor current (motor current is related to armature torque) curve and a jammed sample load. Looking at my attached PNG file, the differences are obvious. During a normal sample load, with our particular motors, there is an inrush spike and then two humps (when the armature is actually pushing the sample into the device and the second hump is when it is returning to home position) and then the deceleration spike (which is basically a back EMF) at the end of motor motion.... A jammed sample load (as you can see with the 3rd sample load) has an inrush spike followed by a slight drop from the spike and then a period of high frequency oscillation about the jammed holding torque.... I have thought about using some triggering to tell the extract signal.vi when/where to look for the Jammed slide curve... but am not sure how I would differentiate between a normal load and the jammed load.... They both start the same way, but obviously the jammed curve attains a holding torque... Is there a way to make logic such that: IF the value of say above 50 amplitude is detected for so long (in X-axis units) then there is an implied jammed sample curve, thus look at this signal interval for the data we are interested in.....????????

OR, is there a way to do what the Red arrow and red ellipse show: Start the signal extract from the red ellipse backwards to the point of the red arrow???

The data we are interested in is less for a jammed sample load compared to a normal sample load. For the Jammed sample load, we are interested in the items bounded by the orange bars: the High and Low about the middle thinner orange line which is the holding torque of the jam....... Those values should be easy to find once I tell the Statistics.vi where to look in the signal, right?

Thanks so much for the help!!

[Kevin_Price]

I think you may have 2 mostly distinct issues to deal with here and yes, both are certainly doable.

1.  You must somehow detect and identify a jam event, presumably very soon after the fact.  Either that or do a bunch of logging and then find these events entirely during post-processing.

   So you want to come up with some simple set of criteria that does a very good job of discriminating normal events from jams.  Do all normal events have a very similar shape or does it vary?  Do all jams look similar to one another or do they vary?   Are you trying to characterize and troubleshoot a problem to be fixed in design or are you going to need to build this jam detection into a product?   Obviously you would need a much more robust approach for the latter.

   Offhand, the jam looks to have longer duration, lacks a characteristic negative torque "release" at the end of the event, and has a fairly long interval of high freq oscillation overlaid on a positive DC offset.  Any or all of these traits (and more) seem like good candidates to help discriminate normal events from jams.

2.  Maybe another problem is knowing when to capture.  Maybe you expect to be standing by during testing and you'll be able to manually intervene when you notice a jam with your own eyes and ears.  Trouble is, the event already happened, so how do you go back in time to capture the data?

   This part is actually fairly simple.  You can set up a task for continuous acquisition and then configure a few task property nodes that'll get you there.  One is to make sure you set your buffer size explicitly with a DAQmx Buffer property node.  Make it plenty long enough that your jam event won't be overwritten before you can react.  20 seconds should be plenty.  Also set the AllowOverwrite property to True.  I'm not sure if this is a DAQmx Buffer property or a Channel property.  Finally, when it's time to read your data, use a DAQmx Read property node first.  Set RelativeTo = 'Most Recent Sample' and set Offset = -(# of samples you plan to read).  Notice the negative sign!  Then when you call DAQmx Read.vi and request that # of samples, you'll get the most recent ones.

  Can you say what city you're in?  Is it by chance Rochester, NY?  Your description, and even to an extent the traces, seem kinda familar from a prior job of mine...

-Kevin P