Hi:
After some private emails with Pawel, the issue was in his device support:
"... changed the waveform data type from double to short and in my
memcopy routine I used pointer arithmetics on a pointer to double, thus
overwriting whatever was in the memory twice as far as it was necessary.
It's not surprising that strange things followed."
In summary, some steps we took to determine what was happening:
* This was about using CSS & the BOY display tool as a client
* IOC was on x86 Linux
CSS was using the pure Java CA client library.
Suggested to use the JNI client library, just to make sure that it's not a
CA client compatibility issue, but that didn't work on the host
(CSS currently includes EPCIS CA JNI binaries for (Redhat) Linux x86 and Mac
OS X).
When using a soft IOC with simple CALC-based 'ramp' PVs, the problem went
away -> likely an issue in the DAQ driver/device support, which was then
found.
Thanks,
Kay
On 10/25/10 10:20 , "Paweł Prędki" <[email protected]> wrote:
> Hello,
>
> I'm having more problems with the data acquisition software I'm
> developing. This time I have no idea where the error I'm getting is
> coming from.
>
> The idea is this - there are 12 DAQ cards in the system, each able to
> support 4 channels. There are 12 action buttons which enable the
> operator to switch between the DAQ cards and one XY Graph that displays
> the waveforms from all 4 channels for each card. The contents of the
> graph is controlled by a $(cardno) macro, which is changed whenever the
> action button is pressed. To be more precise, another panel is loaded
> with a different value of $(cardno) and it replaces the previous one.
>
> It is possible to switch between the cards without any problems until
> data starts coming. I wrote my own device support for the cards using
> the waveform record. Data is sent over TCP/IP and once a full sample set
> is received a scanIoRequest function is called which, in turns, calls
> the read_waveform function where I fill the buffer with valid data.
>
> As I said, once the data starts coming, switching from one card to
> another causes this error to appear:
>
> A call to 'assert(status == epicsMutexLockOK)'
> by thread 'CAS-client' failed in ../dbEvent.c line 460.
> EPICS Release EPICS R3.14.11 $R3-14-11$ $2009/08/28 18:47:36$.
> Local time is 2010-10-25 16:11:12.177758908 CEST
> Please E-mail this message to the author or to [email protected]
> Calling epicsThreadSuspendSelf()
>
> A call to 'assert(status == epicsMutexLockOK)'
> by thread 'CAS-client' failed in ../dbEvent.c line 442.
> EPICS Release EPICS R3.14.11 $R3-14-11$ $2009/08/28 18:47:36$.
> Local time is 2010-10-25 16:11:12.457952837 CEST
> Please E-mail this message to the author or to [email protected]
> Calling epicsThreadSuspendSelf()
> Thread CAS-client (0x82eb670) suspended
> Thread CAS-client (0x8308220) suspended
>
>
> I looked in dbEvent.c but couldn't find anything that would have
> anything to do with my problem. Does anyone have any ideas what could be
> wrong? What could hold the mutex and what is the mutex really guarding here?
>
> Kind Regards,
> Pawel Predki
>
- References:
- CSS panel switching causes epicsMutexLockOK assert fail PaweÅ PrÄdki
- Navigate by Date:
- Prev:
Re: CSS panel switching causes epicsMutexLockOK assert fail Tim Mooney
- Next:
Re: CSS panel switching causes epicsMutexLockOK assert fail PaweÅ PrÄdki
- 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: CSS panel switching causes epicsMutexLockOK assert fail PaweÅ PrÄdki
- Next:
RE: CSS panel switching causes epicsMutexLockOK assert fail Jeff Hill
- 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
|