Other bugs found in DGS1 Gnote files

This information comes from looking in Gnote files on DGS1

More than likely these are still mostly open issues.

Follow up: spreadsheet woes and CPLD registers


A couple months ago we tried to update spreadsheets and much evil ensued.  The whole EPICS database went crap and a couple of highly worrisome days of reverting and rebooting occurred.  In the hopes of forestalling another round of that,  here are some observations:

1) There is evidence that using an EPICS PV type of 'T' (toggle) may be deleterious to your health.  Avoid.

2) There is evidence that adding any register to a spreadsheet that has an address greater than 0x7FFF is also deleterious to your health.  Avoid.

3) There is circumstantial evidence that having white space in column 'P' of a spreadsheet (selections for type 'b' or 'm' PVs) may also be problematic.  It is suggested that this also be avoided.

4) If you are defining a 'b' or 'm' field, do NOT use colons in the text name of the setting.  This mucks the Python parser and generates malformed PV database entries.  Example:

     0:text:0;1:other text:1     is ok.
     0:text:0;1:other : text:1   will fail.  

No error given by Python, but if you look carefully in the IOC console there's a error there and you can find malformed definitions in the .template files.




There are also some IOC idiosyncrasies that should be noted:

A) After going off to con5 and doing a new make for the system, simply rebooting the TrigCPU (VME32) isn't sufficient to get the system to re-initialize.  You have to go to the crate and cycle the power, or hit the crate's reset button, to get the other IOCs to understand things have changed.  It appears that only the hard loss of the Ethernet connection caused by a hard boot of the trigCPU IOC suffices to get all the other IOCs to reload the database.

B) For reasons nobody understands, some of the digitizer IOCs are a lot slower than others.  If you power cycle the crate containing VME32 (trigger), VME9 and VME10, for example, the trigger comes up in the time expected but VME9 and VME10 aren't ready for a few minutes after that.  


 

In a separate Gnote there are some entertaining observations about the Python code that may have relevance for the "system configuration file" concept:

11) now what we *WANT* to do is simply parse and run the spreadsheet extractor without mangling the
existing system here on DGS1. So at this point I exit python (knowing I'll have to go back to it) to look 
at the Python source for the spreadsheet extractor to see how it works.

It turns out that the source code (in genSystem.py) has a couple of magic control variables:

a) function genDGSMasterTrigger() assumes five globals:

	global code_location
	global is_do_screens
	global ss_delimiter

	global e_pvnamestr
	global e_pvnamestrrbv.

b) IT IS IMPERATIVE AND CRITICAL that you set code_location = None before you run any python, or the running DGS setup will get clobbered.

c) global is_do_screens seems to select what kind of auto-generated screens occurs:
#
# set to 0 for no screen generation.
# set to 1 for css screen generation.
# set to 2 for edm screen generation.

12) In attempting to follow the instructions, everything talks about .csv files, but the conversion crashed.
Reading the source code in spreadsheet.py, I find that the expected column delimiter is TAB, not COMMA.