Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STAT/SEVR are changed to NO_ALARM after setting the variable although connection is down. #127

Closed
jalalmostafa opened this issue Sep 22, 2021 · 4 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@jalalmostafa
Copy link

STAT and SEVR fields are changed from COMM COMM INVALID to NO_ALARM although there is no connection to OPC UA server.

To Reproduce
Steps to reproduce the behavior:

  1. Run a disconnected EPCS server
  2. Monitor a record STAT and SEVR fields
  3. While disconnected, use caput to write to the record.

Expected behavior
STAT/SEVR should always show an error if the connection is not working.

Setup (please complete the following information if applicable):

  • OPCUA Support: v0.9.3
  • Platform: Ubuntu 21.04
  • EPICS Base: 7.0.6.1
  • Client library: UA SDK 1.7
  • Server: None

Additional context
Add any other context about the problem here.

@ralphlange
Copy link
Member

That is for an output record?

@jalalmostafa
Copy link
Author

yes for an ao. Specifically:

record("ao", "8110d90a-851c-4cf1-b9e6-7d238021d3ab")
{
    field(OUT, "@OPC ns=2;s=0.0_0 monitor=n")
    field(DTYP, "OPCUA")
    field(DESC, "Timestamp 1 Timestamp")
    field(EGU, "None")
    field(MDEL, "-1")
    field(ADEL, "-1")
}

@ralphlange ralphlange self-assigned this Oct 14, 2021
@ralphlange ralphlange added the bug Something isn't working label Oct 14, 2021
@ralphlange ralphlange added this to the 0.10 pre-release milestone Oct 14, 2021
@ralphlange
Copy link
Member

Sorry for the delay - this fell off the table.

I can reproduce this easily on my box. Might have been introduced with the recent change that skips processing when not connected.

@ralphlange
Copy link
Member

Sorry for the long delay.
The issue was indeed introduced by a recent reorganization of the device support that avoids calling into the driver for unconnected items. It applies to both write and read actions. (I.e., when explicitly processing unmonitored read records.)
I have implemented a fix and will merge after the tests have finished.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants