Hi Dirk,
In my test I tried to write a parameter of type "u_short" (in the
Pfeiffer nomenclature) which has just 3 bytes,
But many parameters are actually of type "old_bool" or "int" having 6 bytes.
epics> dbpf SCATTERCHAMBER:VACUUM:TP:IntSelLckd 0
DBF_STRING: "off"
2022/07/12 09:59:28.743 /dev/ttyAMA0 write 20
0011006106000000015\r
2022/07/12 09:59:29.393959 rs485 SCATTERCHAMBER:VACUUM:TP:IntSelLckd:
No reply within 500 ms to "0011006106000000015<0d>"
2022/07/12 09:59:29.395 /dev/ttyAMA0 write 16
0010006102=?102\r
2022/07/12 09:59:30.033945 rs485 SCATTERCHAMBER:VACUUM:TP:IntSelLckd:
No reply within 500 ms to "0010006102=?102<0d>"
Got 16 bytes:
0011006106000000
Got 16 bytes:
15\r0010006102=?1
I also tried to use a simple python script to send messages with the
same result. It seems the Kernel accepts more then 16 bytes but only the
first 16 get send.
The 17th byte seems to get lost while the remaining bytes are send with
the next write-call.
Also for those parameters having 6 byte payload data, my workaround I
mentioned in the previous mail won't work...or I have to calculate the
checksum outside of streamdevice.
Guess I will check if this issue is known and if there is some
workaround independent of EPICS.
Cheers,
Florian
On 7/12/22 09:56, Zimoch Dirk (PSI) wrote:
Hi Florian,
If the output buffer is not able to accept all bytes at once, then the write() function should have returned 16 instead
of 17 and drvAsynSerialPort writeIt() would try again with the remaining bytes, waiting for writeTimeout and failing
with asynTimeout if it cannot send.
But if the kernel driver implements write() in a way that discards bytes, then all hope is lost.
Try with some other program, for example from the command line:
echo "this is a string longer than 16 chars" > /dev/ttyAMA0
Dirk
On Tue, 2022-07-12 at 09:44 +0200, Florian Feldbauer via Tech-talk wrote:
Hey all,
we have a small vacuum chamber to test our sensor modules after production.
The 2 Pumps and 2 valves are controlled via a Raspberry Pi CM4 running
linux-aarch64.
The Turbo pump and digital gauge are from Pfeiffer Vacuum and controlled
via RS485.
I noticed some strange issue. I was able to read all parameters from
those devices, but changing them fails.
To further investigate I attached a 2nd PC to the RS485 bus just
listening and found the following:
epics> asynSetTraceIOMask rs485, 0, ASYN_TRACEIO_ESCAPE
epics> asynSetTraceMask rs485, 0, ASYN_TRACEIO_DRIVER
epics> dbpf SCATTERCHAMBER:VACUUM:TP:CtrlViaInt RS485
DBF_STRING: "RS485"
2022/07/12 09:25:52.084 /dev/ttyAMA0 write 17
0011006003002125\r
2022/07/12 09:25:52.721930 rs485 SCATTERCHAMBER:VACUUM:TP:CtrlViaInt:
No reply within 500 ms to "0011006003002125<0d>"
2022/07/12 09:25:52.722 /dev/ttyAMA0 write 16
0010006002=?101\r
2022/07/12 09:25:52.762 /dev/ttyAMA0 read 16
0011006003002125
2022/07/12 09:25:52.766 /dev/ttyAMA0 read 1
\r
epics>
The 2nd PC received this:
Got 16 bytes:
0011006003002125 [30 30 31 31 30 30 36 30 30 33 30 30 32 31 32 35]
Got 16 bytes:
0010006002=?101\r [30 30 31 30 30 30 36 30 30 32 3d 3f 31 30 31 0d]
Got 17 bytes:
0011006003002125\r [30 30 31 31 30 30 36 30 30 33 30 30 32 31 32 35 0d]
As you can see, on the first message which was send from the IOC, the CR
is missing.
I guess the issue is, that asyn tries to write all 17 bytes at once, but
the tx buffer on the Raspberry Pi can only hold 16 byte, so the CR gets
lost.
Is there a way to limit the number of bytes written in a single write
call with asyn?
Luckily in this case the length of the telegrams is well known and I
could simply use 2 OUT statements in my protocol file to work around
this problem, but what if I want to control a device where the length
depends on the payload data?
Cheers,
Florian
--
Ruhr-Universität Bochum
AG der Experimentalphysik I
Dr. Florian Feldbauer
NB 2/131 / Fach 125
Universitätsstr. 150
D-44801 Bochum
Office: NB 2/134
Phone: (+49)234 / 32-23563
Fax: (+49)234 / 32-14170
https://paluma.ruhr-uni-bochum.de
- References:
- Issue with Asyn+StreamDevice on a Raspi CM4 Florian Feldbauer via Tech-talk
- Re: Issue with Asyn+StreamDevice on a Raspi CM4 Zimoch Dirk (PSI) via Tech-talk
- Navigate by Date:
- Prev:
RE: EPICS compilation errors Adrian Martinez via Tech-talk
- Next:
Re: Issue with Asyn+StreamDevice on a Raspi CM4 Zimoch Dirk (PSI) via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
<2022>
2023
2024
- Navigate by Thread:
- Prev:
Re: Issue with Asyn+StreamDevice on a Raspi CM4 Zimoch Dirk (PSI) via Tech-talk
- Next:
Re: Issue with Asyn+StreamDevice on a Raspi CM4 Zimoch Dirk (PSI) via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
<2022>
2023
2024
|