Re: Issues with epics module and ISEG HAL service libraries

["Nariyoshi, Pedro via Tech-talk" <tech-talk at aps.anl.gov>]

Hello all,

it is my understanding that this is a warning added to Qt5 (and maybe the library was created assuming qt4?). The problem seems to stem from the fact that different threads are calling iseg_getItem, so the parent of the Qsslsocket thread is being changed frequently.

I have run some tests and oddly enough, the warning is issued during the call to waitForBytesWritten in writeReadSynchronous. I have tried to move the thread with setParent(0) and moveToThread(this->thread()) to no avail.

(I have also tried creating a mutex so that only a single thread can call writeReadSynchronous at a time, but that did not prevent the warnings from being issued).

What I was going to check next (before I was reassigned to a different higher priority project) is to create a QThread object as a member of the IsegHalRemote QObject. This QThread would have a Qsslthread member and only this single thread would actually interact with this socket. The I'd have to connect the appropriate signals and slots so the change is mostly transparent to the rest of the library.

Pedro Nariyoshi Software Controls Engineer Facility for Rare Isotope Beams Michigan State University 640 South Shaw Lane East Lansing, MI 48824, USA Tel. 517-908-7352 Email: nariyosh at frib.msu.edu

---

From: Yann Mandza <yann.mandza at ess.eu>
Sent: Monday, May 29, 2023 11:59:44 AM
To: tech-talk at aps.anl.gov
Cc: Nariyoshi, Pedro; Jens Römer
Subject: RE: Issues with epics module and ISEG HAL service libraries

 

[EXTERNAL] This email originated from outside of FRIB

Hey Florian,

I added some screens for your consideration, as you can see the communication is okay and the return values, I can confirm are correct, but this warning “QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread” keeps on popping up. I have disabled the embedded IOC and tested before launching this one that the pv are no longer connected.

 

Regards

 

Yann

 

From: Florian Feldbauer <florian at ep1.ruhr-uni-bochum.de>
Sent: Monday, May 29, 2023 10:49 AM
To: Yann Mandza <yann.mandza at ess.eu>; tech-talk at aps.anl.gov
Cc: Jens Römer <j.roemer at iseg-hv.de>
Subject: Re: Issues with epics module and ISEG HAL service libraries

 

Hey Yann,

the communication with the socket does not happen within the device support, but within the isegHal library.
Tbh I do not really understand the problem you have. The EPICS IOC running on the crate controller uses the same device support.
So if muliple threads within EPICS cause the error, it should happen in that IOC as well, but it doesn't.

So I guess the problem comes from somewhere else. Are you running multiple IOCs/programs accessing the isegHAL?

Cheers,
Florian

 

Am 29.05.2023 um 10:39 schrieb Yann Mandza via Tech-talk:

Hey Florian, thanks for your quick feedback,

“as for the AO record: The initialization failes, because the "Quality" of the iseg items returns 000 (=ISEG_ITEM_QUALITY_INVALID)
Maybe the module you are using does not support setting the RampSpeed and thus the isegHal return INVALID qualtiy for it.
That would explain, why it is the only record producing this error.“

I believe the issues is with my hardware config, but I only show the output of one AO record, many of those AO shows this error, I will first get the config right and see if this  “INVALID quality” is clear and the initialization works.

When it comes to Qt, I only tied to follow the source of the problem. There is an issue of epics thread (reading/writing) to the socket as once since that socket is creating as shared resource statically should it not be protected?

I was asking if the device support could handle this? Is there a way to know which epics thread make the call to the driver methods? At init all records call the devIsegHalInitRecord method which call the driver method iseg_getItem which internally make read and write call to the socket.

Does the DB record initialization process handle each record in its own thread? Who can help me understand this init process?

Perhaps having a thread that solely access the socket working as a server for those epics thread would make it safe?

Regards,

Yann

 

 

From: Florian Feldbauer <florian at ep1.ruhr-uni-bochum.de>
Sent: Monday, May 29, 2023 10:11 AM
To: Yann Mandza <yann.mandza at ess.eu>; tech-talk at aps.anl.gov
Cc: software.entwicklung at iseg-hv.de
Subject: Re: Issues with epics module and ISEG HAL service libraries

 

Hey Yann,

as for the AO record: The initialization failes, because the "Quality" of the iseg items returns 000 (=ISEG_ITEM_QUALITY_INVALID)
Maybe the module you are using does not support setting the RampSpeed and thus the isegHal return INVALID qualtiy for it.
That would explain, why it is the only record producing this error.

As for the output recrods being monitored via the polling thread:
The isegHAL offers multiple interfaces to the outside world, like the EPICS interface (devIsegHal), the browser-based frontend from ISEG,
and some others. So Voltages/Currents and all other configurations can be changed outside of EPICS and we wanted to have a way,
that our EPICS records stay "synced" with the settings of the module.

It can be quite confusing, when the measured voltage is 0 although the set voltage is 1.2kV and the setOn bit is set in EPICS (but not in the module).
Or why the set voltage shows 1.2kV but the HV only goes up to 1.0kV (because someone set Vset to 1.0kV via another interface).

Unfortunately I cannot answer your question about Qt.
Personally I do not use Qt in any of my own projects and we usually use the IOCs running on the crate controllers for our isegHV modules.
With them we never had this issue.

Best regards,
Florian

 

Am 28.05.2023 um 23:13 schrieb Yann Mandza via Tech-talk:

Hello all,

I have a ICSMINI 2 box from iseg am trying to interface to via the HAL services utilities using HAL service libraries from iseg, I was able to recompiled for my system.

So far I tried to connect to the box using the provided example and it worked.

However I tried the epics module from florian  https://github.com/ffeldbauer/devIsegHal, so i could disable the embedded IOC and run mine outside.

I was able to compiled the module and get the IOC connected to the box. However I’m having two main issues.

 

1 -  error at record initialization for AO record

ISEG:7200081:0:32:VoltageRampSpeed: Error while reading item property '0.32.VoltageRampSpeed' (Q: 000)

recGblRecordError: ao: init_record Error (514,11) PV: ISEG:7200081:0:32:VoltageRampSpeed ( is this a result from the above? Then sorting out the above should clear this error)

it’s strange because only AO return this error.

 

I read on the deviseghal GitHub page that AO record were added to the polling thread that also handle I/O interrupt.

I wonder why that would be? 

 

This excerpt is from the page

“It is possible that control parameters change during operation. For example, if a trip occurs the corresponding setON bit in the channel control register will be set to 0.

These changes are monitored by devIsegHal through a polling thread. Each output record (except for stringout records) is automatically registered to this thread and their values are checked for updates on the isegHAL.

If a value has changed the VAL field and timestamp of the record will be set to the new values”

I’m a bit confused why output record would need that.

 

2- Qt Socket Library return this warning “QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread", it seems the IOC starts several threads to read/write information to the iseg system.

One can trace this issues till the writeReadSynchronous method within the isegHal-service library. I used QT5 to compile the library.

Can the device support protect against this or should iseg update their code to handle multi thread access to the socket?

 

Regards,

 

Yann