| ID |
Date |
Author |
Type |
Category |
Subject |
|
327
|
Thu Feb 21 09:56:26 2008 |
steve | Update | PSL | the laser is back |
The laser and the psl recovered.
The water chiller temp is 19.98C and head temp 18.4C
Power 3.2W
PMC_T 3.1
c1iovme was restarted and the mc is locking now |
| Attachment 1: laserisback.jpg
|
|
|
326
|
Wed Feb 20 16:24:37 2008 |
steve | Update | PSL | the laser is recovering slowly |
Head temp is still 20.5C and decreasing slowly.
Power output 2.9W
NPRO power 22 mW is increasing as head is cooling down |
| Attachment 1: laserecoverring.jpg
|
|
|
325
|
Wed Feb 20 11:34:17 2008 |
steve | Update | PSL | laser head temp is up |
MOPA head temp is running at 20.3C now
Nomally it is at 18.5C |
| Attachment 1: htempup.jpg
|
|
|
324
|
Tue Feb 19 18:28:41 2008 |
John | Update | PEM | More seismic in Baja California |
Steve spotted more activity from the same quake.
Reset watchdog on ETMY. |
|
323
|
Tue Feb 19 15:21:47 2008 |
Andrey | Update | SUS | Earthquake tripped watchdogs in ETMY, ITMY |
According to the web-page http://earthquake.usgs.gov/eqcenter/recenteqsus/Quakes/ci14351140.php ,
there was a 5.0 earthquake in northern Baja California in Mexico at 02.41PM earlier today.
This earthquake made an effect on our watchdogs for ETMY and ITMY (their currents exceeded maximal values).
Watchdogs for ITMY are now restored back,
and it is taking more time for a "side degree" for ETMY to calm down,
it is still (40 minutes after the kick) swinging a lot with amplitude ~ 200mV. |
|
322
|
Tue Feb 19 10:14:13 2008 |
steve | Update | VAC | rga logging needs help |
| The rga head and controller are running fine, but the data logging is not. |
|
321
|
Mon Feb 18 12:04:39 2008 |
Alberto | Update | Electronics | RF Monitor (StocMon) |
I put the amplifiers next to the monitor on the PSL table, layed the power and the RF SMA cables out to the rack. I'm powering the box and the amplifiers with the power supply, waiting for someone to show me tomorrow how to connect it to the Sorensen (Steve, Ben?).
I'm ready to hook up the channels into EPICS. |
| Attachment 1: DSC_0443.JPG
|
|
|
320
|
Fri Feb 15 22:16:04 2008 |
Andrey | Update | Computers | MATLAB is not working: "Licence checkout failed" |
For some unknown to me reason,
Matlab stopped working about 20 minutes ago on all computers in the control room (both UNIX control machines and Windows).
It says: "License checkout failed. License Manager Error -15. MATLAB is unable to connect to the license server."
I do not know how to revive Matlab.
At the same time, I consider that I made a significant progress in building my theoretical/computational model in the last 2 days. I was able to compute the time-evolution of accelerometer signals through stacks and pendulums using Matlab command "lsim", and I am now able to calculate RMS of spectrum of differential arm length in different frequency intervals. It seemed to me that everything is ready in my program to make the three-dimensional theoretical/computational plot (RMS as a function of Q-factors of ETMX and ITMX), but unfortunately Matlab stopped working. It seemed to me that all that was remaining was to run a loop with all possible values of Q-factors. Let's hope that Matlab will be working after the weekend.
Andrey. |
|
319
|
Fri Feb 15 10:28:44 2008 |
rana | Update | Computers | Noise budget code changes |
| Quote: | In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code. |
The IFOin variable (which I admit is not documented) should refer to a file called
C1IFOparams.m in the ReferenceData directory. This does not yet exist but can be
created by merging L1IFOparams.m with our knowledge of the 40m IFO. |
|
318
|
Thu Feb 14 17:21:53 2008 |
Max Jones | Update | Computers | Noise budget code changes |
In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code. |
|
317
|
Thu Feb 14 15:05:18 2008 |
rob | DAQ | DMF | seisBLRMS 1.1 |
>
> Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes. We'll see if that's enough.
5 minutes didn't work. |
|
316
|
Thu Feb 14 15:04:53 2008 |
rob | DAQ | DMF | DMF delay |
Sometime ago I edited seisBLRMS to keep of track of how long it was taking to write RMS data (that is, the delay between the accelerometer data and the write of the EPICS rms data). Here's a plot of that info, showing how the delay increases over time. I think this indicates a logical flaw in the timing of the seisBLRMS program, which sort of relies on everything running well consistently; this should not be difficult to fix. I'll maybe try increasing the delay to ~10 minutes, and making it relatively inflexible. |
| Attachment 1: DMFdelay.png
|
|
|
315
|
Wed Feb 13 20:37:11 2008 |
John | Update | LSC | Fibre locking - Fiber |
| Sam and I observed fringes in the light reflected from the Y arm. These fringes are due to the sidebands and not the carrier. To improve matters we plan to reduce the RF AM and increase our modulation index. |
|
314
|
Wed Feb 13 11:41:00 2008 |
Alberto | Update | Electronics | Some characterization of the RF Monitor Box (StocMon) |
I'm attaching a table with some measurements and the power spectrum from the pd to help evaluate the numbers.
The box output ranges from 0.5V to 2.1V. The coefficient between power and voltage is negative so higher voltage means lower power.
The red numbers are the outputs from each channel at their resonant frequencies. As one can see these are not very well centered on the dynamic range of the power detectors.
The cross coupling seems to be not a problem.
Even if the 166 filter, which handles the smallest of the frequencies and is also the most lossy (for construction reason), mounts a preamplifier, the output is still rather small. this explain also the high bias due to the noise amplification at the maximum power (13dB). A better insertion loss either remaking the filter or re-tuning that one would simplify many problems, i.e. there is not much room in the metal pomona box to fit the amplifier. I might want to consider, after everything else is ready and if I have time before leaving next week, to work on a new 166 filter. |
| Attachment 1: CircuitCharacterization.png
|
|
| Attachment 2: alberto.spectrum3.png
|
|
|
313
|
Tue Feb 12 16:39:52 2008 |
rob | Update | Locking | report |
Did some locking work on DRFPMI on sunday and (with John) on monday nights. So far progress has not been terribly encouraging.
Problems include the DD_handoffs not working and the CARM->MCL handoff not working so well. To get around the DD signals trouble, I decided for now to just ignore 67% of the DD signals. We should be able to run with PRC & MICH on single demod signals, and SRC on a DD signal. This seems to work well in a DRMI state, and it also works well in a DRMI+2ARMs state.
The CARM->MCL handoff actually works, but it doesn't take kindly to the AO path and it doesn't work very stably. I guess this was always the most fragile part of the whole locking procedure, and it's fragility is really coming to light now. Investigation continues. |
|
312
|
Tue Feb 12 16:34:07 2008 |
rob | DAQ | DMF | seisBLRMS 1.1 |
The compiled version of seisBLRMS had been running ~2 weeks without crashing as of last night, when I killed it
so it wouldn't interfere with alignment scripts. I added an EPICS channel C1:DMF-ENABLE, and updated the DMF
executables to check this channel while running. So far it seems to work. When you're running alignment acripts,
simply click the DISABLE button on the C1DMF_MASTER.adl screen, and then re-ENABLE when the scripts finish.
It's not clear why this is necessary though. Theories include the constant disk access is keeping the
framebuilder busy, reducing its ability to deal with ezcademod commands and DMF programs just flooding the
network with so much traffic that ezcademod-related packets run late and get ignored.
Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes. We'll see if that's enough. |
|
311
|
Tue Feb 12 16:18:29 2008 |
rob | Configuration | Computer Scripts / Programs | autoburt cron moved to op340m |
I moved the autoburt cron job from op440m to op340m. For some reason, burtrb requires gcc to run (I gather it uses the C-preprocessor to parse input files), so I had to install that on op340m to get it to work properly.
There are no more cron jobs running on op440m now. |
|
310
|
Tue Feb 12 13:53:27 2008 |
rob | Omnistructure | VAC | Return of the RGA |
The new RGA head was installed a few days ago. I just ran the RGAlogger script to see if it works, which it does. I also edited the crontab file on op340m to run the RGAlogger script every night at 1:25 AM. It should run tonight. |
| Attachment 1: RGA-080212.png
|
|
|
309
|
Mon Feb 11 22:44:29 2008 |
rob | Configuration | DAQ | Change in channel trending on C1SUS2 |
I removed the MC2 optical lever related channels from trends, and the SRM POUT and YOUT (as these are redundant if we're also trending PERROR and YERROR). I did this because the c1susvme2 processor was having bursts of un-syncy lateness every ~15 seconds or so, and I suspected this might interfere with locking activities. This behaviour appears to have been happening for a month or so, and has been getting steadily worse. Rebooting did not fix the issue, but it appears that removing some trends has actually helped. Attached is a 50 day trend of the c1susvme2 sync-fe monitor. |
| Attachment 1: srm_sync.png
|
|
|
308
|
Mon Feb 11 14:24:19 2008 |
steve | Update | PEM | more earthquakes |
ITMX and ITMY sus damping restored after Baja earthquake 5.1 mag at 10:29 this morning.
The ground preparation for The ITS building is almost finished.
Activity is winding down, however the Baja California_ Mexico earthquake zone
"Guadala Victoria" started acting up on Friday.
http://earthquake.usgs.gov/eqcenter/recenteqsus/Maps/special/California_Nevada_eqs.php |
| Attachment 1: eqfeb11.jpg
|
|
|
307
|
Sun Feb 10 21:43:16 2008 |
rob | Configuration | IOO | MC alignment tweaked |
I adjusted the alignment of the free hanging mode cleaner to best transmit the PSL beam. |
|
306
|
Sun Feb 10 20:47:01 2008 |
Alan | Summary | SUS | All watchdogs tripped |
A moderate earthquake occurred at 11:12:06 PM (PST) on Friday, February 8, 2008.
The magnitude 5.1 event occurred 21 km (13 miles) NW of Guadalupe Victoria, Baja California, Mexico.
http://quake.wr.usgs.gov/recenteqs/Quakes/ci14346868.html |
|
305
|
Sat Feb 9 13:32:07 2008 |
John | Summary | SUS | All watchdogs tripped |
When I arrived this afternoon the watchdogs had tripped on all optics. I reset them and enabled the coil currents.
I had to adjust the alignment of the mode cleaner to get it to lock. |
|
304
|
Sat Feb 9 13:05:48 2008 |
John | Summary | IOO | PMC camera/ HEPA |
I replaced the Gig-E camera on the PMC trans beam. The PZT was close to railing and I wanted to adjust it. I just did a quick job, there is a little scattered light on the image. If Joe is finished with the Gig-E I'll take another look at it.
The HEPA in the PSL table was turned off for some reason. I turned it back on. |
|
303
|
Fri Feb 8 17:55:53 2008 |
josh | Configuration | PEM | PEM-AS_MIC now in PSL enclosure |
I have moved the microphone to the PSL enclosure, hanging near the south (Y) side from a support rod for the overhanging storage area so that it's reasonably close to the PMC. I've fastened it in many places using cable ties to make sure that it won't fall.
Alberto helped me solder together a female BNC-female 3.5 mm stereo adapter so that I can use the DAQ to output through BNC to PC speakers. My plan is do sweep sine output through PC speakers to find the transfer function of sound from outside the enclosure to inside the enclosure and by moving the microphone more centrally over the PSL table, check if there are any strong resonances. Hopefully I can use this technique at other places around the interferometer or measure the effect of installing acoustic foam. |
|
302
|
Fri Feb 8 17:09:52 2008 |
Max Jones | Update | Computers | Changes to NoiseBudget |
Today I altered the following files
caltech/NB/matlab/utilities/get_dtt_dataset
In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.
caltech/NB/matlab/noise/getUGF.m
I commented out lines of code specifically pertaining to non-existent DARM_DAQ channel. Marked in
code around approximately line 60.
Please address all comments or concerns to me (williamj(at symbl)caltech.edu). Thank you. |
|
301
|
Wed Feb 6 19:39:11 2008 |
rana | Configuration | Cameras | Regions of Interest and max frame rate |
| We really need to look into making the 40m CDS network have an all GigE backbone so that we can have cooler cameras as well as collect multiple datastreams... |
|
300
|
Wed Feb 6 16:50:47 2008 |
josephb | Configuration | Cameras | Regions of Interest and max frame rate |
The Snap code has once again been modified such that setting the -l option to 0 will take images as fast as possible. Also, the -H and -W options set the height and width, while in principle the -Y and -X options set the position in pixels of the top edge and left edge of the image. It also seems possible to set these values such that the saved image wraps around. I'll be adding some command checking so that the user can't do this in the near future.
Doing some timed runs, using a -H 350 and -W 350 (as opposed to the full 752x480), 100 images can be saved in roughly 8 seconds, and 1000 images took about 73 seconds. This corresponds to a frame rate of about 12-13 frames per second (or a 12-13 Hz display). The size of this area was sufficient to cover the current PMC transmission beam.
The command line I used was
time ./Snap -l 0 -m 1000 -f 'test' -W 350 -H 350 -Y 50 -X 350 -E 2000
Interestingly enough, there would be bursts of failed frame saves if I executed commands in another terminal (such as using ls on the directory where the files were being stored).
As always, this code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. |
|
299
|
Wed Feb 6 09:17:31 2008 |
steve | Update | PEM | IST building construction continoues |
| The bulldosers at work |
| Attachment 1: seismic8d.jpg
|
|
| Attachment 2: seisioo.jpg
|
|
|
298
|
Tue Feb 5 17:39:05 2008 |
jweiner | Configuration | PEM | PEM-AS_MIC taken down from AS table, will put in PSL enclosure soon |
| I took down the microphone that Andrey hung above the AS table his first week in lab. I want to hang the microphone above the PMC to check the effect of acoustic noise on the PMC. The cables were a little more tangled than I thought so I've only taken the microphone down and haven't hung it back up yet, but on Thursday I'll have enough time to carefully put it up inside the PSL and see what I can find out about acoustic noise inside the PSL. I think the microphone should be sensitive enough for the frequencies we're interested in, and I'll hopefully find out if it's sufficient once I put it up in the PSL. The microphone cable and microphone are on top of the PSL for now. |
|
297
|
Tue Feb 5 15:32:29 2008 |
josephb | Configuration | Cameras | PMC and the GigE Camera |
The PMC transmission video camera has been removed and replaced with the GigE GC750 camera for the moment.
A ND4.0 filter has been added in the path to that camera to reduce saturation for the moment.
The old camera has been placed on the elevated section inside the enclosure, and the cable for it is still on the table proper.
The Gige camera is currently running the Snap code on Linux3 with the following command line:
./Snap -E 2000 -l 60 -m 1440 -f './pmc_trans/pmc_trans'
So its going to be taking tiff images every minute for the next 24 hours into the cvs/cds/caltech/target/Prosilica/40mCode/pmc_trans/ directory.
Attached is an example image with exposure set to 2000, loaded into matlab and plotted with the surf command. 2500 microseconds looked like it was still saturating, but this seems to be a good level (with a max of 58560 out of 65535). |
| Attachment 1: pmc_trans.jpg
|
|
|
296
|
Mon Feb 4 22:01:57 2008 |
John | Summary | LSC | Fibres auxiliary locking - Fibers |
| I managed to couple ~75% of the light transmitted from the y arm, through the fibre, back to the SP table. I hoped that this would be a good way to match the beam from the fibre into the arm. Still no flashes. It looks like the cameras just aren't sensitive enough. |
|
295
|
Sun Feb 3 05:02:41 2008 |
rana | Update | PEM | Seism 4 day |
|
| Attachment 1: Screenshot.png
|
|
|
294
|
Sat Feb 2 14:11:27 2008 |
John | Summary | Computers | OPTLEVmaster screen |
| I changed the layout of the optlev master screen. The old version is /cvs/cds/caltech/medm/old/C1ASC_OPTLEVmaster080202.adl |
|
293
|
Fri Feb 1 17:17:05 2008 |
John | Summary | PSL | Mach-Zender tweaking |
I helped Rob adjust the alignment of the Mach-Zender to try and reduce any AM on the laser light. Our goal was to reduce the large offsets in the DD signals.
We reduced the MZ refl from 0.54 to 0.39. We were able to re-lock the mode cleaner without problems. We then centred the WFS heads.
No change in the DD signal offsets. |
|
292
|
Fri Feb 1 15:04:54 2008 |
josephb | Configuration | Cameras | Snap with looping functionality available |
New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.
Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.
"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).
It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.
Use --help for a full list of options.
Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera 131.215.113.104 (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment. |
|
291
|
Fri Feb 1 12:37:39 2008 |
rob | Update | DMF | seisBLRMS trends |
Here are DV trends of the output of seisBLRMS over the last ~36 hours (which is how long it's been running), and another of the last 2 hours (which show the construction crew taking what appears to be a lunch break). |
| Attachment 1: seis36hours.png
|
|
| Attachment 2: seis2hours.png
|
|
|
290
|
Fri Feb 1 10:43:05 2008 |
John | Update | Environment | Construction work |
| The boys next door have some bigger noisier toys. |
| Attachment 1: DSC_0433.JPG
|
|
|
289
|
Thu Jan 31 16:53:41 2008 |
josephb | Configuration | Cameras | Improving camera user interface |
There's a new and improved version of Snap program at the moment people are free to play with.
Located in /cvs/cds/caltech/target/Prosilica/40mCode/
The program Snap now has a -h or --help option which describes some basic command line arguments. The height (in pixels), width (in pixels), exposure time (in micro seconds), file name to be saved to (in .tiff format), and packet size can all be set. The format type (i.e. pixel format such as Mono8 or Mono16) doesn't work at the moment.
At the moment, it only runs on mafalda.
Currently in the process of adding a loop option which will take images every X seconds, saving them to a given file name and then appending the time of capture to the file name.
After that need to add the ability to identify and choose the camera you want (as opposed to the first one it finds).
Lastly, I've been finding on occassion that the frame fails to save. However if you try again a few seconds later with the exact same parameters, it generally does save the second time. Not sure whats causing this, whether on the camera or network side of things.
I've attached two images, the first at default exposure time (15,000 microseconds) and the second at 1/5th that time (3,000 microseconds).
The command line used was "./Snap -E 3000 -F 'Camera_exp_3000.tiff' " |
| Attachment 1: Camera_exp_15000.tiff
|
| Attachment 2: Camera_exp_3000.tiff
|
|
288
|
Thu Jan 31 12:39:14 2008 |
John | Configuration | General | Y arm test mass cameras |
| I've adjusted the test mass cameras on the y arm to make the beam injected through ETMY more visible. |
|
287
|
Wed Jan 30 20:39:31 2008 |
rob | Update | DMF | seisBLRMS |
In order to reduce the probability of seisBLRMS crashing due to unavailability of data, I edited seisBLRMS.m so that it displays data from 6 minutes in the past, rather than 3. After compiling, this version ran for ~8 hours without crashing. I've killed the process now because it seems to interfere with alignment scripts that use ezcademod, causing "DATA RECEIVING ERROR 4608" messages. These don't cause ezcademod to crash, but so many of them are spit out that the scripts don't work very well. I guess running DMF constantly is just making the framebuilder work too hard with disk access. In the near term, we can maybe work around this by having DMF programs check the AutoDithering bit of the IFO state vector, and just not try to get data when we're running these sorts of scripts. |
|
286
|
Wed Jan 30 13:09:55 2008 |
Andrey | Update | SUS | New results for XARM (pdf) |
See attachments: pdf-presentation with plots in "true" axes Q_ETMX and Q_ITMX, and seismic backgound measurement.
Results that were shown a week ago turned out to be not sad at all! |
| Attachment 1: New_Results_XARM.pdf
|
|
| Attachment 2: Accel-Seismic_10AM.pdf
|
|
|
285
|
Wed Jan 30 11:49:30 2008 |
Alberto | Summary | Electronics | RF monitor's filters final schematics and transfer functions |
| These are the final schematics for the 6th order Chebyshev filters of the RF monitor board. I'm also attaching the TF as I measured. The tuning is probably not optimal, less insertion noise could be achieved. |
| Attachment 1: 33Melog30Jan08.png
|
|
| Attachment 2: 133Melog30Jan08.png
|
|
| Attachment 3: 166Melog30Jan08.png
|
|
| Attachment 4: 199Melog30Jan08.png
|
|
| Attachment 5: 33elog30Jan08.png
|
|
| Attachment 6: 133elog30Jan08.png
|
|
| Attachment 7: 166elog30Jan08.png
|
|
| Attachment 8: 199elog30Jan08.png
|
|
|
284
|
Tue Jan 29 14:56:39 2008 |
rob | Update | DMF | seisBLRMS 1.0 |
The seisBLRMS 1.0 program crashed at ~7:20 pm last night, so we didn't get data from overnight. It crashed when framecaching failed. I added
a try-catch-end statement around the call to dttfft2 to let the program survive this, then compiled it and started it on mafalda. After ~45 minutes, the compiled version encountered the same error, and while it didn't crash per se, after 20 minutes it still wasn't able to read data. We may have to dig deeper into the guts of mDV to make this stuff run more robustly. |
|
283
|
Mon Jan 28 19:35:55 2008 |
rana | Summary | PEM | Accelerometer and Seismometer Coherences |
The attached PDF shows that there is some strange behavior at low frequencies.
From the plot it looks like to me that the Wilcoxon accelerometers (which are supposed to have good response down to 0.05 Hz) are not displaying real seismic motion below 0.3 Hz. Because the coherence length for seismic waves at those frequencies should be 100's of meters we should expect that the accelerometers would have good coherence (>0.8) down there. Instead, my guess is that its all air currents, temperature, or electronics noise. These sensors are not reliable indicators for the microseism.
The Ranger seismometer, however, seems to work fine down to just below the microseism. The Ranger is mounted down around the X end and pointing in the z-direction. The coherence I plotted between it and EX_Z is larger than any other acc/seis pair (as expected).
JM and I discussed what could be done; if we get a SURF student who's into building stuff we can ask them to make a styrofoam hut for the Wilcoxons to see if that helps anything. JM also asked what the point of all this is.
IF we want to do good Adaptive Noise subtraction then we need sensors which can sense the motion which disturbs the mirrors and they need to sense it with a good SNR to get a good subtraction ratio. If the styrofoam thing doesn't work, we should probably look into getting a Guralp 3-axis seismometer for the corner area and just move the accelerometers down to the ends. The sites have Guralp CMG-40T units (~ 8k$). I think we should check out the CMG-3T or the CMG-3ESP.
Does anyone know someone in the Geo depts that we can borrow one from? |
| Attachment 1: Acc.pdf
|
|
|
282
|
Mon Jan 28 18:56:47 2008 |
rana | Update | DMF | seisBLRMS 1.0 |
I made all of the updates I aludded to before:
- Expanded the dmf.db file on c1aux to include all accelerometers and the seismometer.
- Added the channels to the C0EDCU.ini file and restarted the framebuilder daqd.
- Modified seisBLRMS.m to use .conf files for the channels. The .conf files are now residing in the compiled matlab directory that Rob made.
I still have yet to compile and test the new version. Its running on linux3 right now, but feel free to kill it and compile it to run on Mafalda.
It should be making trends overnight and so we can finally see what the undergrads are really up to. |
|
281
|
Mon Jan 28 17:16:54 2008 |
Andrey | Configuration | Computers | Matlab libraries DO NOT WORK properly sometimes |
Working in Matlab, I encountered at two different times today the license distribution problem:
??? License checkout failed.
License Manager Error -4
Maximum number of users for Curve_Fitting_Toolbox reached.
Try again later.
To see a list of current users use the lmstat utility or contact your License Administrator.
Troubleshoot this issue by visiting:
http://www.mathworks.com/support/lme4a |
|
280
|
Mon Jan 28 15:11:38 2008 |
rob | HowTo | DMF | running compiled matlab DMF tools |
I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:
1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).
NB: Steps (4) and (6) must be carried out on mafalda. |
|
279
|
Mon Jan 28 12:42:48 2008 |
Dmass | Bureaucracy | TMI | Coffee |
| There is tea in the coffee carafe @ the 40m. It is sitting as though it were fresh coffee. There is also nothing on the post it. |
|
278
|
Sun Jan 27 21:44:48 2008 |
rana | Update | CDS | Seismic BLRMS on Matlab |
I wrote a matlab script to produce band limited RMS trends from our accelerometers. It mimics the code written
by Ed Daw which makes the seismic FOMs at the sites.
Here's how it works:
- Use mDV to get data by reading directly from frames.
- Use the Matlab pwelch function to produce a power spectrum of the channels.
- Use the Matlab find function and rms.m to get the RMS in user-defined frequency bands.
- Makes a tdswrite command string which writes all the values to EPICS channels.
- The EPICS channels are just a list of simple names in a database file.
- The channel names are (will be) added to the C0EDCU.ini file so that its all trended.
The code is in the mDV/extra/C1 directory; its ~20 lines of code (excluding comments and spaces).
Next up is to add more DMF trend channels to the database and upgrade the code to use a .conf file
instead of hardcoded channel names. We should also evaluate if the bands I used are appropriate for the 40m;
I just used Ed's choices (0.1-0.3, 0.3-1, 1-3, 3-10, and 10-30 Hz).
In the medium term, we should make this compiled (like what RW did with the linetracker), and explore if we
want it to write values faster than 1/minute. |
| Attachment 1: seisBLRMS.m
|
% Seismic BLRMS Monitor
%
%
%
% RA 08-01-26
% 0 for no messages, 1 for debugging
debug_flag = 1;
% ------------ Build channel list
... 82 more lines ...
|