start trigger based on channel logic OR time-based, STOP based on channel logic OR time based: can this be done?

I am setting up a remote monitoring system and fear that data files will be far too large if I use "always fast".

I have created a fast storage based on channel logic of Peak-to-Peak values calculated every 1s so the logic is: Trigger= (PTP >10) AND (PTP<150) - this is to avoid the scenario where a sensor fails (or starts to fail and gives rubbish). I also have an "end" logic which is Trigger<0.5. This way I can use "trigger" to start a fast recording and "end" to finish it - in both cases by choosing "enters window" and my window is between 0.5 and 1.2 to capture the logic "1". To capture all the data leading to PTP exceeding the threshold, I have a pre-trigger period as well. I know from experience that this will work, so long as PTP is within the valid range.

In my current case, I would like to set a regular recording to capture some sample fast data, say 1 minute every hour, in order to get some fast data for general analysis/checking. I can easily set the start trigger based on time BUT the end trigger is more complicated (I think). If my channel logic causes a fast data storage, I do not want it to stop after 1 minute (if the levels still exceed the PTP trigger). Equally, I do not want my time-based trigger to stop fast data storage because my channel-based end logic is valid.

I think I need to create a "timer" channel/signal/value every 60 minutes (or other configurable period) which, like my PTP is logic high only for a certain duration (60s or whatever instead of a value). I can't figure out how to do this though :(

I think I can see the basis for doing this: create a formula channel based around timetrig=TIME MOD X - where X is my number of seconds between recording periods - to get a saw tooth signal from 0 to X.

Next I need to hold timetrig briefly when it reaches my value of interest (e.g. 20 for testing purposes) so that I can "see" it long enough for the trigger to start the fast data recording. I think I do this with HOLD - however I am having problems with holding timetrig at 20 using HOLD...

I'm sorry to keep posting here, but every now and then I have another play. I think that the "rearm" function of HOLD is not working in 7.1.3 b426 (I am running DEWESoft 7 on a Dewetron device). I have tried various combinations based on value or logic and my held value does not ever reset.

Hi,

I had to read the initial post a few times but I believe that I now understand what you're trying to accomplish. I've configured an example setup that is probably the simplest way to do this. Since the storing conditions themselves don't allow you to perform your exact type of storing, we need to configure a custom trigger in math, which you've already figure out. This could be done with only one formula, but I've used two to make it a bit more user friendly. I only use one start/stop trigger that sends out a 1 when data should be stored and a 0 when data shouldn't be stored based on your conditions. In the storing tab, I then use this trigger as a rising (positive) edge over 0.5 for starting and a falling (negative) edge over 0.5 for stopping storing.

The trigger includes the basic value condition, which produces a 1 when the specific value is within a defined range OR if the time conditions are met. Either of these conditions will cause the formula to output 1, so the storing won't end if the time limit runs out but the value is still within the target range. The way the time condition is set up is by using the mod operator (remainder after division). I use time mod 3600, which is basically a 1 hour counter. Since you said you wanted to store one minute of data for each hour, I then use the condition to output a one when this counter is between 0 and 60. The counter will reset to zero after 1 hour has passed and repeat itself.

If you wanted to store your minute on every absolute hour, then you'd need to download the "Time decode" plugin and set up your triggers a bit differently, but it shouldn't be to hard to do.

The hold function works a bit differently then you think. The rearm option doesn't mean that it will reset the formula to a "default value" when the trigger is reached, it just means that the hold formula is ready to hold another value when it reaches the initial trigger. Until that happens, the formula will sit on the previous value.

For example if you use the following formula:hold('Signal', 'Sine wave' = 0 , 'Sine wave' = -1), it will hold the signal value when the sine reaches 0. When sine reaches -1, the formula will again start looking for the hold condition ('Sine wave' = 0), but it will still be set to whatever value it was originally holding until sine reaches 0 again. In your case, where you were using the mod function, the "Signal" was always the same, so the hold function held the same number over and over again, so you couldn't notice if the rearming of the trigger actually happened or not.

Hopefully both explanations will be useful to you in configuring your setup. I've just noticed that you're using DEWESoft 7 and I sent you a setup file made in X2. If you're unable to open/transfer my setup to V7, just let me know and we'll figure it out.

Thanks.

I'll have a play. Andy Hathway in the UK suggested I set a post time of 60s and a simple start trigger of "every 1 hour" in addition to my "logic-based" ones. I have not tried this yet, either but will be in touch if I have any more questions.

Back again I'm afraid.

The system has been recording data reasonably steadily now for a couple of months. Hardware issues appear to have been solved BUT now I find that DEWESoft is not storing fast data when I expect it to.

I have attached a screenshot of a data file and the event markers clearly show that some good, high stress range, data are not triggering the storage. I wonder if there is a problem because I have not included a "post time extension" and an elevated level has occured just as the logic is seeing a "stop"...

I have also included the setup extracted from the data file. Any help greatly appreciated - especially as I will be able to make changes to the system this week when visiting the site to do something else (so a prompt reply - as they always are - will be extra welcome!)

Back again I'm afraid.

The system has been recording data reasonably steadily now for a couple of months. Hardware issues appear to have been solved BUT now I find that DEWESoft is not storing fast data when I expect it to.

I have attached a screenshot of a data file and the event markers clearly show that some good, high stress range, data are not triggering the storage. I wonder if there is a problem because I have not included a "post time extension" and an elevated level has occured just as the logic is seeing a "stop"...

I have also included the setup extracted from the data file. Any help greatly appreciated - especially as I will be able to make changes to the system this week when visiting the site to do something else (so a prompt reply - as they always are - will be extra welcome!)

Hi,

I've looked a the setup file and I remember the original logic behind the storing condition. As you probably expected, I would really appreciate if I could see the data file in question. Just looking at the picture that you've sent, none of the cursor values go above 5, which is your lowest triggering limit.

Seeing the data file would help me determine whether there was actually a failure with the system, and then I could see if it happened on the trigger (formula) level, or if the storing was't activated for some reason. Then I can focus on reproducing the issue.

Since the data in your picture has the ".d7d" extension, it would also be interesting to know which DEWESoft V7 you're using to record the data.

PS: Re-reading everything, the reason for this is probably the one that you've discovered by yourself. Since you don't have the post the "post time extension selected", the stop storing trigger happens and while DEWESoft is still in the "post time" mode, another storing trigger occurs, but gets discarded. The data levels are than already higher than your trigger level and since you're triggering on simple edge, this means that the value of your data must cross over a certain level, which in this case won't be happening until the data returns to the normal state, which causes you to miss an area.

To get around this, you should simply select this option, which will extend the triggered area with a new start storing trigger, if it happens during the "post time".

Thank you. I will send you the data file later as you describe in the PDF. I will also tick the box when I get access to the system and hope that this cures the rare events where a new trigger occurs while the old one is "on its way down"

Hi,

thank you for sharing the data. I've looked at the area that was zoomed in on your picture and it's just as we suspected. The trigger occurs just as the post time is happening. I've attached a screenshot that shows just that.

If you'll see any strange behavior after you turn off the check box in your future measurements, let me know.

I am sorry to be contacting you again because it means I am seeing strange behaviour. I have had another set of data where "valid" data are not being stored. I have attached the storing page for reference. Should the "post time" be switched off if I am selecting the "post time extension"?

Any help greatly appreciated as I have another similar installation coming up in a few weeks.

Hi,

it's no problem. If something is indeed wrong, then we'll try to fix it to the best of our abilities.

There is nothing wrong with your setup and having the post time defined should work correctly with the post time extension.

In all of the tests that I've performed while looking at this thread a few weeks ago I wasn't able to find any odd behavior. As always if your situation allows it, please upload the data file in question to the private forum and point out where you think something went wrong and I'll analyze it.