Menu
▾
▴
#1 fft function not working
fft not being processed
In startviaqs/loopOnSignal a t ~ line 1004
bufPtr->busy is false but bufPtr->stale is not true so
we never reach the switch statement to case and test
for case 4 (external trigger) which is used for fft
external function.
COuld this be because I have defined fft functions in
the config before some more (digital io) parameters
that use auto?
Logged In: YES
user_id=1127717
There is a problem with bufPtr->stale not being set
anywhere. Same issue existed when trying to set the value
from console. Whenever new data is to be set, stale must be
set to true manually.
I have previously checked for write access to stale variable
and not found it anywhere.
Logged In: YES
user_id=1150327
Hi Steve, did you get a reply from John re FFT bug?
Logged In: YES
user_id=1127717
No, actually this has nothing to do with configuration. The
configuration gets processed fine, because it is a two stage
process anyway (first the file parse, then the dependency
resolution).
The problem here is with all external functions. Each
functions specifies the SOURCE parameter, which determines
to which parameter this function is bound (i.e. BPM_X_FFT
has SOURCE set to 2 which is BPM_X). For performance reasons
though, the BPM_X_FFT value does not get updated on change,
but only whenver the user requests it (i.e. refreshProperty
in console).
This however has some problems, especially with regard to
available data and synchronization. Refreshing a property
only marks the butPtr as stale (actually it should, but it
does not) and then moves on. When the value is actually
updated is not known. In typical application you will first
call the refresh property and then read the value of
function parameter (BPM_X_FFT). In most cases the result
will be old value, since fft calculation (or the very
minimal invocation of the external function) will take
considerably longer than time between the two calls to the
resfreshProperty and read value.
I have insofar looked into two ways two solve this problem.
One is to retain the current method of operation. After the
refreshProperty is called, caller will run in a loop,
checking for bufPtr->busy flag (while (bufPtr) // wait).
This is rather simple but just calls for applications hangs.
Imagine EPICS running in several threads, each calling the
same external function. Since all of them will be processing
the VIAQS property continously, bufPtr->busy will be almost
always true.
The other way I've been trying is to make external function
passive. This means it would be called only when input would
acquire sufficient data to actually process new frame of
data. This would make client side operation trivial, it
could however lead to higher CPU usage. I believe the later
would not be problematic, since VIAQS will only support a
small number of parameters.
Unfortunatelly, there is no good solution to this, the best
way for this would be, to have a callback, that would
indicate, when an external function has been processed. But
since the shared memory structure is not most suitable for
this, I'm not sure if it can (or should) be done.