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

Warning messages from devAsynXXXArray in testAsynPortDriver #181

Open
MarkRivers opened this issue May 24, 2023 · 4 comments
Open

Warning messages from devAsynXXXArray in testAsynPortDriver #181

MarkRivers opened this issue May 24, 2023 · 4 comments

Comments

@MarkRivers
Copy link
Member

A problem is manifested in testAsynPortDriver if P_Run is set to 1 in the .cpp file.

The driver will print these messages right after iocInit:

2023/05/24 07:33:12.002 testAPD:scope1:Waveform_RBV devAsynXXXArray::process, warning: multiple interrupt callbacks between processing
2023/05/24 07:33:12.503 testAPD:scope1:Waveform_RBV devAsynXXXArray::process, warning: multiple interrupt callbacks between processing
2023/05/24 07:33:13.003 testAPD:scope1:Waveform_RBV devAsynXXXArray::process, warning: multiple interrupt callbacks between processing
  • If P_Run is set to 0 in the .cpp file, and then changed to 1 at run-time the warnings do not occur.
  • If P_Run is set to 1 in the .cpp file the warnings occur immediately after iocInit because the default value of the Waveform_RBV.SCAN field is “I/O Intr”. If that SCAN field is changed from “I/O Intr” to “1 second” and back to “I/O Intr” at run time then the warning messages stop.

Both of these observations suggest a problem in the initialization of devAsynXXXArray.cpp. That was completely re-written in asyn R4-44.

@wanglin86769
Copy link

Thanks for following up.
To provide more info, it can also be reproduced on asyn-R4-43 and asyn-R4-42.

@MarkRivers
Copy link
Member Author

To provide more info, it can also be reproduced on asyn-R4-43 and asyn-R4-42.

I believe I have identified the issue. The problem is that devAsynXXXArray::interruptCallback should be returning immediately if interruptAccept is not yet 1. It currently does this if a ring buffer is being used:

if (!interruptAccept) return;

But it needs to do this even if a ring buffer is not being used.

This problem is not new in R4-44, it was also present in older versions when devAsynXXXArray.h was a giant C macro.

@MarkRivers
Copy link
Member Author

MarkRivers commented May 24, 2023

I have fixed the problem. interruptCallback() now returns immediately if interruptAccept is 0. I have pushed the fix to the master branch.

@wanglin86769
Copy link

It works, wonderful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants