Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Mon, 06 Dec 2010 16:26:04 +0100

Hi Craig,
I plan to use a different solution for arbitrary whitespace now. I am
thinking of something like "\_".
Regarding the stack overflow I have to dig through the source code.
Dirk
[email protected] wrote:

Hi Dirk,
Thanks for that, I think the ability to consume arbitrary amounts of whitespace is useful as it does make the protocol files easier. At least for me, the backwards compatibly for me isn't a big deal as this is a new device I'm writing support for. btw, I like the new TIME feature, it neatly solves a problem I had with trying to set the time and date in my device. 
I've ran into another problem with the latest snapshots though (both 20101203 and 20101129 but not in 20100615). I'm seeing a crash in StreamCore.cc. It doesn't seem to happen with a device emulator I have but does wit the real device which responds a bit slower (it's an RS-232 over Ethernet device) so it might be timing related. It looks like StreamDevice is getting stuck in a loop as the call stack is over 300 calls deep when it crashes. It's going between evalIn() and readCallback().
Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: KERN_PROTECTION_FAILURE at address: 0x0000000100686e08

[Switching to process 6213]

0x00000001000a0818 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=0x0, size=0) at ../StreamCore.cc:903

903 const void* input, long size)

(gdb) b

Breakpoint 1 at 0x1000a0818: file ../StreamCore.cc, line 903.

(gdb) bt
#0 0x00000001000a0818 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=0x0, size=0) at ../StreamCore.cc:903

#1 0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874

#2 0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070

#3 0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874

#4 0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070

..

..

#311 0x000000010009e823 in StreamCore::evalIn (this=0x102008800) at ../StreamCore.cc:874

#312 0x00000001000a13e3 in StreamCore::readCallback (this=0x102008800, status=StreamIoTimeout, input=<value temporarily unavailable, due to optimizations>, size=0) at ../StreamCore.cc:1070

#313 0x0000000100089c5f in StreamBusInterface::readCallback () at /Users/has09e/src/askapsoft/3rdParty/EPICS/3.14.11/support/streamDevice/streamDevice-2-5/StreamDevice-2-5/src/StreamBusInterface.h:933

#314 0x0000000100089c5f in AsynDriverInterface::readHandler (this=0x1010039b0) at ../AsynDriverInterface.cc:933

#315 0x0000000100089eb8 in handleRequest (pasynUser=<value temporarily unavailable, due to optimizations>) at ../AsynDriverInterface.cc:1356

#316 0x000000010000dd0d in portThread (pport=0x100465f10) at ../../asyn/asynDriver/asynManager.c:828

#317 0x000000010028bbe2 in start_routine (arg=<value temporarily unavailable, due to optimizations>) at ../../../src/libCom/osi/os/posix/osdThread.c:282

#318 0x00007fff804cb536 in _pthread_start ()

#319 0x00007fff804cb3e9 in thread_start ()
The protocol looks like this
one command to send out the poll
get_flashNearN {
    out "A";
    in "NEAR: N %f     NE %*f     E %*f     SE %*f     S %*f     SW %*f     W %*f     NW %*f    ";
}
and 18 commands that are set as INTR/IO scan in the records
get_flashDistNW {
    in "DIST: N %*f     NE %*f     E %*f    SE %*f     S %*f     SW %*f     W %*f     NW %f    ";
}
get_flashCloud {
    in "OVHD %*f     CLOUD %f     TOTAL %*f     P %*2XH %*f C";
}
I've only tested this on the mac so far. If there is any debug trace I can get to help find the issue please let me know.
Regards
Craig
On 03/12/2010, at 9:59 PM, Dirk Zimoch wrote:
Hello Craig,
Thanks for testing it on Mac.
The effect you found is indeed an incompatibility. I think I better
remove it again and look for something better. I was trying to be more
compatible with the sscanf format strings, where a space consumes
arbitrary amounts of whitespace (see: man sscanf). Thus in your case it
is not the last %s but the spaces after the %s that consume the \r\n. I
think I better remove that feature again to stay backward compatible.
Maybe I better go for a special escape sequence for "arbitrary amount of
white space".
Dirk
[email protected] wrote:

Hi Dirk,
Thanks for the new release. I can confirm it builds OK on Snow Leopard 10.6.5. I've run into a difference with the previous snapshot though. I have a protocol as follows
InTerminator = "> ";
OutTerminator = CR LF;
ExtraInput = Ignore;
get_airTemp {
   out "R1";
   in "R1\r\n%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   ,%*s   \r\n%*f,%*f,%*f,%f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f,%*f";
}
to handle the follow command & 3 line response from my device
R1

R1
WS=   ,WD=   ,RH=   ,AT=   ,RG=   ,SR=   ,BP=   ,S1=   ,S2=   ,BV=   ,LC=   ,SV=   ,CC=   ,9R=   ,Ev=
+000006.02,+000106.95,+000051.97,+000027.21,+000006.92,+000010.50,+000902.35,+000019.26,+000018.63,+000012.37,+000035.12,+000012.47,+000249.95,+000009.65,+000004.03
km/h   ,Degrees,%      ,Deg C  ,mm     ,W/m^2  ,hPa    ,Deg C  ,Deg C  ,V      ,mA     ,V      ,mA     ,mm     ,mm
The reason for using "> " for the input terminator is to handle a command prompt that the device sends without a CR LF. I then treat the 3 line response as a single line with "\r\n" in the format string. This worked quite well for the 20100615 snapshot but with the latest, I find that the last %*s before the \r\n also consumes the \r\n. So for the new snapshot I need to remove the 2nd "\r\n" in the format string. Not sure if this change was intentional or not. Other than that, works fine on Mac.
Regards
Craig
-------------------------------------------------------
Craig Haskins
Software Engineer
Australia Telescope National Facility
CSIRO Astronomy and Space Science
P.O.Box 76, Epping NSW 1710, Australia
Phone: +61 2 9372 4309
email: [email protected]

-------------------------------------------------------
Craig Haskins
Software Engineer
Australia Telescope National Facility
CSIRO Astronomy and Space Science
P.O.Box 76, Epping NSW 1710, Australia
Phone: +61 2 9372 4309
email: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System