Unable to get readbacks to update MBBO and BO in DG535 support

[mdwyman]

When I change a setting that uses either a MBBI or BI as it's "readback", the gpibRead a gets string that it can't deal with. Here's the ioc console output for such a case with most of the asyn traces on when the trigger sourc is changed to "External":

2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12
wrt 15\nTM 1\r
2022/11/09 15:27:32.184 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeSetMO writeIt
TM 1
2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:863] [L1,0x12a83b0,50] 164.54.104.15:4001 flushed 63 bytes
2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 11
wrt 15\nTM \r
2022/11/09 15:27:32.184 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeMI writeIt
TM
2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10
rd #60 15\r
2022/11/09 15:27:32.201 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 63
1\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0003\r\n
2022/11/09 15:27:35.204 [L1,-1,0] [devSupportGpib.c:982] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeMI gpibRead
TM 1\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\321\v\000\000\000\000\000\000\200\000\000\330v\177\000\000\200\000\000\330v\177\000
2022/11/09 15:27:35.204 [L1,-1,0] [devCommonGpib.c:749] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeMI can't convert msg >TM 1<

When I change a setting whose readback is a combination of MBBI and an AI PVs, I don't see such behavior. Here's the output on the console when I change the A channels delay to 2.0:

2022/11/09 15:30:38.390 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12
wrt 15\nDT 2\r
2022/11/09 15:30:38.390 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10
rd #60 15\r
2022/11/09 15:30:38.405 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64
1,+1.600000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n
2022/11/09 15:30:38.405 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12
wrt 15\nDT 2\r
2022/11/09 15:30:38.405 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10
rd #60 15\r
2022/11/09 15:30:38.419 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64
1,+1.600000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n
2022/11/09 15:30:38.419 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 29
wrt 15\nDT 2,1,2.000000000000\r
2022/11/09 15:30:38.419 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelaySetAO writeIt
DT 2,1,2.000000000000
2022/11/09 15:30:38.421 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12
wrt 15\nDT 2\r
2022/11/09 15:30:38.421 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelayAI writeIt
DT 2
2022/11/09 15:30:38.421 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10
rd #60 15\r
2022/11/09 15:30:38.589 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64
1,+2.000000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n
2022/11/09 15:30:38.589 [L1,-1,0] [devSupportGpib.c:982] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelayAI gpibRead
1,+2.000000000000
2022/11/09 15:30:38.589 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12
wrt 15\nDT 2\r
2022/11/09 15:30:38.589 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelaySI writeIt
DT 2
2022/11/09 15:30:38.589 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10
rd #60 15\r
2022/11/09 15:30:38.603 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64
1,+2.000000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n
2022/11/09 15:30:38.603 [L1,-1,0] [devSupportGpib.c:982] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelaySI gpibRead
1,+2.000000000000

In this case the gpibRead seems to get or is able to process the string to remove the stuff after the \r\n.

Is this the expected behavior? Is this an asyn problem?

---

Details of setup
epics 7.0.4.1
asyn 4-42
delaygen 1-2

Hardware Setup
SRS DG535 <-GPIB-> NI GPIB-RS232 <-RS-232-> Moxa <-ethernet-> network

Hardware settings
RS-232 (both on Moxa and NI GPIB-RS232): 115200, 8, N, 1, no flow control (tried hardware and software control, same result)
NI GPIB-RS232 set for S-mode operation
SRS DG535 address set to 15

[Engbretson]

It might well be an asyn issue, but all the weird crap seems to being caused by not setting the correct input/output EOL terminations correctly. I.e. 4001 read 63 1\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0003\r\n Should have those setting set so that nothing else gets read after that initial \r\n so the read becomes just “1” Which should be easier for something to parse out. From: Max Wyman ***@***.***> Sent: Wednesday, November 9, 2022 4:15 PM To: epics-modules/delaygen ***@***.***> Cc: Subscribed ***@***.***> Subject: [epics-modules/delaygen] Unable to get readbacks to update MBBO and BO in DG535 support (Issue #5) When I change a setting that uses either a MBBI or BI as it's "readback", the gpibRead a gets string that it can't deal with. Here's the ioc console output for such a case with most of the asyn traces on when the trigger sourc is changed to "External": 2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12 wrt 15\nTM 1\r 2022/11/09 15:27:32.184 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeSetMO writeIt TM 1 2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:863] [L1,0x12a83b0,50] 164.54.104.15:4001 flushed 63 bytes 2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 11 wrt 15\nTM \r 2022/11/09 15:27:32.184 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeMI writeIt TM 2022/11/09 15:27:32.184 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10 rd #60 15\r 2022/11/09 15:27:32.201 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 63 1\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\0003\r\n 2022/11/09 15:27:35.204 [L1,-1,0] [devSupportGpib.c:982] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeMI gpibRead TM 1\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\321\v\000\000\000\000\000\000\200\000\000\330v\177\000\000\200\000\000\330v\177\000 2022/11/09 15:27:35.204 [L1,-1,0] [devCommonGpib.c:749] [L1,0x12a83b0,50] 25ide:DG535:E1:trigModeMI can't convert msg >TM 1< When I change a setting whose readback is a combination of MBBI and an AI PVs, I don't see such behavior. Here's the output on the console when I change the A channels delay to 2.0: 2022/11/09 15:30:38.390 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12 wrt 15\nDT 2\r 2022/11/09 15:30:38.390 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10 rd #60 15\r 2022/11/09 15:30:38.405 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64 1,+1.600000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n 2022/11/09 15:30:38.405 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12 wrt 15\nDT 2\r 2022/11/09 15:30:38.405 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10 rd #60 15\r 2022/11/09 15:30:38.419 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64 1,+1.600000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n 2022/11/09 15:30:38.419 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 29 wrt 15\nDT 2,1,2.000000000000\r 2022/11/09 15:30:38.419 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelaySetAO writeIt DT 2,1,2.000000000000 2022/11/09 15:30:38.421 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12 wrt 15\nDT 2\r 2022/11/09 15:30:38.421 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelayAI writeIt DT 2 2022/11/09 15:30:38.421 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10 rd #60 15\r 2022/11/09 15:30:38.589 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64 1,+2.000000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n 2022/11/09 15:30:38.589 [L1,-1,0] [devSupportGpib.c:982] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelayAI gpibRead 1,+2.000000000000 2022/11/09 15:30:38.589 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 12 wrt 15\nDT 2\r 2022/11/09 15:30:38.589 [L1,-1,0] [devSupportGpib.c:1388] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelaySI writeIt DT 2 2022/11/09 15:30:38.589 [L1,-1,0] [drvAsynIPPort.c:596] [L1,0x12a83b0,50] 164.54.104.15:4001 write 10 rd #60 15\r 2022/11/09 15:30:38.603 [L1,-1,0] [drvAsynIPPort.c:794] [L1,0x12a83b0,50] 164.54.104.15:4001 read 64 1,+2.000000000000\r\n\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\00019\r\n 2022/11/09 15:30:38.603 [L1,-1,0] [devSupportGpib.c:982] [L1,0x12a83b0,50] 25ide:DG535:E1:aDelaySI gpibRead 1,+2.000000000000 In this case the gpibRead seems to get or is able to process the string to remove the stuff after the \r\n. Is this the expected behavior? Is this an asyn problem?

…

________________________________ Details of setup epics 7.0.4.1 asyn 4-42 delaygen 1-2 Hardware Setup SRS DG535 <-GPIB-> NI GPIB-RS232 <-RS-232-> Moxa <-ethernet-> network Hardware settings RS-232 (both on Moxa and NI GPIB-RS232): 115200, 8, N, 1, no flow control (tried hardware and software control, same result) NI GPIB-RS232 set for S-mode operation SRS DG535 address set to 15 — Reply to this email directly, view it on GitHub<#5>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADHLVCYEPZTWJV4Q4MTJ2F3WHQO75ANCNFSM6AAAAAAR35DCL4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[MarkRivers]

Are all of those null characters part of the documented protocol of the DG535? I suspect they are not. It seems to me that they may be arising from the convoluted Ethernet to GPIB conversion hardware you are using.

I suggest you get a real Ethernet to GPIB converter and try that instead. A $2,300 solution is this: https://www.keysight.com/us/en/product/E5810B/lan-gpib-usb-gateway.html

A $500 solution, which I have used, is this: http://prologix.biz/gpib-ethernet-controller.html.