Experimental Physics and
Industrial Control System

André Hartmann via Tech-talk <tech-talk at aps.anl.gov> · Tue, 30 May 2023 16:23:04 +0200

Dear Florian,

the isegHAL-remote library provides a blocking access to the isegHAL

over TCP/IP (secured with SSL sockets). Therefore all data has to be

serialized.

It *should* be possible to open multiple TCP connections by using

multiple iseg_connects() with unique session names and then concurrently

operate on these unique sessions names with iseg_getItem() and

iseg_setItem().

But if the same session is reused, all isegHAL-remote calls must be

serialized.

When the IOC is running on the crate controller, you use the

isegHAL-client library, and there the access is already protected with

mutexes.

But of course the access is much faster here, because no network is

involved.

Best regards,
Andre

Am 30.05.2023 um 16:06 schrieb Florian Feldbauer:

Hey Andre,

is there any difference between the isegHAL-remote library and the

"local" isegHAL library in regards to the iseg_getItem method?

I'm a bit puzzled that there is no issue with threading in the IOC

running on the crate controller itself because both IOCs use the same

device support module. Just a different version of the isegHal library

beneath.

Cheers,
Florian

On 5/30/23 15:59, André Hartmann wrote:

Dear Yann,

I've never used the isegHAL-Remote library with multiple threads, and
I assume that threads can cause problems.

What you could try is to put a mutex around writeReadSynchronous(),

but note that this will block all other threads during the network

operation (which can fail, so in worst case it blocks for the timeout).

I hope that helps.

Best regards,
Andre

Am 29.05.2023 um 10:10 schrieb Florian Feldbauer:

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

<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

--
André Hartmann, Dipl.-Ing. (FH)
Softwareentwicklung / Software Development

E-Mail: andre.hartmann at iseg-hv.de
Tel: +49.351.26996-43 | Fax: +49.351.26996-21

iseg Leistungselektronik Sachsen GmbH
www.iseg-hp.de

Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany

Geschäftsführer / Managing directors: Dr. Tanju Gleisberg, Dr. Martin

Rentzsch

Amtsgericht / Lower district court: Dresden HRB 33563

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail. Das unerlaubte
Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System