Undulator device versions
This document contains version information for the undulator device.
The first move after the RackPower has been turned on, results in a move error. It stops by itself. It is necessary to send a Reset to the Device for new movements. After this first trouble everything seems OK.
990409 JSN
Change code so UndulatorMaxMoveTime depends on how large a movement and the undulator speed. (JSN 010322)
Version 1.25.121.175 (061114 JSN):
UndulatorDevice is now more stable towards failure of CSerialPort:Disconnect failure (hanging of CloseHandle). The failure is reported to ConSysLog and to Console (if not closing the device)
Version 1.25.121.174 (061113 JSN):
Moved Disconnect port to WaitUntilStopped, so that the occasional hanging of COMport CloseHandle is less fatal (all other persistent files saved).
Version 1.25.121.172 (061113 JSN):
Better handlng of communication errors in ASCII encoder, escpecially in the startup of the encoder.
Version 1.25.106.148 (060125 TW/JSN):
Corrected Bugs:
Moved commands through the client connection to one thread, CUnduDevThread
BUG: Hvis devicet stoppes under en undulator flytning, så vil PollDriver() afslutte straks. MoveUndulator() vil derfor ikke blive signaleret at undulatoren ikke kører mere, og vil først afsluttet når flytningens max flyttetid er udløbet. => Deviced for hele nedlukningen af ConSys til at hænge. : Solution: Changed wait for
Version 1.25.106.148 (060125 TW):
Corrected Bugs:
CSDP5Single - Occasional heap errors when accesing SDPerrorString: All data must be protected by the 'monitor' from CSerialPort. This is not the case in the present code. Access to SDPerrorString in UpdateSDPErrorString gave occaisinally heap errors - this has temperary been solved by introducing m_spdStatusStringMonitor.
CTRencoder: Same correction as in CSDP5Single.
Version 1.24.96.134 (040902 jsn):
Implemented moveInhibited.
Version 1.23.92.126 (tw 2004-03-09):
BUG CORRECTED (HOPEFULLY - NOT Tested): 100% use of CPU during close - kernel took very long time to close. The reason seemed to be in the PollDriver method - when closed, the m_UnduDevClosing was set true in PreStopDevice, leading to imeadate exit of the PollDriverMethod => 100 % CPU usage.
Implemented write history in undulator device - not tested.
REMARK: Persistent store of histories is changed, when new version has been run on front-end, the temp code in the
Version 1.23.92.119 (040213 TW):
Implemented history on Gap set and read back. Not tested - could not run device on dev. PC).
Version 1.16.69.87 (1/8-02 jsn):
* MoveSlow implemented.
* Sleep(10) in CUndulatorDevice::PollDriver changed to Sleep(50) to avoid so
much CPU time used when moving the undulator. Also move to top of PollDriver in
order to wait before getting new values.
Version 1.16.61.80 (1/5-02 jsn):
DeActivateBrake controlbit implemented.
Version 1.13.45.51 (6/4-01 jsn):
Now allows 200 s for undulator movement.
Implemented fast undulator move.
Version 1.11.40.51 (4/8-00 jsn):
Changed to new closing method.
Version 1.11.36.45 (19/7-00 jsn):
Minimum gap changed to 23 mm (from 25).
Version 1.1.13.24 (9/4-99 jsn):
Strong cleanup of the device. Stopping of the decice changed to present day standard (StopDevice() and WaitUntilStopped()). MoveUndulator() has been tightened. backlash and backlashSize parameters added.
Version 1.1.12.16 (23/2-99 TW):
Initialisation in CKernelDevice, CConSysKernel changed - now loads all devices and call create before starting the client construction and database initialisation. All database load and client creation in the devices must be done in separate threads in the devices and must wait for the new sync. object, m_devicesLoaded in the CConSysKernel, to be TRUE before database initilisation/client creation.
The service thread, CUnduDevThread, has been blocked until devices has loaded.
REMARK: The device needs an overall:
1) all Sleep(X) must be substituted with something like
m_UnduDevClosing.WaitForTrue(X);
if ( !(BOOL) m_UnduDevClosing) {
.... < original code >
} else {
.... < evt. Clean up code before closing>
}
2) All ConSys client operations (create, delete and Data() etc.) must be protected by a monitor.
3) MoveUndulator() must check for a valid ConSys client before writing data to it !
Version 1.1.2.5 (6/7-98 KTN):
Report generation
Report generation for the ConSysManager implemented (version 1.1.2.4).
Last Modified 29 March 2019