> But Presently I am testing for 2 values( 2 interrupts near as 50ns) and facing problem.
> That may be because of no buffer for waveform interrupt.
Yes, it is because there is no buffering of waveform callbacks.
> Will it work if we create buffer in the Thread calling callback?
The problem is that your driver needs to wait until the waveform record has processed from callback N before doing callback N+1. The only way I can think of to do this is to have the waveform record forward link to another record that
sends a “Done” message to your driver. When your driver get the Done message it then does another callback, using its internal waveform buffer.
> or any other way to buffer the values for consecutive interrupts?
You could write your own device support to do the buffering. But it is probably simpler to put it in your driver.
If you want useful help from this group you should really tell us the actual requirements of your system.
What are you trying to do?
How large will your waveforms be in the real application?
What is the average and maximum callback rate in the real application?
Mark
But Presently I am testing for 2 values( 2 interrupts near as 50ns) and facing problem. That may be because of no buffer for waveform interrupt. Will it work if we create buffer in the Thread calling callback? or any other way to buffer
the values for consecutive interrupts?
Thank you
Vishnu
From: Mark Rivers <[email protected]>
Sent: Sun, 23 Feb 2014 02:31:26
To: Vishnu Patel <[email protected]>
Cc: techtalk <[email protected]>
Subject: Re: Waveform record I/O interrupt. asyn
If your driver can have new values every 50 nanoseconds, and can do that continuously, then there is no way that EPICS record processing can keep up. You need to rethink your approach.
________________________________
From: [email protected] [[email protected]]
Sent: Saturday, February 22, 2014 2:28 PM
To: Mark Rivers
Cc: techtalk
Subject: Re: Waveform record I/O interrupt. asyn
In my case the drive can have new value at maximum 50ns fast. Presently, i am testing 2 consecutive interrupts. But that may be continuous or burst.
Thanks
Vishnu
From: Mark Rivers <[email protected]>
Sent: Sat, 22 Feb 2014 20:21:00
To: Vishnu Patel <[email protected]>, "techtalk " <[email protected]>
Subject: Re: Waveform record I/O interrupt. asyn
> In devAsynXXXArray.c dbScanUnlock has been used before scanIoRequest(). Can it create problem for repeating same value?
No, it does not matter the order there. scanIoRequest just queues a request to process the record later in a callback thread.
> My assumption is as dbScanUnlock and before scanIoRequest() execute, value change and second time triggers interrupt. This result same value for both interrupts.
The problem is that your driver does a second callback after the first callback has called scanIoRequest but before the callback thread has processed the record.
> I checked interrupt callback code in devAsynInt32.c where epicsMutexUnlock has been used after scanIoRequest().
That does not matter. In devAsynInt32 that is a private mutex, so the callback does not call dbScanLock(). That mutex protects the ring buffer so that 2 threads are not accessing the ring buffer at the same time.
In devAsynInt32 if another driver callback occurs before the record processes then the new value is placed in the ring buffer. This can handle the situation of short bursts where the driver callbacks happen faster than record processing. But if the driver callbacks
continue to happen faster than record processing, then the ring buffer will overflow and some values will be dropped.
This is much harder to handle with arrays because it may involve allocating and copying large amounts of data in order to buffer it.
You said your driver can produce new values that are only 1 microsecond apart. Does it do this continuously, or only in short bursts? If short bursts, then how many rapid callbacks in a burst? Are your arrays only 3 elements long in the real application, or
was that just for testing?
Mark
________________________________
From: [email protected] [[email protected]] on behalf of Vishnu Patel [[email protected]]
Sent: Friday, February 21, 2014 12:35 PM
To: techtalk
Subject: Waveform record I/O interrupt. asyn
Hello,
I am facing problem in I/O Interrupt for waveform record in the asyn. If the value of waveform record change very fast then some of the samples missing or same sample repeat twice even if before p_interruptInt32Array->callback () function the value is scanned
properly by driver. But i think the read value is pushed to the callback but it is not handle that much fast in the callback.
I checked the code for interruptCallbackInput in devAsynXXXArray.h.
In devAsynXXXArray.c dbScanUnlock has been used before scanIoRequest(). Can it create problem for repeating same value?
My assumption is as dbScanUnlock and before scanIoRequest() execute, value change and second time triggers interrupt. This result same value for both interrupts.
I checked interrupt callback code in devAsynInt32.c where epicsMutexUnlock has been used after scanIoRequest().
Thank you
Vishnu
[http://sigads.rediff.com/RealMedia/ads/adstream_nx.ads/www.rediffmail.com/signatureline.htm@Middle]<http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
Get your own FREE website, FREE domain & FREE mobile app with Company email.
Know More ><http://track.rediff.com/click?url="">>
[http://sigads.rediff.com/RealMedia/ads/adstream_nx.ads/www.rediffmail.com/signatureline.htm@Middle]<http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle?>
Get your own FREE website, FREE domain & FREE mobile app with Company email.
Know More ><http://track.rediff.com/click?url="">>
Get your own
FREE website,
FREE domain &
FREE mobile app with Company email.
|
Know
More >
|