Re: Teledyne Dalsa Areadetector Driver

[David Vine via Tech-talk <tech-talk at aps.anl.gov>]

Hi Sandeep,

I have an area detector driver for Teledyne Dalsa that I have tested with the Shadobox line of cameras. 

It looks like it might work with radicon as well.

Today i'll post it to github and share a link with this thread.

Best,

David

On Tue, Jul 12, 2022 at 3:27 AM <tech-talk-request at aps.anl.gov> wrote:

Send Tech-talk mailing list submissions to
        tech-talk at aps.anl.gov

To subscribe or unsubscribe via the World Wide Web, visit
        https://mailman.aps.anl.gov/mailman/listinfo/tech-talk
or, via email, send a message with subject or body 'help' to
        tech-talk-request at aps.anl.gov

You can reach the person managing the list at
        tech-talk-owner at aps.anl.gov

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Tech-talk digest..."
Today's Topics:

   1. Teledyne Dalsa Areadetector Driver
      (Sandeep Kumar Malu - STFC UKRI)
   2. Issue with Asyn+StreamDevice on a Raspi CM4 (Florian Feldbauer)
   3. Re: Issue with Asyn+StreamDevice on a Raspi CM4
      (Zimoch Dirk (PSI))
   4. Re: Issue with Asyn+StreamDevice on a Raspi CM4
      (Florian Feldbauer)
   5. Re: Issue with Asyn+StreamDevice on a Raspi CM4
      (Zimoch Dirk (PSI))
   6. Re: Issue with Asyn+StreamDevice on a Raspi CM4 (Maren Purves)
   7. Re: Issue with Asyn+StreamDevice on a Raspi CM4
      (Zimoch Dirk (PSI))



---------- Forwarded message ----------
From: Sandeep Kumar Malu - STFC UKRI <sandeep-kumar.malu at stfc.ac.uk>
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Cc: 
Bcc: 
Date: Tue, 12 Jul 2022 04:09:26 +0000
Subject: Teledyne Dalsa Areadetector Driver

Hi All,

I am looking for Areadetector Driver for Teledyne Dalsa (Model - Radicon 3030) camera and wondering if anyone have already developed one. I see ADCameraLink  can be compiled for Dalsa Frame grabber. If anyone has developed camera specific driver for the same and can share would be of great help.

FYI, I do have all the relevant software licenses.

Many Thanks

Sandeep

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. 

---------- Forwarded message ----------
From: Florian Feldbauer <florian at ep1.ruhr-uni-bochum.de>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc: 
Bcc: 
Date: Tue, 12 Jul 2022 09:44:01 +0200
Subject: Issue with Asyn+StreamDevice on a Raspi CM4
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





---------- Forwarded message ----------
From: "Zimoch Dirk (PSI)" <dirk.zimoch at psi.ch>
To: "florian at ep1.ruhr-uni-bochum.de" <florian at ep1.ruhr-uni-bochum.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc: 
Bcc: 
Date: Tue, 12 Jul 2022 07:56:33 +0000
Subject: Re: Issue with Asyn+StreamDevice on a Raspi CM4
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
>
>



---------- Forwarded message ----------
From: Florian Feldbauer <florian at ep1.ruhr-uni-bochum.de>
To: "Zimoch Dirk (PSI)" <dirk.zimoch at psi.ch>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc: 
Bcc: 
Date: Tue, 12 Jul 2022 10:12:50 +0200
Subject: Re: Issue with Asyn+StreamDevice on a Raspi CM4
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





---------- Forwarded message ----------
From: "Zimoch Dirk (PSI)" <dirk.zimoch at psi.ch>
To: "florian at ep1.ruhr-uni-bochum.de" <florian at ep1.ruhr-uni-bochum.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc: 
Bcc: 
Date: Tue, 12 Jul 2022 09:24:33 +0000
Subject: Re: Issue with Asyn+StreamDevice on a Raspi CM4
You could write an asynInterpose driver that chops the output into 16 bytes chunks. (And maybe delays in between if
necessary.)

On Tue, 2022-07-12 at 07:56 +0000, Zimoch Dirk (PSI) via Tech-talk 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
> >
> >



---------- Forwarded message ----------
From: Maren Purves <m.purves at eaobservatory.org>
To: "Zimoch Dirk (PSI)" <dirk.zimoch at psi.ch>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Bcc: 
Date: Tue, 12 Jul 2022 00:21:37 -1000
Subject: Re: Issue with Asyn+StreamDevice on a Raspi CM4
And for the reads read in 16 byte chunks until you get a 0d.

Maren

On Mon, Jul 11, 2022 at 11:24 PM Zimoch Dirk (PSI) via Tech-talk
<tech-talk at aps.anl.gov> wrote:
>
> You could write an asynInterpose driver that chops the output into 16 bytes chunks. (And maybe delays in between if
> necessary.)
>
> On Tue, 2022-07-12 at 07:56 +0000, Zimoch Dirk (PSI) via Tech-talk 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
> > >
> > >




---------- Forwarded message ----------
From: "Zimoch Dirk (PSI)" <dirk.zimoch at psi.ch>
To: "florian at ep1.ruhr-uni-bochum.de" <florian at ep1.ruhr-uni-bochum.de>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Cc: 
Bcc: 
Date: Tue, 12 Jul 2022 10:27:23 +0000
Subject: Re: Issue with Asyn+StreamDevice on a Raspi CM4
On Tue, 2022-07-12 at 09:24 +0000, Zimoch Dirk (PSI) via Tech-talk wrote:
> You could write an asynInterpose driver that chops the output into 16 bytes chunks. (And maybe delays in between if
> necessary.)

I have extended an existing interpose driver which should fulfill your needs.
https://github.com/paulscherrerinstitute/asynInterposeDelay

(The repo does not have a standard EPICS configure directory and uses a PSI specific GNUmakefile. Feel free to adapt it
to the standard EPICS or any other your build system or simply add it to asyn.)

I wrote this interpose driver to chop output into single bytes with delay. Now  you can tell it to use any chunk size
(with 0 delay or longer, as you need).

Dirk

>
> On Tue, 2022-07-12 at 07:56 +0000, Zimoch Dirk (PSI) via Tech-talk 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
> > >
> > >
_______________________________________________
Tech-talk mailing list Tech-talk at aps.anl.gov
https://mailman.aps.anl.gov/mailman/listinfo/tech-talk

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited