Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Mon, 25 Oct 2010 12:06:48 -0400

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
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System