looking for an example IOC for a Keithley 6517B Electrometer

[LeeYangLBLBCS]

I'm having trouble finding an example IOC in IP or XXX directories. Is it possible to add a woring example IOC to the ip/iocsh directory?

[LeeYangLBLBCS]

After some struggling, I think the I've configured the synApp/IP module's iocsh for Keithley 6517B to "kind of work".
i.e. I can get the reading from the instrument.
However I keep noticing an error when communication with the instrument, 
"**addr -1 queueRequest priority 0 not lockHolder**".
=========================================================
2022/10/24 09:17:16.503 /dev/ttyS0 write.
2022/10/24 09:17:16.503 /dev/ttyS0 write 12
*trg;fetch?\n
2022/10/24 09:17:16.503 wrote 12 to /dev/ttyS0, return asynSuccess
**2022/10/24 09:17:16.503 L0 addr -1 queueRequest priority 0 not lockHolder**
2022/10/24 09:17:16.503 asynManager::portThread port=L0 callback
==========================================================

Is this error fatal to the operationj of the IOC?

The other question I have is that the termination must be set to  "\r\n":
asynOctetSetInputEos( "$(PORT)", 0, "\r\n")
asynOctetSetOutputEos("$(PORT)", 0, "\r\n")
This is odd because the instrument supports other terminations as well, such as "\n", "\r" ,  etc.

[MarkRivers]

However I keep noticing an error when communication with the instrument, "addr -1 queueRequest priority 0 not lockHolder". Is this error fatal to the operationj of the IOC?

That is not an error at all. You are only seeing that message because you have enabled ASYN_TRACE_FLOW. That is an information message that is printed here in asynManager.c: https://github.com/epics-modules/asyn/blob/299be139652ff6a4528bb27cd8a65bd160fb0ad6/asyn/asynDriver/asynManager.c#L1569

The other question I have is that the termination must be set to "\r\n":

What do you mean by "must be". Did you try other values and find they did not work?

[LeeYangLBLBCS]

the value read back is correct if I set termination to "\r\n" or "\n". For example: But if I set the termination to "\r", I get a constant value of 0: Incidentally, the IOC trace shows the command string is always terminated with "\n", regardless of what termination I set it to. Could it be done that way by design? ======================================IOC output============= 2E+00\n 2022/10/24 10:00:58.992 /dev/ttyS0 read 6, return 0 2022/10/24 10:00:58.992 devXxStrParm::completeIOCommon (xxx:EM1:dmm_get_str) status=0 nread=13 2022/10/24 10:00:59.476 L0 addr -1 queueRequest priority 0 not lockHolder 2022/10/24 10:00:59.476 asynManager::portThread port=L0 callback 2022/10/24 10:00:59.476 L0 set Eos 1 \n 2022/10/24 10:00:59.476 /dev/ttyS0 write. 2022/10/24 10:00:59.476 /dev/ttyS0 write 12 *trg;fetch?\n* 2022/10/24 10:00:59.476 wrote 12 to /dev/ttyS0, return asynSuccess 2022/10/24 10:00:59.476 L0 addr -1 queueRequest priority 0 not lockHolder 2022/10/24 10:00:59.476 asynManager::portThread port=L0 callback 2022/10/24 10:00:59.476 L0 set Eos 1 \n 2022/10/24 10:00:59.476 /dev/ttyS0 read. 2022/10/24 10:00:59.487 /dev/ttyS0 read 8 +000.907 2022/10/24 10:00:59.487 /dev/ttyS0 read 8, return 0 2022/10/24 10:00:59.487 /dev/ttyS0 read. 2022/10/24 10:00:59.492 /dev/ttyS0 read 6 4E+00\n 2022/10/24 10:00:59.492 /dev/ttyS0 read 6, return 0 2022/10/24iocxxx> 2022/10/24 09:57:52.921 L0 addr -1 queueRequest priority 0 not lockHolder 2022/10/24 09:57:52.921 asynManager::portThread port=L0 callback 2022/10/24 09:57:52.921 L0 set Eos 1 \n 2022/10/24 09:57:52.921 /dev/ttyS0 write. 2022/10/24 09:57:52.921 /dev/ttyS0 write 12 trg;fetch?\n** 2022/10/24 09:57:52.921 wrote 12 to /dev/ttyS0, return asynSuccess 2022/10/24 09:57:52.921 L0 addr -1 queueRequest priority 0 not lockHolder 2022/10/24 09:57:52.921 asynManager::portThread port=L0 callback 2022/10/24 09:57:52.921 L0 set Eos 1 \n 2022/10/24 09:57:52.921 /dev/ttyS0 read. 2022/10/24 09:57:52.932 /dev/ttyS0 read 8 -000.393 2022/10/24 09:57:52.932 /dev/ttyS0 read 8, return 0 2022/10/24 09:57:52.932 /dev/ttyS0 read. 2022/10/24 09:57:52.937 /dev/ttyS0 read 6 0E+00\r 2022/10/24 09:57:52.937 /dev/ttyS0 read 6, return 0 2022/10/24 09:57:52.937 /dev/ttyS0 read. 2022/10/24 09:57:57.932 /dev/ttyS0 timeout handler. 2022/10/24 09:57:58.039 /dev/ttyS0 read 0, return 1 2022/10/24 09:57:58.039 devXxStrParm::completeIOCommon (xxx:EM1:dmm_get_str) status=1 nread=14 10:00:59.492 devXxStrParm::completeIOCommon (xxx:EM1:dmm_get_str) status=0 nread=13

[MarkRivers]

Incidentally, the IOC trace shows the command string is always terminated with "\n", regardless of what termination I set it to.

I am not sure what you mean. Do you mean changing the termination using the front panel of the device, or using a command in your startup script?

[LeeYangLBLBCS]

I changed the termination options after I shutdown IOC. And with the keithley 6517B's termination character always matching the IOC's "asynOctetSetInputEos" and "asynOctetSetOutputEos", as in the following two lines of the startup script: asynOctetSetInputEos( "$(PORT)", 0, "\r") asynOctetSetOutputEos("$(PORT)", 0, "\r") When I replaced "\r" by "\r\n", "\n\r", and "\n", voltage reads back correctly.

But when I use "\r", the read back always showed 0, even when the Keithley instrument responded properly as if a query has been received and responded back to the caller, similar to the other three terminations.

I've ruled out the hardware issue, in some other way.

[MarkRivers]

I think you are misunderstanding what asynOctetSetInputEos() does. It does not tell the device what terminator to send. I tells the EPICS asyn driver what terminator to expect. The device always sends \n at the end of the response, so you should use that as your input terminator. I think the device probably ignores the output terminator. TCP devices can do that, they just act upon all the characters sent in a packet. Real serial devices do require an output terminator so they know when the command is complete.

[LeeYangLBLBCS]

Then why can’t I tell asynchrony driver to expect ‘\r?

The ‘\r’ happens to be the first available option in the instrument so that’s what I tried first - for a few days.

On Mon, Oct 24, 2022 at 5:37 PM Mark Rivers @.***> wrote:

I think you are misunderstanding what asynOctetSetInputEos() does. It does not tell the device what terminator to send. I tells the EPICS asyn driver what terminator to expect. The device always sends \n at the end of the response, so you should use that as your input terminator. I think the device probably ignores the output terminator. TCP devices can do that, they just act upon all the characters sent in a packet. Real serial devices do require an output terminator so they know when the command is complete.

— Reply to this email directly, view it on GitHub https://github.com/epics-modules/ip/issues/42#issuecomment-1289822503, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSYGNE2FYWCRGSIMI6JWODWE4TWLANCNFSM6AAAAAARMCKAMY . You are receiving this because you authored the thread.Message ID: @.***>

-- Lee Yang Lawrence Berkeley National Lab 1 Cyclotron Road, M/S 15R0217 Berkeley, California 97320 office:(510)486-7320

[MarkRivers]

Then why can’t I tell asynchrony driver to expect ‘\r?

Because the device support you are using is overriding the terminator you set in iocsh: https://github.com/epics-modules/ip/blob/69beb8465e6c80456524bcd0ab6a96fb315a423c/ipApp/Db/Keithley65xxEM.db#L403

Note that the link in that record sets the terminator to 0x0a which is \n.

[LeeYangLBLBCS]

that explains it. thanks.