Experimental Physics and
Industrial Control System

Hinko Kocevar via Tech-talk <[email protected]> · Thu, 18 Jul 2019 12:06:09 +0000

I think I've  succumbed to my own blunder. I was using sleep(0.3) instead of usleep(300000).. floating point value of 0.3 for sleep(unsigned int) is a nice way of getting no sleep (literally!).

I did notice that TCP socket is already being opened with TCP_NODELAY in drvAsynIPPort.c which made me think that asyn is already doing it the way I wanted..

Sorry for the noise!

//hinko
________________________________________
From: [email protected] <[email protected]> on behalf of Hinko Kocevar via Tech-talk <[email protected]>
Sent: Thursday, July 18, 2019 12:17:18 PM
To: [email protected]
Subject: pasynOctetSyncIO flushing with drvAsynIPPortConfigure

Hi,

I'm using drvAsynIPPortConfigure() to connect to a network attached device, with a small PIC based MCU handling the TCP/IP. It is XT Pico SXL described here if anyone is interested: http://www.ak-nord.de/en/daten/manual_xxl_ts.pdf.

For my application the XT Pico SXL takes data over network and translates it to SPI messages to talk to SPI peripheral.

I can make it work if the delay between consecutive requests (either pasynOctetSyncIO->writeReadOnce() or pasynOctetSyncIO->writeRead()) is 1 second; I can tell that the SPI peripheral was programmed properly. As soon as the delay is lowered (i.e. 0.3 s) the SPI peripheral does not interpret the data correctly. I have ~ 40 registers on the SPI peripheral to write and do not like to wait > 40 s for this to complete. FYI, using USB programmer from vendor, I can program the SPI peripheral in matters of miliseconds.

I've started looking at the wireshark dumps of what is on the wire and noticed that TCP seems to be "optimizing" when I would like it not to optimize.

Successful SPI peripheral programming, at 1 second delay, as seen on the wire is found in ok.txt attachment. On the other hand, failed programming looks something like in bad.txt attachment (delay between requests was set to 0.3 second).

Finally, the question: Can I force the TCP from asyn somehow not to "optimize", and send/receive 3 bytes at a time even if the delay between my requests is 0.3 (or less)?

Thank you in advance!

Hinko Kocevar

Beam Diagnostics Engineer
European Spallation Source ERIC
P.O Box 176, SE-221 00 Lund, Sweden
Visiting address: Odarslövsvägen 113, SE-224 84 Lund
, Sweden

Mobile: +46-721-79 22 58
Phone:  +46-46-888 32 58

E-mail: [email protected]
Web:    www.esss.se

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System