MoTeC Global Forum

Following up on a wish list from my mate for whom I have been dong setup work, could a feature request be considered.

Can alarms be configured to display only once when the alarm condition is met, until the condition becomes false and then true again?

You should investigate using user-conditions. With those, you can create all sorts of logic to drive the simple alarm conditions.

I have started looking into them, but have not had time yet to really dig in and get my head around the logic. If I can create a condition that registers the transition from logging stopped to logging running and vice versa I can alarm on them.

But even the owner was keen on the idea of being able to have an alarm which alarms once and then doe not alarm again after acknowledgement (By button press or automatically) until the alarm condition becomes false and then true again.

Try using the trigger value modifier on your alarm condition to get this behavior.

For example, let's say you created an alarm for when logging was running (with the Message "Logging = YES").
The comparison for this is "Logging Running" greater than or equal to 1.

You then tick the "User Trigger Value Modifier", and set the trigger value to be modified by 1 (ie, it won't trigger again until the Logging Running channel becomes >= 2.

Tick the "Reduce trigger value when the alarm is inactive for" and enter say 1 second.

This will cause you to get the message once, it will stay up until you manually (or automatically using the "Options" tab) acknowledge it. It will not retrigger until Logger Running returns to 0 for 1 second, and then goes back to 1.

I have already started working on a pair of user conditions, but will keep the trigger modifier in mind as that should carry out a similar function. Given the logger running should produce a 0 or a 1, incrementing the alarm threshold to 2 should prevent a retrigger until the alarm condition becomes false again.

It is a bit like a RADAR system I used to work on (Quite an old one) some high level creativity was required to overcome the limitations of logic circuits of the day. Chiefly that mostly they had NAND gate chips to work with and not OR gates, so multiple NAND gates could be configured to work as a single OR.

I looked at the trigger modifier but even without sending something to him to test it is not going to perform as he wants. It would be able to make it display a "Log running" alarm only once, but given "Log stopped" is a value of zero, it can not be done as readily. User conditions it is.

I have sent him a new config to try with the logger running and logger stopped alarming via "Logger running False & Logger running true" as a momentary condition via user alarm 1, and it's mirror image logic wise as user alarm 2 which should create a momentary alarm on transitions from stopped to running and then back to stopped again only.

Still talking to him about the session time thing, at the moment for the events he is doing he does not see much value in it being displayed. Though I can perhaps see the value if he is not going to download log data after every run. Even if the session time is not displayed, I could create a counter for him which increments on each session reset to make it easy to see individual run data in the log if the counter is logged.

Had to do a bit of lateral thinking and there is likely to be cleaner way to do it, but until I have my own dash to work with the round trip time to test configuration changes was a problem.

I ended up generating separate user alarms for logging running true and false and used them to increment separate counters. The "True" counter is also logged so if he does not download logs until the end of a day's running he has a visual cue in the log file as to the start and end of each logged run. Downloading the logs resets that counter. The logger running and logger stopped alarms are generated on a change of state in one counter or the other and now only generate once per start and stop of the logger.

However my feature suggestion still stands. There are a few alarms that I can think of where an option for "Do not retrigger until condition becomes false" would be useful. Until/unless I can come up with a simpler way once I have my own dash to work with I have had to chew up two user alarms and two counters to achieve the same.

OK, I have been in discussion with the owner of the dash I started this thread for (I have since bought a C127 for myself and have been playing and learning for months while I do a wholesale electronics change on my car) and thought I might restate this feature request/wish list in a different way.

Rather than a change to alarm configuration, can a new and similar functionality be considered?

Rather than alarms, what my friend is looking for is status messages. They could be differentiated from alarms by having the message background green instead of red (For instance) and generally would appropriately display only once per instance of the trigger condition being met.

He has tonight had me tweak his setup for a comfort message that displays via an alarm for ten seconds when his thermo fan starts up, but but it is a bit messy to be creating a pulse function in his PDM based on the output status of the thermo fan, then transmitting that status of the pulse function to his dash via CAN to generate an alarm to display the text he wanted. If the dash could generate status messages it would be as simple as using the output status message sent via CAN as a condition to generate it.

This is what Display Creator is for. You can use it to configure any screen layout you like, including status messages that pop up for as long as you like based on any condition.

If you don't want to use DC, as has been suggested previously the trigger modifier in the alarm setup is probably the easiest way of doing it.

Well, DC would be one way of dealing with it. I did see a feature request logged on DC to include filtering of display outputs (Which was presumably not in place before?) is that looking like being implemented soon (Just because DC is cool to play with but I can't quite sell it to myself yet)

We did try the trigger modifier but using the alarm subsystem is a bit clumsy in operation. I may do better creating functions in his PDM for a lot of things he would like. And it is all good practice in setting up my own gear.