I’m working with LOGO! 8.4 and want to ensure an analog output only updates when the current analog input value differs by more than a certain threshold (for example, 0.3 °C) and ideally remains stable for a short time.

The goal is to avoid constant updates by configuring the IoT table to update = on change option (not on short frequency intervals) and only update the output when the change is significant, in order to reduce costs.

I’m looking for a simple, solution using as fews blocks … if as possible, since I have many NAQ values to send.

[ Current Analog ]
                            |  
        Difference > Threshold (0.2 °C)?  — No —> Don’t update output  
                            |  
                           Yes  
                            |  
        [ Stability  ]   — No —> Don’t update output  
                            |  
                           Yes  
                            |  
        [ Update Analog Output ]  
                               

Any suggestions (or examples?) Maybe there’s a block that can something like his ;)

Thanks in advance.

Hello PierHB,

Filtering always results in a time delay. There are elegant solutions using custom filters. However, they require several functions (see here in the German section of the forum).

Another option would be to compare the last stored value with the current value. If this is greater than the desired deviation, the comparators are switched on and the current value is stored again. To prevent multiple triggering due to large changes, a switch-off delay keeps the muxer open for a short time.

I've attached an example.

Regards, Ella_68

(translated by Google)

Sure, that's the problem with the program. A permanent change within the mask window (+/- 1) means the values ​​aren't recorded.

Hi 

Thanks again for your help — Hi Ella_68,  your explanation really clarified things.

That sentence you wrote:
"A permanent change within the mask window (+/- 1) means the values aren't recorded."
…is exactly where the real issue is. It mostly shows up with extreme values. Each variable behaves differently, and in some cases, a fault could trigger hundreds or even 1000 updates message  just to go from 0 to 999 — which is exactly what I’m trying to avoid.

Using the fixed frequency update (every X seconds) might be the safest option, but it’s not ideal in most cases. It adds unnecessary messages when nothing’s really changing.

I’m not planning to use extra hardware after the LOGO! for now — even if it might be more cost efficient long-term, it would also mean more maintenance.

For sure use Average value first ! thanks ixo65. 

and then I’m still deciding: :
– maybe I’ll stick with your first program, adding a short delay (like 5s) just to be safe,
– or I’ll try my version,  but allow extreme values to pass through instantly. more blocks….not perfect…

Either way, your support helped me move forward. Thanks again!

Best,
 

Hello PierHB,

I've revised my first draft "Filterschaltung". Now the analog value is only output when the hold-open time for B004 has elapsed. Of course, the time is only a default value, since I don't know the duration of your spike. You'll have to experiment a bit with the time value of B005. The problem with the 999, of course, remains.

I've also included the other suggestion from the German section of the forum, "Spikefilter mit mediane Mittelwert" in the zip file.

Here, too, you have to adjust the clock rate "TL" of B001 to your requirements. The time must be longer than the spike. Note that by calculating the median average of three intermediate values, the response time is only established during the second cycle of B001.

Of course, it's also possible to make the spike filter interference-proof. For this, the median average would only have to be calculated from 5 or 7 values. However, the program will then become significantly larger and the response time will increase to 3 or 4 sampling cycles.

Best regards, Ella_68

(translated by Google)

Hi Ella_68,

Thanks again — I’ve been testing your first program, and it’s actually working quite well for my needs.

I’m using time values in seconds — not so much for filtering, but more as a kind of validation logic. For me, those seconds act as a safety margin when using the “on change” setting to send data to the cloud. The main goal is to reduce costs, not necessarily to smooth out the signal.

I also have a redundant periodic update configured (using "frequency" mode), in case a value is lost — or in edge cases like the 999 issue (a long change that stays just under the trigger threshold). That update is set to run every few minutes.

So for now, your first solution gives me a really good balance between simplicity and reliability. Thank you again for sharing it!

Best regards,
PierHB

PS: To avoid surprise costs, I’ve had a similar need with digital signals as well — implementing debouncing to prevent multiple MQTT messages from being triggered (or missed) due to contact bounce or signal noise. I mention this in case it’s useful for other readers ...