25-Aug-2008

• Finished fixing MasterMonitor?.cc.
• Merged Miiop and IIOP.cc to eliminate redundant functionality (and to keep all IIOP related code in one place). All IIOP access software now resides in MIiop.cc.
• Fixed code from MasterMonitor?.cc up through SurfaceTemperature?.cc
• Moved houses. Took ~ 1/2 week to finish this before this weekends Va Beach 1/2 marathon.

18-Aug-2008

• Continued slogging my way through a plethora of build errors, ridding code of vestiges of old VxWorks? code and arcane, obsolete C++ constructs. Currently bogged down in MasterMonitor?.cc and anticipate being stuck there for a couple of days.
• PTCS Servo Design meetings, and resulting work account for significant amount of time.
• Sick one day.

11-Aug-2008

• Jason Ray informed me that actuators continue to disable due to unknown causes .. I requested a list of the usual suspects. I decided to get a better handle on this and started looking (again) for actuators which has oscillating position readbacks in hopes that some would correlate with those which auto disable. In the process, I realized that my understanding of how actuator index relates to Physical (Rib/Hoop) coordinates was wrong and after much head scratching, code review, and digging through arcane notebooks, finally came up with a proper mapping between actuator index, and rib/hoop, lvdt module, IIOP, and channel#.
• Collected more position error data on the A Surface, in an attempt to look for unstable LVDT position readbacks. Ran my Python script (find_unstable_lvdts.py) to determine which actuators are "wiggling". Lo and behold, the list I get back has many actuators which are at same Rib Hoop location of the ones Jason was seeing disable, including a group of 8 which are on a single LVDT module.
• Jason took a look at the LVDT module associating with the "wiggling" actuator positions and found the module to be fault. After replacing the module, we ran the python script again, and saw the unstable actuator set was reduced by 8 (from 13 to 5). JD and Jason will go back and look at remaining "wiggling" actuators over the next few days.
• After making all the obvious code changes necessary to integrate the master and (former) slave code, I decided to be brave and do a build. As expected, 100's of compile errors generated. Am working my way, module by module to clean up the errors and get an image which will link. Many errors are due to fat fingering on my part, some due to the old and now invalid 2 slave system architecture, and alot due to C++ code which was legal under the old vxWorks system, but is not illegal under modern C++. From what I'm seeing, this effort will continue into next week.
• An aside. In an attempt to get the HW Watchdog module to build, I realized that the serial device needed replaced. Found and tried out an RTAI serial driver which seems to work for this application. Bench test results look good, so I rigged the access routines to the new serial driver into the HW Watchdog task.

04-Aug-2008

• Extensive modifications to Translator to support "flat" actuator space. Then, in test harness, merged 2 slave arrays into one and ran through Translator to compare results against 2 slave system. After initial confusion (due to incorrect array dimensions (NUMBER_OF_ACTUATORS vs MAX_ACTUATORS), finally got reasonable results.
• Hacked Dispatch.cc to eliminate use of RPC and call SlaveAccessor? access routines directly.
• In Dispatch.cc; R&R vxWorks task, msgque with RTAI equivalent constructs.
• In ActiveSurfaceRPC?.CC; R&R vxworks tasks, and msgques with RTAI equivalents.
• Modified main.cc to breakout all POST steps into a separate function call. Also, now create all Tasks via pthreads mechanism.
• Currently working through all code which assumes a 2 slave systems and am modifying to access flat actuator space.

28-Jul-2008

• 1 day vacation
• Many PTCS Servo S/W design meetings
• Need to remove all translating master <==> slave actuator space for 2 slave system. This was not intuitive for me, and I've had to spend a bit of time breaking out the translation code and unit testing just so I understood what was happening in the translation process. Next step is to replace the 2 slave arrays with a single double sized array and compare results against unit tests.

21-Jul-2008

• Monitor task was not running. Tracked down to singleton start() method which created a task which blocked on pthread_join. Solved through code reorganization, and elimination of pthread_join within mcTime.
• Extensive work merging startup code in master.cc with slave initialization routines in main.cc. This involved converting vxWorks constructs to RTAI equivalents. Also, some eliminated code which tested slave processors. Much work yet to done eliminating all dependencies on master/slave relationships.
• Began looking a Ray Creagers MCB server as a possible alternative to inline MCB monitoring. At any rate, something must be done to replace vxWorks MCB driver, and this is one possible solution.

• Found timing problem ... issue was w/ accessign Actuator sets not assigned to 1st IIOP. Monitor accesses for these were timing out (silently) and producing long delays. Now am running code using only Actuator sets assigned to IIOP 1. A control cycle for 1 IIOP now takes 900uSec, so extrapolating for all 8 we have a control cycle of 7.2mSec total.

02 Jun 2008

02 Jun 2008

- Ported essential components of mcTime routines to RTAI. This entailed creation of bare bones mcTime version which uses NTP synched system clock as time source for repeating 20 mSec timer. This gives semaphores for all necessary time periods via rt_sem_broadcast. dT between 2 tasks blocking on same semaphore is ~13-16uSec. Jitter in waiting task period is ~7-10 uSec. - In an attempt to get the interface between RTAI based PC and VME chassis working, have scrounged an old VME chassis, MVME card (for easy memory debugging), and Bit3 adapter. VME chassis is now assembled and awaiting interconnect with PC/PCI card once Holography work in basement wraps up.

• Ported essential components of mcTime routines to RTAI. This entailed creation of bare bones mcTime version which uses NTP synched system clock as time source for repeating 20 mSec timer. This gives semaphores for all necessary time periods via rt_sem_broadcast. dT between 2 tasks blocking on same semaphore is ~13-16uSec. Jitter in waiting task period is ~7-10 uSec.
• In an attempt to get the interface between RTAI based PC and VME chassis working, have scrounged an old VME chassis, MVME card (for easy memory debugging), and Bit3 adapter. VME chassis is now assembled and awaiting interconnect with PC/PCI card once Holography work in basement wraps up.

09 Jun 2008

• Built vmedrv.ko (PCI=>VME bridge driver), created vmedrv* devices, build vmedrv test applications
• Installed PCI card in Alchiba, found serial cable for comm with MVME167 card
• Reconfigured MVME167 to boot generic VxWorks? image.
• Used vmedrv read/write utilities to verify bidirectional communications across the Bit3 bridge.
• Fixed byte swap issue in configuration of vmedrv devices. In the process, discovered that module cannot be unloaded due to "module in use" error. The vme_open() function increments use count politely, but doesnt decrement it in vme_release(). Fixed by putting call to module_put() in vmedrv_release().
• Installed IIOP board in VME crate. IIOP is 16 bit word accessed at base 0x8000000. Verified that Alchiba can talk to IIOP board across the Bit3 adapter (initiated scans).

16 Jun 2008

• Made extensive changes to main.cc essentially, to replace vxWorks constructs with RTAI equivalents. The scope of work, for now, is to just change the slave code to allow it to run under RTAI control and have it talk to the IIOPs via the VME bridge card. Testing will have to occur through the slave RPC interface so I plan on leaving as much of this intact as necessary.
• Succeeded in getting mcTime converted from C to a C++ class which is used by the AS slave code.
• Finally, was able to generate an active surface slave binary which is currently under debug for various (but not unexpected) run-time exceptions, mostly related to incomplete mapping of VME=>PCI addresses.

TWO WEEKS VACATION starting Friday, 20th !

07-Jul-2008

• Need to reassin MessageMuxHost? to localhost and should reassign ActiveSurfaceHost? to localhost as well. This prevents system message from going to the operator consoles.

FLASH - Jason and JD are having difficulty configuring I/O modules using DOS program. When the PC is hooked up to control modules they can read in and modify I/O configuration, however when they reboot VME the modules lose communication with the system controller. Took a look at CFG file used by PC program. Compared with the original 'golden' CFG file. Noticed that the module scan order was different. The good file had a scan order of Analog/Digital/Analog/Digital ... whereas the 'other' CFG file had order of Analog/Analog/Digital ... etc. Jason restored the original CFG file back to control modules and all was good.

• Modified code to use PCI mmaped address instead of VME addresses
• Application ran, but erratically. This was eventually traced to incorrect RTAI setup. Proper modules to use are RTAI_HAL.KO RTAI_LXRT.KO and RTAI_SEM.KO
• Application seems to "work" but timing numbers are not good. 125mSec needed to communication across the bus per actuator control cycle. Arrg. This was supposed to be improved by new Architecture but we seem to be I/O limited?
• Many PTCS meetings.

14-Jul-2008

09 Jun 2008

• Check VME jumper configuration. Jumpers installed where IIOP was were removed.
• Found and fixed byte swap problem in vmedrv_config.c. Helped software, but not performance.
• Write memory test routines to read 64KBytes of IIOP memory. Timing per access works out to around 2.7 uSec which comes close to spec (1.8uSec).
• Control application takes ~ 40uSec/access on account of RealActuatorSet?::get_position
• Tried improving get_position by eliminating actuator array argument and replacing with pointer instead. Not much help on timing but cleaner than using an array of pointers.

- Built vmedrv.ko (PCI=>VME bridge driver), created vmedrv* devices, build vmedrv test applications - Installed PCI card in Alchiba, found serial cable for comm with MVME167 card - Reconfigured MVME167 to boot generic VxWorks? image. - Used vmedrv read/write utilities to verify bidirectional communications across the Bit3 bridge. - Fixed byte swap issue in configuration of vmedrv devices. In the process, discovered that module cannot be unloaded due to "module in use" error. The vme_open() function increments use count politely, but doesnt decrement it in vme_release(). Fixed by putting call to module_put() in vmedrv_release(). - Installed IIOP board in VME crate. IIOP is 16 bit word accessed at base 0x8000000. Verified that Alchiba can talk to IIOP board across the Bit3 adapter (initiated scans).

16 Jun 2008

- Made extensive changes to main.cc essentially, to replace vxWorks constructs with RTAI equivalents. The scope of work, for now, is to just change the slave code to allow it to run under RTAI control and have it talk to the IIOPs via the VME bridge card. Testing will have to occur through the slave RPC interface so I plan on leaving as much of this intact as necessary. - Succeeded in getting mcTime converted from C to a C++ class which is used by the AS slave code. - Finally, was able to generate an active surface slave binary which is currently under debug for various (but not unexpected) run-time exceptions, mostly related to incomplete mapping of VME=>PCI addresses.

TWO WEEKS VACATION starting Friday, 20th !

16 Jun 2008

- Made extensive changes to main.cc essentially, to replace vxWorks constructs with RTAI equivalents. The scope of work, for now, is to just change the slave code to allow it to run under RTAI control and have it talk to the IIOPs via the VME bridge card. Testing will have to occur through the slave RPC interface so I plan on leaving as much of this intact as necessary. - Succeeded in getting mcTime converted from C to a C++ class which is used by the AS slave code. - Finally, was able to generate an active surface slave binary which is currently under debug for various (but not unexpected) run-time exceptions, mostly related to incomplete mapping of VME=>PCI addresses.

TWO WEEKS VACATION starting Friday, 20th !

%META:TOPICINFO{author="PeteWhiteis" date="1213301995" format="1.0" version="1.1"}% %META:TOPICPARENT{name="SoftwareQueue"}%

-- PeteWhiteis - 12 Jun 2008

02 Jun 2008

Have begun the long process of porting AS code to RTAI. To date: - Ported essential components of mcTime routines to RTAI. This entailed creation of bare bones mcTime version which uses NTP synched system clock as time source for repeating 20 mSec timer. This gives semaphores for all necessary time periods via rt_sem_broadcast. dT between 2 tasks blocking on same semaphore is ~13-16uSec. Jitter in waiting task period is ~7-10 uSec. - In an attempt to get the interface between RTAI based PC and VME chassis working, have scrounged an old VME chassis, MVME card (for easy memory debugging), and Bit3 adapter. VME chassis is now assembled and awaiting interconnect with PC/PCI card once Holography work in basement wraps up.

09 Jun 2008

- Built vmedrv.ko (PCI=>VME bridge driver), created vmedrv* devices, build vmedrv test applications - Installed PCI card in Alchiba, found serial cable for comm with MVME167 card - Reconfigured MVME167 to boot generic VxWorks? image. - Used vmedrv read/write utilities to verify bidirectional communications across the Bit3 bridge. - Fixed byte swap issue in configuration of vmedrv devices. In the process, discovered that module cannot be unloaded due to "module in use" error. The vme_open() function increments use count politely, but doesnt decrement it in vme_release(). Fixed by putting call to module_put() in vmedrv_release(). - Installed IIOP board in VME crate. IIOP is 16 bit word accessed at base 0x8000000. Verified that Alchiba can talk to IIOP board across the Bit3 adapter (initiated scans).