-*- outline -*- (for Emacs formatting)

*Common Notes:
*===============

**2001, Mar 19 & 20:
Fixes to string data type: Client now receives them,
Server doesn't crash as easily as it did before
when handling strings.
Strings packed as wide char, so that Delphi can receive
string-events from EpicsCAClient.

**2000, Dec 21:
Moved to LabVIEW 6i.
Note that the EpicsCAClient is currently in an unknown state.
Before using this, make sure that you are not accidentally
using parts of the previous installtion.
- Remove all instances of the CA**.llb LabVIEW libraries
  or rename them to *.old_llb.
  LabVIEW will otherwise find them, wherever they are!
- Remove or rename all instances of EpicsCA*.exe so that
  Win32 will not accidentally launch them.

**2000, Jul 27:
ActiveX software and LabVIEW VIs seem to work
on Windows 2000, using RegisterNT.bat.
Update from LabVIEW 5.1 to 5.1.1
causes problems with some VIs.
Until there is a reason to switch to 5.1.1,
this is not investigated for now.

**2000, Jul 26:
LabVIEW exhibits a memory leak:
"Wait On ActiveX Event.vi" leaks
when receiving an event with Event Data.
This is not specific to any of my code,
it can be duplicated with a simple
Visual Basic program that generates ActiveX events.
I asked NI for a fix.
The response was that this will be fixed in LabVIEW 6.0.

**1999, August 29:
Combined Server and Client executables
into a default "ActiveX" directory,
utilizing a common registration script.

*EpicsCAClient Notes:
*======================

Unlike the server, the ChannelAccess client version is still
very untested.

**2001, April 4:
Made sure that chid & evid are removed when EpicsProcessVariable
is deleted (unclear: thought this already happend but experienced
mysterious crashes).

**2001, Mar 19 & 20:
Added put_callback method, based PutWait.vi on this.

**2000, Dec 21:
NOT MOVED TO LabVIEW 6i!
The Client VIs might not work at all for now!

**2000, Jul 25:
Added some VIs for arrays.

**2000, Jul 20:
Disassembled the EpicsCAClient.llb into individual VIs
to make it easier to work with them.

*EpicsCAServer Notes:
*======================
**2001, April 2:
  Handle MatLab arrays (single-dimensional row vectors)
  which are internnally passed as 2-dim arrays (second
  dimension is of length 1).
  Added MatLab examples to ServerTests.

**2000, Dec 21:
  String/Text support:
  While the caget command line program can read a served string,
  the ChannelArchiver causes the EpicsCAServer to crash
  when strings are used.

**2000, Dec 21:
*** Moved to LabVIEW 6.0/6i
  * The memory leak related to ActiveX events is gone.
  * 6i has better support for the COM/ActiveX Variant data type.
  * Per default, all the LabVIEW GUI elements are now cute

*** Added support for time stamps:
  Originally the time stamp was determined in the ActiveXCAServer
  program. User programs like LabVIEW would only pass the value. Now
  they can pass a time stamp, too, which is useful in case e.g. a highly
  accurate hardware event system is available.
  Format of this (Epics) time stamp: seconds and nanoseconds since 1990.

  For LabVIEW support there is now a PVSetT.vi that accepts a time
  stamp (as a U32 seconds/nanosecs cluster, typedef'ed as EpicsTime.clt)
  in addition to the PVSet.vi

  The EpicsCAServer.ProcessVariable has a GetEpicsTime method
  to get the current time from the system clock to test this.
  There is a LabVIEW wrapper PVGetServerTime.vi that calls this,
  there is also a PVGetLabViewTime.vi that calculates the current
  seconds/nanoseconds in LabVIEW (LabVIEW's idea of time is based
  on seconds since 1904). ServerTests/TimeExample.vi shows all this

*** Added support for passing multiple value/time-stamp pairs
  at once in a "burst":
  This was meant to reduce the COM overhead. Current times for
  updating a value in the EpicsCAServer (PVSet*):
     Deadband check     ...in LabVIEW    ...in Server
     change >= deadband       0.20         0.18
     change <  deadband       0.03         0.18

  When collecting N values+time stamps in LabVIEW arrays and passing
  those as a whole with the new PVSetMulti.vi (see MultipleVals.vi
  example), the result is:
     N=15 ->  0.08ms per value,
  compared to 0.20ms when sending values one by one.

  In principle the client program sees no difference:
  It received one value after the other as if the usual PVSet was used.

  The catch:
  The CA Server library has a fixed queue length which currently
  doesn't allow more than N ~ 15 with brief intervals between calls.
  When using N>15 or sending N=15 bursts in a no-wait loop, the server
  cannot send the queued values to clients in time so values are lost.
  (It's about 15, it depends on the number of clients, the point is:
   It's limited enough to make the burst support useless for now)

  This is intentional: An ordinary Epics IOC would run the server at
  a rather low priority. Network delays must not affect the
  performance of the front-end.
  In order to support this special "burst" mode, the CAS library could
  be extended to allow changing the queue size/pool, though it's unclear
  how this fits into the bigger CA plan:
  Should CA clients also be able to change the queue size, must this
  be guarded by CA security, ...
	
***Changes/Considerations for Porting existing software:
- Existing LabVIEW code doesn't port transparently:
  E.g. LabVIEW 5.1 property nodes for
      EpicsCAServer.ProcessVariable.name
  would still show "name" in LabVIEW 6i but won't work until
  "name" was again manually picked from the property listbox.
  The behaviour or "To G data.vi" has changed, it now creates
  errors where it didn't before.
- The COM interface had to be extended to support passing time stamps
  and multiple value/time pairs.
  Since LabVIEW can now also handle VARIANTS much like any other data
  type, the type-specific interface elements were removed wherever possible.
- New LabVIEW wrappers for the time stamp support were needed. Simply
  adding those would result in too many VIs, not really necessary when
  utilizing the better VARIANT support.
  As a result these previous VIs have been REMOVED:
    PVSetU16, PVSetFloat, PVSetArray, PVSetFloatArray, PVSetU16Array,

  PVSet now accepts a VARIANT and thereby replaces all the above.
  When porting LabVIEW 5.1 diagrams, this means that almost all the
  unresolved VIs can be replaced by PVSet.

  There are still some type specific set VIs left:
  PVSetEnum:   Takes an integer and checks if a corresponding enumeration
	       string, generated by PVInitEnum, exists.
  PVSetBool:   The same but for booleans.
  PVSetString: Takes a string, no deadband checking done. 
               (actually takes a variant, can be used to circumvent
	        the deadband check in LabVIEW)

  PVSetT, PVSetEnumT, ...: Like the above but in addition they accepts
  a time stamp.


*2000, Jul 27:
Server gives error message when creating a PV
with an already existing name.
(Name is checked on this server only,
 not on the whole network)
Update on the LabVIEW crash problem:
Using a simple Automation server in Visual Basic
that has a "CausePing" method and sends a "Ping"
event when called, LabVIEW crashed occasionally
when trying to connect to it.
So it must be a generic LabVIEW/AX startup problem.

**2000, Feb 23:
Added delays in PVInit, PVInitEnum:
Sometimes, LabVIEW crashes in ax-events.dll
during startup. Neither I nor the NI support person
knew exactly why.
The delay seems to help a bit, but it does not cure the problem.
For now I'm shifting the blame to LabVIEW because
- LabVIEW crashes, not the "EPICSCAServer" program.
  If my program was misbehaving, LabVIEW should
  report this instead of crash
- I have not seen Visual Basic crash when using "EPICSCAServer".
- It's not the first error in ax-events.
  NI claimed LabVIEW 5.1 could handle ActiveX events
  when in fact this was limited to ActiveX controls.
  -> this resulted in the updated version of ax-events.dll
- The NI knowledge base has reports about how one should
  run ax stuff in the UI thread. This is clumsy because
  it stops the communication when you e.g. move the window,
  but is shows that there are still problems with handling
  threading issues with AX.
  The "sometimes crash" problem could be just such a timing/threading
  problem.

The bottom line remains:
-----------------------------
There is an unsolved problem causing LabVIEW to crash sometimes.
If that happens, exit LabVIEW, kill the EpicsCAServer
(Might show up at "EpicsC~1") and try again.

**2000, Feb 17:
Support Text.
The strings to serve are limited to "aitFixedString" (40 chars.)
and one should probably prefer the "Enum" type,
but other than this the strings can be served
and also received via "CA put" just like
the remaining data types.

**2000, Jan. 21:
LabVIEW VIs:
For PVSet*.vi, deadbands are checked inside LabVIEW
before the server is called.
While the server does also perform a deadband check,
the COM call into the server accounted for most of the time
when we benchmarked LabVIEW applications that used the CA Server.

Example for PVSet Time [ms] on 450 Mhz PentiumII:

Deadband checked in...
LabVIEW  Server
New Value0.34     0.27
Within Deadband  0.05     0.27

So when testing the deadband in LabVIEW, a PVSet for a changing
value takes a little bit longer than before.
But for values that haven't changed, the PVSet time in reduced to 1/5th!

**1999, October 29:
For values changing inside deadband,
no monitors were send (OK),
but the time stamp was still updated (wrong, now fixed)

**1999, August 4:
Found the U32/I32 quirk in the default LabVIEW
"Wait on ActiveX event.vi".
Debugging aids:
- Extended the PVHandle to carry the PV name
- PVTestError.vi

**1999, July 21:
Found the "Missing ATL.DLL" bug that causes
registration to fail on some machines.

**1999, July 9
PVInit*.vi:
Added check for successful connection
to EpicsCAServer to get better error
report in case of failure.

**1999, June 24
PVInit*.vi, PVCheckInput.vi:
Cause event queue to queue unchecked events
and not to ignore previous events,
so that you won't miss updates
if you check only from time to time.

Fixed deadband algorithm:
With a deadband of 1, changes like
1, 1.1, 1.2, ... 2.0, 2.1, ..
were ignored because each individual step
was below deadband.