Deadband algorithm always sends monitors for NaN and inf values

Bug #1346930 reported by Ralph Lange
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
EPICS Base
Fix Released
High
Ralph Lange

Bug Description

The deadband algorithm used for float type values in the analog records (ai, ao, calc, ...) always sends monitors while the value is NaN or +inf or -inf.
This might be mathematically correct (as numerical deadbands cannot be applied to infinite or non-numerical values), but it is not what is expected.

I think the expected function is:
If the last and the current value are either both NaN or both inf and do not differ in sign, do not send an update.
If the last and the current value are either both NaN or both inf and differ in sign, send an update.
If the NaN property or the inf property of the last and current value have changed (one of the values is finite, the other is not), send an update.
If the last and the current value are both finite, apply the deadband to the absolute difference and send update if delta > deadband.

Tags: rec 3.15

Related branches

Revision history for this message
mdavidsaver (mdavidsaver) wrote :

Could you provide a unittest which demonstrates the undesired behaviors? (separate from record support code)

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Working on it.

As there are no tests in the record section yet, this means adding a lot of boilerplate.

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Since I am adding a test, I will make this a 3.15 change, and then backport the changes (without the test) to 3.14.

Changed in epics-base:
milestone: 3.14.branch → 3.15.branch
tags: added: 3.15
removed: 3.14
Revision history for this message
Andrew Johnson (anj) wrote : Re: [Bug 1346930] Re: Deadband algorithm always sends monitors for NaN and inf values

On 07/22/2014 09:40 AM, mdavidsaver wrote:
> Could you provide a unittest which demonstrates the undesired behaviors?
> (separate from record support code)

Since this is a test of a record type, it will be simplest to write it
in Perl using my lp:/~epics-core/epics-base/ioc-test-module/ branch.
Look at src/std/softIoc/testSoftIoc.plt for an example that has the .db
file embedded in the test source as a Perl __DATA__ stream.

I would avoid using CA in the tests like the example does though, the
Perl CA library doesn't work on Windows so I will be adjusting the
testSoftIoc.plt code to allow for that. You can use the $ioc->dbpf() and
$ioc->dbgf() routines to set and get field values.

- Andrew
--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Since I want to test the record's monitor() routine, and test results depend on monitors being sent or not, can I get around using CA?

I was considering to replace (overload) the db_post_events() routine to get the updates sent back into my test code.

Revision history for this message
Andrew Johnson (anj) wrote :

You can use CA links inside your test database with no problem, it's just that you'll have to disable the test program on Windows if it uses the Perl CA module. I don't think it matters that we don't run all the tests on all the architectures, but in this case I think you can do so. Using the CA module would also make your test program harder to write and understand because it'll have to use callback subroutines.

I would love to be able to build CA on Windows, but I don't see an easy way to do it — the C code must be compiled using Perl's compiler flags since they vary with architecture and even with Perl version, and I don't want to embed that kind of knowledge into my Makefile. On Windows we may be using a different compiler than Perl was built with, with different flags, and the compiler that Perl needs might not even be installed.

Revision history for this message
Ralph Lange (ralph-lange) wrote :

That sure looks interesting, but doesn't allow to run the tests on vxWorks or RTEMS, correct?

Revision history for this message
Andrew Johnson (anj) wrote :

Yes, until we implement a version of the Perl API that can talk via a serial port to a VxWorks/RTEMS system.

Personally I don't think it is essential to run these tests on all architectures as long as we are testing the underlying APIs that the code uses on all architectures, i.e. finite(), isnan() etc. which are tested inside libCom/test. The alternative is to write tests in C on top of the current ioc-shutdown2 branch, but I suspect those test programs would take rather longer to code and be more fiddly. You also need the IOC to run rsrv and dbCa links which I didn't think ioc-shutdown2 could stop and restart properly (although I may have misunderstood that).

One of the possible projects I have for the codeathon is to start writing tests for the Base record types, and I really don't want people to have to do those in C. The tests you're writing might be a good starting point for those, so I'd suggest making separate test programs for each record type testAiRecord.plt etc.

Revision history for this message
Ralph Lange (ralph-lange) wrote :

I am actually planning to use a server-side plugin (pre-queue) that
feeds the update back to the test before it is put on the ca server queue.
That would only need a record that sets up the CA input links (with the
plugin) to all records under test (one of each analog type), and neither
needs an external CA client nor a restart of the database nor any dirty
overloading tricks.

Revision history for this message
Andrew Johnson (anj) wrote :

That approach might appear simple to you, but to me it seems to add an awful lot of complexity for anyone else who wants to understand and modify your test code. It also couples your tests to the server-side plugin API.

One nice thing about testing record-types is that the record instances are all independent, so you can load as many as you need and run each test or series of tests against a new instance without having to restart the IOC to reset the test environment.

Changed in epics-base:
status: New → Fix Committed
Andrew Johnson (anj)
Changed in epics-base:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.