Re: PVA custom structs

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

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