Hi,

Instead of SCAN=I/O Intr you might want to consider modbus absolute addressing, where the modbus driver will write/read for each specified address in turn. If each record is forward linked, the records will process in order, and after the last one has finished you can trigger the detector. This is a less efficient way of doing modbus I/O, as it results is separate write/read operations rather than polling contiguous registers, but can be useful in certain circumstances.

For the timestamps, each of the record timestamps will be set when the response comes back (I think). So depending on how fast the device is, there’ll be several milliseconds between each write/read. However, it’ll be deterministic for your application.

Cheers,

Matt

Hello Kay,

Thank you for your response, Even I was banking on the last record to process.

However the EPICS documentation, does not assure the sequence of processing.

I also wanted to know how to get Modbus read/write time stamp.

for sequencing, I was wondering if PHAS field will help. Another workaround I could think was the having another bi record flag as Done and check that all flags are asserted.

But I have to reset it every time.

Another nifty soln can be thought as given in the pseudo code below. However, I am not sure of scaling and computation overhead. any suggestion on this will be welcome.

record(ai, modin1) {
    field(DTYP, "asynFloat64")
    field(INP, "@asyn($(PORT) $(OFFSET) 10)FLOAT32_LE")
    field(FLNK,"modin1:done)")
}

record(calcout, "modin1:done") {
  field(CALC, "!A")         #Toggle
  field(OUT, "modin1:done.A")
  field(FLNK,"check:done)")
}

record(calcout, "check:done") {
  field(INPA,"modin1:done")
  field(INPB,"modin2:done"
  field(CALC, "A&&B = A||B")         #XNOR OPERATION
  field(OOPT, "On Change")
  field(OCAL,'0')
  field(DOPT,"Use OCAL")
  field(OUT, "modbus:busy")
}

record(busy, "modbus:busy"){        #sscan detector trigger can set this to 1 which can be cleared by the check:done
}

Thank you in advance,

Kuldeep 

Date: Wed, 12 Aug 2026 12:44:23 +0000
From: "Kasemir, Kay" <kasemirk at ornl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: Re: [EXTERNAL] Modbus and SScan acquisition synchronisation
        and timestamp query
Message-ID:
        <DM8PR09MB683912CC9885405D56DFF2C6B4DC2 at DM8PR09MB6839.namprd09.prod.outlook.com>

Content-Type: text/plain; charset="windows-1252"

Hi:

Good question, I?ve been wondering about this as well!

When I had N records that all read from the same device via SCAN=I/O Intr, I?ve set the ?TPRO? flag and that way saw in which order they are processed. Then I added an FLNK from the one record processed last to the record or chain of records that should process next to use the information just read from the device.
That ?works? as long as your device support always reads items from the device and then issues the I/O Intr updates of the associated records in the same order. This was the case for the specific device that I used, but isn?t generally given.

???

Hello,
I am having a device communicating over Modbus/TCP with four analog input channel
I am using these individual channels with ai records and SCAN in I/O Intr mode.
These four channels are used as detector PV's in SScan record.

I wanted to trigger the Detector acquisition only after all the four ai PV are processed (i.e. after I/o Intr processing of ai record).
Is there any way to do this and can I get the time stamp of the modbus read/write operation.

I am using EPICS 7 with modbus 3.3 asyn 4.42 streamdevice 2.8.22

Thank you in advance.

Regards,
Kuldeep

Hi James,

I am not familiar with the device, but it seems a python program at

bcsblbl/Cryostream1000_PythonController: Python Controller for the Oxford CryoSystems 1000 Series CryoStream.

Opens and closes a connection each time, including polling for the status update. I think the device is closing connections as you describe, so a change to how the Db/protocol works to poll and operate in an open/close connection manner would remove the error message you are getting.  

Regards,

Freddie

Hello Mark -

'asynReport1' produces the following output:

asynReport 1

L0 multiDevice:No canBlock:Yes autoConnect:Yes

    enabled:Yes connected:Yes numberConnects 1

    nDevices 0 nQueued 0 blocked:No

    asynManagerLock:No synchronousLock:No

    exceptionActive:No exceptionUsers 1 exceptionNotifys 0

    traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1

    Port 164.54.212.121:10304 TCP: Connected

OC_CMD multiDevice:No canBlock:Yes autoConnect:Yes

    enabled:Yes connected:No numberConnects 0

    nDevices 0 nQueued 0 blocked:No

    asynManagerLock:No synchronousLock:Yes

    exceptionActive:No exceptionUsers 1 exceptionNotifys 0

    traceMask:0x1 traceIOMask:0x0 traceInfoMask:0x1

    Port 164.54.212.121:10304 TCP: Disconnected

However I can successfully control the Cryostream, so I'm assuming that the command port is able to be opened when required. I am also able to telnet to the port; it sends what appears to be one packet and then disconnects, so it appears that the unit does allow multiple connections. 

Looking at the output of netstat on a Windows machine running the Oxford software, I see many connections in 'TIME_WAIT' in addition to the currently active one, which leads me to believe that the unit closes the connection after each status query.

-Jim

Hi James,

·         2026/08/13 18:20:47.498515 _main_ OXCRYO:CS1000:TURBOCMD lockRequest: port OC_CMD not connected

That looks to me like the Oxford rejected the connection attempt for the second socket.

Here are a couple of ways to diagnose:

asynReport 1

That will show the status of all asyn port drivers, including whether they are connected.

telnet 164.54.212.121 10304

Does it let you connect, or does it reject the connection attempt?  If it rejects then it would seem the Oxford is only allowing one socket client at a time on that port.  That is not consistent with the original database and startup script design.  Perhaps there is a configuration setting on the Oxford to allow more than one socket connection?

Mark

From: James P. Withrow <jwithrow at cornell.edu>
Sent: Thursday, August 13, 2026 6:34 PM
To: Mark Rivers <rivers at cars.uchicago.edu>; tech-talk <tech-talk at aps.anl.gov>
Subject: Re: Oxford Cryostream 1000 IOC questions

Hello Mark -

Below is the relevant excerpt from the IOC when both the status and command sockets are set to the same IP and port as in the repository.

# CS1000 uses TCP for Status Packets or Commands

# Status Packets

drvAsynIPPortConfigure("L0", "164.54.212.121:10304 TCP", 0, 0, 0)

# Commands

drvAsynIPPortConfigure("OC_CMD", "164.54.212.121:10304 TCP", 0, 0, 0)

# Status Packet and Commands on a Single Port

dbLoadRecords("db/MDO.db", "P=OXCRYO:,Q=CS1000,PORT=L0,R=MDO:,L=0,A=0,PORTCMD=OC_CMD")

#var mySubDebug 1

#var streamError 1

#var streamDebug 1

#If are interested in saving logs, it can produce a few GBs of logs, use with caution

#streamSetLogfile("logfile.txt")

cd "/opt/epics/iocs/cryostream-1000-EPICS-IOC/OXCS1000/iocBoot/ioccryo1"

iocInit

Starting iocInit

############################################################################

## EPICS R7.0.9

## Rev. 2026-01-14T12:49-0600

## Rev. Date build date/time: 

############################################################################

2026/08/13 18:20:47.498515 _main_ OXCRYO:CS1000:TURBOCMD lockRequest: port OC_CMD not connected

-Jim

Hi Jim,

I think the database was probably intentionally designed to open 2 separate sockets to the device, so that the long status reply and short commands were independent.

Can you send the error message you got when using 2 separate asyn ports?

Mark

Good afternoon, all - 

I have an Oxford Cryostream 1000 and I am attempting to use the IOC located at 

https://github.com/bcsblbl/cryostream-1000-EPICS-IOC

I have it working well; I am able to both control and monitor the cryostream. However, my IOC console fills up with the following messages at 1-second intervals:

2026/08/13 15:55:18.027546 L0 OXCRYO:CS1000:STATUS: device L0 0 disconnected

2026/08/13 15:55:19.179502 L0 OXCRYO:CS1000:STATUS: device L0 0 disconnected

2026/08/13 15:55:20.331536 L0 OXCRYO:CS1000:STATUS: device L0 0 disconnected

2026/08/13 15:55:21.483524 L0 OXCRYO:CS1000:STATUS: device L0 0 disconnected

2026/08/13 15:55:22.635480 L0 OXCRYO:CS1000:STATUS: device L0 0 disconnected

Have I configured something incorrectly? Is this something to be concerned with? I did change the following line in st.cmd:

dbLoadRecords("db/MDO.db", "P=OXCRYO:,Q=CS1000,PORT=L0,R=MDO:,L=0,A=0,PORTCMD=L0")

I changed PORTCMD from "OC_CMD" to "LO" as both the drvAsynIPPortConfigure lines referenced the same IP and port, and the IOC complained about not being able to get a lock for the second port.

Thank you, 

-Jim Withrow

OK, masters of the EPICS universe….

Got a unique inquiry for you.   Probably something rarely used.

Running an IOC on the latest EPICS 7.

Have a situation where I need to process a PV when the IOC exits.

I have some PVs that control the power to a device that I’m testing.  When I want to replace the device (this is for a testing rig), I’d like to turn off the power to the device in the process of exiting the IOC (I don’t want to keep the interface powered up while unplugging and plugging equipment).

I implemented 2 PVs that have the power on command, and the power off command.  In the Power On command I set PINI=RUN, however all I could do on the Power Off command was to set PINI=Pause.   I can successfully control the power on/off  with the iocRun and iocPause commands.  iocRun occurs when the ioc Starts running, so that has the desired effect of powering up the interface.  But iocPause only processes on the iocPause command as far as I can tell.  I may have to compromise on that, as an exit command is not a pause.  I would have though it would possibly cause a pause/exit sequence, but no.

John Priller told me I would probably need to write some ‘C’ code to attach to the at-exit point (which I can do), but thought I’d ask the mailing list if there is a more standardized method to do this in the current release of EPICS.

Later-

David