Leginon

Please see suggestion under "new CM support in pyScope" topic for editing your mag table. Perhaps you already did this.

After doing this, I had to hit the "get magnifications" button in the Instrument node before they took effect.

I also get error message upon starting the Manual application:

from CM class

model <ctypes.c_char_Array_33 object at 0x03EE0210>

version <ctypes.c_char_Array_33 object at 0x03EE0260>

undocumented err message

from getMagnificationsInitialized

from setMagnifications

but then things work ok.

sorry, Ignore above. I do not get an error message (Leginon had been poisoned by a previous error with the calibration application) Starting the Manual Application comes up clean in my current implementation:

from CM class

model <ctypes.c_char_Array_33 object at 0x03A5E990>

version <ctypes.c_char_Array_33 object at 0x03A5E940>

CM Model: 'CM200 ' Version: '00142 '

from getMagnificationsInitialized

from setMagnifications

Yes, I definitely edited the mag table. I had to because I created a whole new mag list called cm120mags.py and that is what CMCal reads. The Instrument node never completes its initialization, so I can't hit the get magnifications button. Other suggestions?

I am concerned about the version of CM software. I'm not exactly sure how to find this out, but I suspect that we have version 14.2 and that you have version 11.2 based on the output. I know from my earlier history with emscope (predecessor to pyScope) that some of the ram addresses changed during the upgrading process. I have some old files called ramadres.11, ramadres.120, ramadres.121 which show changes in the addresses used for EM functions! Hopefully I'm being paranoid, but it would be nice to know whether the CM version number is a variable that we need to be concerned about. What version is your cm300?

OK, I found solid evidence for this. This is a statement from rcm.c from the old emscope stuff. These refer to ram addresses that have changed in versions 11-12.3 and correlate with the ramadres.* files mentioned above. I have no idea what happened to the ram addresses after this. Does pyScope know about these changes?

static rcmVarAddresses rcmVar_table[] = {

{ 11, 0xFF, 0x0C0023EC, 0x0B80934C, 0x0C0024B4, 0x0C002050, 0x00000000, 0x0B80A67A },

{ 12, 0, 0x0C002239, 0x0B809492, 0x0C002301, 0x0C001FD5, 0x0B80A215, 0x0C0001D5 },

{ 12, 1, 0x0C002239, 0x0B809492, 0x0C002301, 0x0C001FD5, 0x0B80A215, 0x0C0001D5 },

{ 12, 2, 0x0C002239, 0x0B809492, 0x0C002301, 0x0C001FD5, 0x0B80A21A, 0x0C0001D5 },

{ 12, 3, 0x0C002239, 0x0B809492, 0x0C002301, 0x0C001FD5, 0x0B80A21A, 0x0C0001D5 },

{ 0, 0, 0, 0 }

Min Su probably knows best about how pyScope relates to emscope. As far as I can tell, emscope was communicating with the CM directly and this is why it needed all these address definitions. pyScope uses cmremote32.dll to communicate with the CM, so I think these address things are taken care of through cmremote32. I assume that cmremote32 contains all the info it needs for different versions of the CM. In the cmlib.py module, it is just calling high level functions like GetCMVar from the cmremote32 library. There is no direct access to specific memory locations. That is just my guess.

I don't know what the "EXIT 8" message means. It does not look like it is coming from any python code. Can you put in some debugging messages to see where exactly it is failing. Based on the log messages, it is at least getting to this line of EM.py:

self.logger.warning('No magnifications saved for %s' % name)

wxaddmethod(name)

OK, the mags thing was a red herring. The error I was seeing was actually a warning, and that warning is actually covered in the installation documentation. All I had to do was press the calculator button and it went away (I can even change mags from the Instrument node).

The real problem is with CAMC4. I believe that EXIT 8 message is coming from there. I am thoroughly confused about what is going on. When I start up an application, the CAMC4 camera icon comes up on my taskbar, then it turns red. I can right click on it and report the "Last alerts". These are:

000: ptrCamera->CoCreateInstance failed

001: CreateInstance (AVL_FC415) failed

002: CCamera UnInitialize failed

That AVL_FC415 bit confuses me because I have the instrument set in the database to Tietz PXL not Tietz FC415. Another little test I performed is:

from pyScope import tietz
myccd=tietz.TietzPXL()
myccd.getBinning()

This returns {'y':1, 'x':1}. Also in this case, the CAMC4 icon comes up with no errors. If I try myccd=tietz.TietzFC415(), it doesn't work. To me, it looks like Leginon is using the FC415 driver instead of the TietzPXL one. Any suggestions about how to figure this one out?

BTW. Acquiring a simulated image works just fine. I also ran the script Christian posted in http://emg.nysbc.org/bb/viewtopic.php?t=8 , and it also showed that Tietz PXL is the only driver that works.

Thanks,

Scott

This reminds me of what happened on your CM300 when we were setting it up. First we created that new class for your FC415. Then I think there was a conflict between that new class and one of the others, like it was actually trying to start both. The immediate solution is to go into tietz.py and comment out all the classes that you are not using, probably all except TietzPXL. At one point I think we commented out everything except FC415 for your CM300.

pyScope uses the module registry.py to try all CCD and TEM classes in all of its modules. If it can make an instance of the class without an error, then it assumes that it can use that instrument. Since tietz.py has several classes to try, most of them will probably fail, but it is possible that CAMC4 is being started in one of the failed attempts. Then when the legitimate one is created (PXL in the case of your CM120) then it may have a conflict if CAMC4 was already started. This is just my guess as to what could be happening.

A similar problem happened with the TEM classes on your CM300. pyScope was able to create an instance of Tecnai, so it actually thought you had a Tecnai. This is probably because the Tecnai scripting support was installed as part of the tietz camera install. I think we had to comment out that class to prevent it from trying beause it took forever to initialize the Tecnai instance.

I commented out everything but TietzPXL and it worked. Hurray! Now I just need to keep from committing that change to svn. Maybe in all my spare time I can figure out how to get pyScope to load only the correct driver.

One thought I have is that we should override the automatic detection of what instruments you have using something in leginon.cfg, or a pyScope specific config file. We already have an instrument configuration that you do through dbem, so I am not sure why this is not used by pyScope.

I was thinking the same thing. My thought is that it should go in leginon.cfg. I realize that that makes pyScope dependent on leginon, but do we honestly want to require yet another config file? Of course having it in the config file creates a redundancy with dbem, and that is also sort of confusing. OK, how about this idea, you have a script that you run in pyScope that automatically detects your Scope/Camera configuration and writes a pyScope config file. Something sort of like the script in http://emg.nysbc.org/bb/viewtopic.php?t=8 . Thoughts?

I agree that we don't want the number of config files to get out of hand. I was even hoping to phase out leginon.cfg and just have everything in the database to begin with. All you need is sinedon.cfg to get to the database and then you have everything else you need.

The InstrumentData table seems to be the best thing to use. We are already sort of using it but we just have to manage it properly. We need an instrument detection script like the one you referenced from Christian. This can be part of pyScope, so that someone could run it stand alone, but Leginon can use this script in a more friendly way so people can then take that information and put in into InstrumentData table.

I see no reason why someone should have to use dbem to manually type in their instrument info when it can be done from Leginon. People tend to enter the wrong things anyway, like entering an arbitrary string for "name" instead of the required string like "Tietz SCX" that must come directly from the class in pyScope. In Leginon, this would have to be a dialog that alows you to accept or reject the instruments that are detected (like rejecting Tecnai if you know you have a CM).