top of page

Lili's Art Decors Group

Public·54 members
Colton Green
Colton Green

Virtual Usb Multikey 64 Bit Driver - UPD

Ring buffers are only used when records have SCAN=I/O Intr. They allow the record to process all of the arrays from a rapid burst of callbacks from the driver. However, because Channel Access does not provide any buffering for arrays, even if the record processes for each new array callback, Channel Access will not necessarily send events for each value, because it just sends the current record value when the CA callbacks are done.

Virtual Usb Multikey 64 Bit Driver -


It has always been asserted that except for devEpics asyn only really depends on libCom from EPICS base. People who are interested in using asyn drivers from other control systems, want to minimize the dependencies of libraries from EPICS base. The following lines have been added to asyn/configure/CONFIG_SITE:

A new C++ class was added, asyn/asynPortClient/asynPortClient.cpp. This class makes it easy to write a C++ application that starts existing asyn port drivers and communicates with them over standard asyn interfaces without running an IOC.

A new test application directory was added testAsynPortClient. This tests running C++ applications that communicate with asyn port drivers without running an IOC. This currently contains a single test application, testAsynIPPortClient.cpp. This program creates an asynIPPort driver, and uses the command line arguments to set the hostInfo string, a single command string to send to the server, and optionally the input and output EOS. It then prints out the response from the server. There are 3 example shell scipts that show how to use testAsynIPPortClient to communicate with a Web server, XPS motor controller, and a telnet host respectively.

Added support functions for setting timestamps in asyn port drivers. These can be used to set the timestamp when the port driver received data. The driver can then set the asynUser->timeStamp field to this value for all input records on read and callback operations. Records that have TSE=-2 will have this timestamp. There is support for registering a user-supplied function to provide the timestamp, which will override the default source that just calls epicsTimeGetCurrent().

Added new virtual methods to support Eos operations on the asynOctet interface. These are setInputEosOctet(), getInputEosOctet(), setOutputEosOctet(), getOutputEosOctet(). Changed the report() method to print the current values of the inputEos and outputEos.

Changed the base class readXXX() functions (e.g. readInt32(), readFloat64(), etc.) to call pasynManager->getTimeStamp() and set the pasynUser->timestamp field to this value. The readXXX() functions in derived classes should also do this, so that records with TSE=-2 will get the timestamp from the driver.

Improved the initMbboDirect function in devAsynUInt32Digital.c. If an initial value is read successfully from the driver it now sets the .Bn fields in the record. It also sets VAL rather than RVAL and returns 2 rather than 0. Thanks to Andrew Johnson for this.

Fixed a bug in devAsynXXXArray.h to handle case of multiple interrupt callbacks between record processing. Previously this would result in a call to the asynXXXArray->read() in the driver, which is not correct. The asynXXXArray device support does not have a ring buffer, so multiple interrupt callbacks between processing results in data being "lost", i.e. the record processes more than once with the same data. This is not really an error, but we now issue an ASYN_TRACEIO_DEVICE warning. This is analogous to ring buffer overflow for non-array data types.

Added new method asynPortDriver::flushOctet(), which implements asynOctet::flush(). The base class implementation reproduces the behavior of asynOctetBase.c::flushIt, i.e. it calls pasynOctet->read() repeatedly with a timeout of 0.05 seconds until it gets no data back. But now drivers can implement their own version of flush() if a different behavior is desired, which was not previously possible.

Changed the "ring buffer overflow" messages from "ASYN_TRACE_ERROR" to "ASYN_TRACEIO_DEVICE", so they do not appear by default. These messages are not really errors, but warnings that record processing it not keeping up with the rate of driver callbacks for records with SCAN=I/O Intr.

Added a new interface, asynEnum. This interface is designed to allow drivers to set the strings, values, and severities for record enum fields. This can be done both at iocInit(), in init_record() with the pasynEnumSyncIO->read() function, and after iocInit via callbacks to device support.

Previously it was not possible for input records with SCAN=I/O Intr to have their alarm status set at all. This support has been added. Device support now uses the pasynUser->auxStatus field in the pasynUser passed to the callback function. If auxStatus != asynSuccess then the record alarm STAT and SEVR are set to values based on the asynStatus. asyn port drivers can now signal error status to clients in callback functions by setting pasynUser->auxStatus to asynSuccess, asynTimeout, asynError, etc. This change should be backwards compatible with all drivers because the pasynUser that is used for the callbacks is private to the callback function, and the auxStatus field is initialized to 0, which is asynSuccess.

Added new waveform record device support, asynInt32TimeSeries and asynFloat64TimeSeries. These use callbacks from the driver on those respective interfaces to collect a time series of values in a waveform record. Added new medm file asynTimeSeries.adl for this, and added an example waveform record to testEpics/Db/devInt32.db.

Added a new test application, testErrorsApp. This application uses a driver based on asynPortDriver to test error handling for all interfaces and all records support by the asyn standard device support (asyn/devEpics). It can be used to test error handling of records with both periodic scanning and I/O Intr scanning. It also tests the new asynEnum interface for setting enum strings, values, and severities at iocInit.

Cleaned up logic for callbacks on asynUInt32Digital interface. It was not doing callbacks if the value had not changed but an interrupt had occured for bits in the mask. This would happen when interrupts were only enabled on the falling or rising edges but not both. Added an additional form of setUIntDigitalParam that takes an interruptMask argument. In the previous releases drivers were calling setUInt32Interrupt for callbacks which is not correct. That function should only be called by device support to tell the driver which interrupts to recognize. These problems made the quadEM not work correctly with the ipUnidig.

Bug fix for devAsynInt32 and devAsynFloat64: it was not freeing the mutex in processAiAverage if numAverage==0, i.e. there had been no callbacks from the driver since the record last processed. This would hang the next thread that tried to take the mutex, typically the driver callback thread.

Fixed a bug in driver initialization. The driver had not completed all required initialization before it called pasynGpib->registerPort. Because pasynGpib->registerPort registers the asynCommon interface, that now normally triggers an immediate callback to vxiConnect, and the driver was not yet properly initialized to handle that callback.

Added an additional example driver, asynPortTest, that uses asynPortDriver. It implements the asynInt32, asynFloat64, and asynOctet interfaces to communicate with the echo server using asynOctetSyncIO calls. This tests nested SyncIO calls. Added a new startup script, database and medm screen for testing this new driver.

Fixed bug in getXXXParam. It was not returning error status when a parameter was undefined. This caused device support to use undefined values for output records, because the initial read from the driver during device support initialization did not return an error it should have.

Support has been added for devices such as web servers that require a connect at the beginning of each transaction. To enable this behaviour, specify "http" as the protocol in the drvAsynIPPortConfigure command and ensure that each transaction ends with a read that detects the broken connection from the device. Note that the device will always appear connected. The connect/disconnect around each transaction is handled within the drvAsynIPPort driver.

Fixed bug which caused an error when writing or reading in binary format if the driver did not implement the get(Input/Output)Eos functions. This bug was introduced when readRaw and writeRaw were removed from asynOctet in release 4-10.

A problem was introduced in R4-11 by not starting the autoconnect process until iocInit(), and operations that do not use the XXXSyncIO functions thus fail before iocInit(). This means, for example, that calls to asynSetOption() to set serial port parameters fail if done in a startup script before iocInit(). R4-12 fixes this problem by decoupling autoconnect operations from iocInit(). NOTE: The first call to the pasynCommon->connect() function now happens almost immediately after pasynManager->registerInterface() is called for the asynCommon interface. This timing is different from all previous asyn releases, and it means that port drivers must initialize everything required by asynCommon->connect() before they register the asynCommon interface. This may require minor re-ordering of the initialization sequence in some drivers.

A new C++ base class called asynPortDriver from which real asyn port drivers can be derived. It greatly simplifies the code required to write a new asyn port driver. It is documented here.

A new test application to demonstrate the use of the new asynPortDriver C++ class. This driver simulates a simple digital oscilloscope, and includes a C++ driver, EPICS database, medm screen, and an example iocBoot directory in ioctestAsynPortDriver. It is described in the documentation for asynPortDriver.

Replaced scanIoRequest with direct call to rset->process in interrupt callback routines in all device support. Without this fix if another interrupt occurred before the first scanIoRequest was complete bad things could happen. The data from the first interrupt would be lost, and the read function in the driver would be called when it should not have been.


Welcome to the group! You can connect with other members, ge...


bottom of page