Re: PVA custom structs

[Heinz Junkes via Tech-talk <tech-talk at aps.anl.gov>]

It's working now. I still had to delete all the old archiving requests.

Danke Heinz

> On 12. May 2026, at 17:57, Heinz Junkes <junkes at fhi-berlin.mpg.de> wrote:
> 
> in engine/log it looks ok for me (I have also introduced alarm fields)?
> 
> 
> 2026-05-12 17:48:15,540 INFO  [JCA Command Thread] pv.EPICS_V4_PV (EPICS_V4_PV.java:259) - Determined ArchDBRTypes for FHIFEL:llpg_1 as DBR_V4_GENERIC_BYTES
> 2026-05-12 17:48:17,474 INFO  [UDP4-receiver /0.0.0.0:59609] pv.EPICS_V4_PV (EPICS_V4_PV.java:221) - channelStateChanged:FOUND FHIFEL:llpg_1
> 2026-05-12 17:48:17,475 INFO  [TCP receiver /141.14.135.0:43970] pv.EPICS_V4_PV (EPICS_V4_PV.java:221) - channelStateChanged:CONNECTED FHIFEL:llpg_1
> 2026-05-12 17:48:17,544 INFO  [JCA Command Thread] pv.EPICS_V4_PV (EPICS_V4_PV.java:235) - Construct the fieldValuesCache for PV FHIFEL:llpg_1
> 2026-05-12 17:48:17,544 INFO  [JCA Command Thread] pv.EPICS_V4_PV (EPICS_V4_PV.java:248) - Type from structure in monitorConnect is structure
>    ushort Ch1_Width
>    ushort Ch2_Width
>    ushort Ch1_Delay
>    ushort Ch2_Delay
>    ushort Ch1_ExtraDly
>    ushort Ch2_ExtraDly
>    ushort Ch1_Atten
>    ushort Ch2_Atten
>    structure timeStamp
>        long secondsPastEpoch
>        uint nanoseconds
>        uint userTag
>    structure alarm
>        int severity
>        int status
>        string message
> 2026-05-12 17:48:17,544 INFO  [JCA Command Thread] pv.EPICS_V4_PV (EPICS_V4_PV.java:259) - Determined ArchDBRTypes for FHIFEL:llpg_1 as DBR_V4_GENERIC_BYTES
> 2026-05-12 17:49:51,502 INFO  [http-nio-17666-exec-5] engine.BPLServlet (BPLServlet.java:102) - Beginning request into Engine servlet /getVersion
> 2026-05-12 17:49:51,502 INFO  [http-nio-17666-exec-5] common.BasicDispatcher (BasicDispatcher.java:44) - Servicing /getVersion
> 
> 
> Unfortunately, nothing is archived, though…
> 
> Heinz
> 
>> On 12. May 2026, at 17:12, Heinz Junkes via Tech-talk <tech-talk at aps.anl.gov> wrote:
>> 
>> I added the timeStamp to the structure:
>> 
>> epics@aaV:~$ pvinfo FHIFEL:llpg_1
>> FHIFEL:llpg_1
>> Server: 141.14.134.173:5075
>> Type:
>>   structure
>>       ushort Ch1_Width
>>       ushort Ch2_Width
>>       ushort Ch1_Delay
>>       ushort Ch2_Delay
>>       ushort Ch1_ExtraDly
>>       ushort Ch2_ExtraDly
>>       ushort Ch1_Atten
>>       ushort Ch2_Atten
>>       structure timeStamp
>>           long secondsPastEpoch
>>           uint nanoseconds
>>           uint userTag
>> 
>> 
>> pvmonitor seems to work:
>> 
>> epics@aaV:~$ pvmonitor FHIFEL:llpg_1
>> FHIFEL:llpg_1 structure
>>   ushort Ch1_Width 0
>>   ushort Ch2_Width 1122
>>   ushort Ch1_Delay 946
>>   ushort Ch2_Delay 1342
>>   ushort Ch1_ExtraDly 10000
>>   ushort Ch2_ExtraDly 2000
>>   ushort Ch1_Atten 3
>>   ushort Ch2_Atten 31
>>   structure timeStamp
>>       long secondsPastEpoch 1147446330
>>       uint nanoseconds 448787927
>>       uint userTag 0
>> FHIFEL:llpg_1 structure
>>   ushort Ch1_Atten 4
>>   structure timeStamp
>>       long secondsPastEpoch 1147446570
>>       uint nanoseconds 69449424
>> FHIFEL:llpg_1 structure
>>   ushort Ch1_Atten 3
>>   structure timeStamp
>>       long secondsPastEpoch 1147446572
>>       uint nanoseconds 722922325
>> 
>> Unfortunately, however, the PV is not archived:
>> 
>> <PastedGraphic-1.png>
>> 
>> Heinz
>> 
>> 
>>> On 11. May 2026, at 20:18, Shankar, Murali via Tech-talk <tech-talk at aps.anl.gov> wrote:
>>> 
>>> Wouldn't you need a IOC timestamp? Maybe alarm information? Something like
>>> 
>>> alarm_t alarm
>>>   int severity
>>>   int status
>>>   string message
>>> time_t timeStamp
>>>   long secondsPastEpoch
>>>   int nanoseconds
>>>   int userTag
>>> 
>>> Regards,
>>> Murali
>> 
>> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature