| Name | pmgr JSON |
| Version |
2.1.3
JSON |
| download |
| home_page | None |
| Summary | Parameter Manager for LCLS Device Configurations |
| upload_time | 2024-05-02 21:32:54 |
| maintainer | None |
| docs_url | None |
| author | SLAC National Accelerator Laboratory |
| requires_python | >=3.9 |
| license | Copyright (c) 2023, The Board of Trustees of the Leland Stanford Junior University, through SLAC National Accelerator Laboratory (subject to receipt of any required approvals from the U.S. Dept. of Energy). All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: (1) Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. (2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. (3) Neither the name of the Leland Stanford Junior University, SLAC National Accelerator Laboratory, U.S. Dept. of Energy nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER, THE UNITED STATES GOVERNMENT, OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. You are under no obligation whatsoever to provide any bug fixes, patches, or upgrades to the features, functionality or performance of the source code ("Enhancements") to anyone; however, if you choose to make your Enhancements available either publicly, or directly to SLAC National Accelerator Laboratory, without imposing a separate written license agreement for such Enhancements, then you hereby grant the following license: a non-exclusive, royalty-free perpetual license to install, use, modify, prepare derivative works, incorporate into other computer software, distribute, and sublicense such Enhancements or derivative works thereof, in binary and source code form. |
| keywords |
|
| VCS |
|
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
# Parameter Manager
Package used in LCLS to manage motor parameters. Currently in use to manage
configurations for IMS motors in the LCLS1 hard x-ray hutches.
## Implementation Notes
```
We assume that there are a number of "classes" of things to be configured.
If one such class is XXX, then we will have three mysql tables for it:
-- XXX_cfg is a table of configurations.
-- XXX_name_map is a table of field aliases.
-- XXX is a table of configured objects.
The first set of fields in each of these tables is fixed, so we can operate
generically on any configuration class.
The configurations in XXX_cfg start with the following fields:
`id` int(11) NOT NULL AUTO_INCREMENT, -- The primary key
`name` varchar(15) NOT NULL UNIQUE, -- The name of the configuration
`config` int(11), -- The parent configuration
`security` varchar(30),
`owner` varchar(10),
`dt_updated` datetime NOT NULL,
`mutex` varchar(16),
It is assumed that there will always be a "DEFAULT" configuration with id 0. This will
be the only configuration with a null link. This should be a "no-op" configuration!
After these, there will be many fields of various types all named "FLD_*" or
"PV_*". The idea is that each configuration will be applied to a base PV name.
The "_*" is what should be appended to the base PV name. Any "__" will be
changed to a single "_" in the actual name, and any single "_" will be changed
to ":" with the exception of the last. For "FLD", the last "_" will become "."
while for "PV" it will become "_".
For example if the base is IOC:TST:01:CTRL,
FLD_XY -> IOC:TST:01:CTRL.XY
PV_XY -> IOC:TST:01:CTRL:XY
FLD_XY_Z -> IOC:TST:01:CTRL:XY.Z
PV_XY_Z -> IOC:TST:01:CTRL:XY:Z
FLD_XY__Z -> IOC:TST:01:CTRL.XY_Z
PV_XY__Z -> IOC:TST:01:CTRL:XY_Z
This is implemented by the function fixName.
The XXX_name_map table has fields:
`db_field_name` varchar(30) NOT NULL, -- The FLD_* or PV_* field name.
`alias` varchar(16) NOT NULL, -- A human-readable alias for this field.
`tooltip` varchar(60), -- A tooltip for the field.
`enum` varchar(120), -- If an enum type, possible names, separated by '|'.
`col_order` int(11) UNIQUE, -- Where this field should be displayed (< = more left).
`set_order` int(11), -- How to set this field. Low ten-bits are order (< = set earlier)
-- 0x0200 flags this as a mutex group.
-- 0x0400 flags a must-write PV.
-- 0x0800 flags a write zero, then write value PV.
-- 0x1000 flags the "autoconfiguration" PV (deprecated!!!).
-- 0x2000 flags a read-only value.
`mutex_mask` int(10) unsigned -- A bitmask of values that are interrelated. Each bit is a different set,
-- so a field can be in several sets.
The XXX table has fields:
`id` int(11) NOT NULL AUTO_INCREMENT, -- The identifier of this object.
`config` int(11) NOT NULL, -- The configuration id of this object.
`owner` varchar(10), -- Which hutch owns this object.
`name` varchar(30) NOT NULL, -- The name of this object.
`category` varchar(10),
`rec_base` varchar(40) NOT NULL, -- pv/field base prefix --
`mutex` varchar(16),
`dt_created` datetime NOT NULL, -- When the record was created.
`dt_updated` datetime NOT NULL, -- When the record was modified.
`comment` varchar(80),
After these fields, the XXX table may also have "FLD_*" and "PV_*" fields
as described above. (These should be object specific things that are always
unique to the object, such as descriptions and digi port addresses.)
mutex is magic in both XXX and XXX_cfg. There is one character for each mutex set,
indicating the unset (derived) value in this set. The coding is 0x40 + colorder,
where each field must have a unique colorder value.
```
### IMS Motor
```
The weirdness for IMS motors is that we have some derived values:
ERES = UREV / (4 * EL)
MRES = UREV / (FREV * MS)
Now, FREV and MS are not really changeable (they are hardware parameters),
so we can solve the latter by saying that [MRES, UREV] is a mutual exclusion
set.
The situation is a little weirder for the first equation.
- If you set UREV, ERES changes.
- If you set ERES or EL, the other one changes.
So, we solve this by calling [ERES, EL] a mutual exclusion set, and ordering
writes:
- UREV is first (setorder 1).
- ERES and EL are later (setorder 2).
- ERES is also "must write" (setorder is negative!).
So if we want EL to be the derived value:
- We write UREV (which changes ERES).
- We write ERES (which changes EL).
```
### Name map table
```
The *_name_map table has the following fields:
db_field_name - The name of the field, used to access the PV. It either
starts "FLD_" (indicating that the name is to be appended
to the base name with a period) or "PV_" (indicating that
the name is to be appended to the base name with a colon.)
Double underscores are converted to single throughout.
alias - The short name of the field, put into the column header.
tooltip - The tooltip for the field.
enum - If the PV is an enum, the possible values are listed here,
separated by |. (If this isn't an empty string, the editor
will be a QComboBox with the listed values.)
col_order - A unique identifier for the field which also gives the
default column order (low numbers first).
set_order - A field giving PV setting information. This has several
bitfields:
- The low 10 bits are the order. Order 0 is written
first, then order 1, etc.
- 0x200 flags this order as a mutex group as well.
Fields in a mutex group must have distinct non-zero
values.
- 0x400 flags a PV that must be written, even if the
value doesn't seem to change.
- 0x800 flags a PV that must be set to zero first.
- 0x1000 flags the "autoconfiguration" PV (the serial
number).
- 0x2000 flags "readonly" PVs.
mutex_mask - If several values are interrelated, this value will be
non-zero. It is a bitmask of values in the interrelated
set. Several bits can be 1 if this field is in several
sets.
```
### Logging into MySQL
```
Log into MySQL with the following commands:
Server is psdb.slac.stanford.edu, though you can log in from
psdev because of the --host=psdb argument...
(ADMIN MODE)
> mysql --host=psdb --user=pscontrolsa --password=pcds pscontrols
(USER MODE)
> mysql --host=psdb --user=pscontrols --password=pcds pscontrols
```
Raw data
{
"_id": null,
"home_page": null,
"name": "pmgr",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.9",
"maintainer_email": null,
"keywords": null,
"author": "SLAC National Accelerator Laboratory",
"author_email": null,
"download_url": "https://files.pythonhosted.org/packages/bb/89/71903fbaf0b480e34649902fe9fc5d8a95074a2fa077db064e767b344486/pmgr-2.1.3.tar.gz",
"platform": null,
"description": "# Parameter Manager\n\nPackage used in LCLS to manage motor parameters. Currently in use to manage\nconfigurations for IMS motors in the LCLS1 hard x-ray hutches.\n\n## Implementation Notes\n\n```\nWe assume that there are a number of \"classes\" of things to be configured.\nIf one such class is XXX, then we will have three mysql tables for it:\n -- XXX_cfg is a table of configurations.\n -- XXX_name_map is a table of field aliases.\n -- XXX is a table of configured objects.\n\nThe first set of fields in each of these tables is fixed, so we can operate\ngenerically on any configuration class.\n\nThe configurations in XXX_cfg start with the following fields:\n `id` int(11) NOT NULL AUTO_INCREMENT, -- The primary key\n `name` varchar(15) NOT NULL UNIQUE, -- The name of the configuration\n `config` int(11), -- The parent configuration\n `security` varchar(30),\n `owner` varchar(10),\n `dt_updated` datetime NOT NULL,\n `mutex` varchar(16),\n\nIt is assumed that there will always be a \"DEFAULT\" configuration with id 0. This will\nbe the only configuration with a null link. This should be a \"no-op\" configuration!\n\nAfter these, there will be many fields of various types all named \"FLD_*\" or\n\"PV_*\". The idea is that each configuration will be applied to a base PV name.\n The \"_*\" is what should be appended to the base PV name. Any \"__\" will be\nchanged to a single \"_\" in the actual name, and any single \"_\" will be changed\nto \":\" with the exception of the last. For \"FLD\", the last \"_\" will become \".\"\nwhile for \"PV\" it will become \"_\".\n\nFor example if the base is IOC:TST:01:CTRL,\n\tFLD_XY -> IOC:TST:01:CTRL.XY\n\tPV_XY -> IOC:TST:01:CTRL:XY\n\tFLD_XY_Z -> IOC:TST:01:CTRL:XY.Z\n\tPV_XY_Z -> IOC:TST:01:CTRL:XY:Z\n\tFLD_XY__Z -> IOC:TST:01:CTRL.XY_Z\n\tPV_XY__Z -> IOC:TST:01:CTRL:XY_Z\n\nThis is implemented by the function fixName.\n\nThe XXX_name_map table has fields:\n `db_field_name` varchar(30) NOT NULL, -- The FLD_* or PV_* field name.\n `alias` varchar(16) NOT NULL, -- A human-readable alias for this field.\n `tooltip` varchar(60), -- A tooltip for the field.\n `enum` varchar(120), -- If an enum type, possible names, separated by '|'.\n `col_order` int(11) UNIQUE, -- Where this field should be displayed (< = more left).\n `set_order` int(11), -- How to set this field. Low ten-bits are order (< = set earlier)\n\t\t\t\t\t -- 0x0200 flags this as a mutex group.\n\t\t\t\t\t -- 0x0400 flags a must-write PV.\n\t\t\t\t\t -- 0x0800 flags a write zero, then write value PV.\n\t\t\t\t\t -- 0x1000 flags the \"autoconfiguration\" PV (deprecated!!!).\n\t\t\t\t\t -- 0x2000 flags a read-only value.\n `mutex_mask` int(10) unsigned -- A bitmask of values that are interrelated. Each bit is a different set,\n -- so a field can be in several sets.\n\nThe XXX table has fields:\n `id` int(11) NOT NULL AUTO_INCREMENT, -- The identifier of this object.\n `config` int(11) NOT NULL, -- The configuration id of this object.\n `owner` varchar(10),\t -- Which hutch owns this object.\n `name` varchar(30) NOT NULL, -- The name of this object.\n `category` varchar(10),\n `rec_base` varchar(40) NOT NULL, -- pv/field base prefix --\n `mutex` varchar(16),\n `dt_created` datetime NOT NULL, -- When the record was created.\n `dt_updated` datetime NOT NULL, -- When the record was modified.\n `comment` varchar(80),\n\nAfter these fields, the XXX table may also have \"FLD_*\" and \"PV_*\" fields\nas described above. (These should be object specific things that are always\nunique to the object, such as descriptions and digi port addresses.)\n\nmutex is magic in both XXX and XXX_cfg. There is one character for each mutex set,\nindicating the unset (derived) value in this set. The coding is 0x40 + colorder,\nwhere each field must have a unique colorder value.\n```\n\n### IMS Motor\n\n```\nThe weirdness for IMS motors is that we have some derived values:\n\tERES = UREV / (4 * EL)\n\tMRES = UREV / (FREV * MS)\n\nNow, FREV and MS are not really changeable (they are hardware parameters),\nso we can solve the latter by saying that [MRES, UREV] is a mutual exclusion\nset.\n\nThe situation is a little weirder for the first equation.\n - If you set UREV, ERES changes.\n - If you set ERES or EL, the other one changes.\n\nSo, we solve this by calling [ERES, EL] a mutual exclusion set, and ordering\nwrites:\n - UREV is first (setorder 1).\n - ERES and EL are later (setorder 2).\n - ERES is also \"must write\" (setorder is negative!).\n\nSo if we want EL to be the derived value:\n - We write UREV (which changes ERES).\n - We write ERES (which changes EL).\n\n```\n\n### Name map table\n\n```\nThe *_name_map table has the following fields:\n\tdb_field_name - The name of the field, used to access the PV. It either\n\t starts \"FLD_\" (indicating that the name is to be appended\n\t\t\tto the base name with a period) or \"PV_\" (indicating that\n\t\t\tthe name is to be appended to the base name with a colon.)\n\t\t\tDouble underscores are converted to single throughout.\n\talias - The short name of the field, put into the column header.\n\ttooltip\t - The tooltip for the field.\n enum - If the PV is an enum, the possible values are listed here,\n\t\t\tseparated by |. (If this isn't an empty string, the editor\n\t\t will be a QComboBox with the listed values.)\n col_order - A unique identifier for the field which also gives the\n\t\t\tdefault column order (low numbers first).\n\tset_order - A field giving PV setting information. This has several\n\t\t\tbitfields:\n\t\t\t - The low 10 bits are the order. Order 0 is written\n\t\t\t first, then order 1, etc.\n\t\t\t - 0x200 flags this order as a mutex group as well.\n\t\t\t Fields in a mutex group must have distinct non-zero\n values.\n\t\t\t - 0x400 flags a PV that must be written, even if the\n\t\t\t value doesn't seem to change.\n\t\t\t - 0x800 flags a PV that must be set to zero first.\n\t\t\t - 0x1000 flags the \"autoconfiguration\" PV (the serial\n\t\t\t number).\n\t\t\t - 0x2000 flags \"readonly\" PVs.\n\tmutex_mask - If several values are interrelated, this value will be\n\t\t\tnon-zero. It is a bitmask of values in the interrelated\n\t\t\tset. Several bits can be 1 if this field is in several\n\t\t\tsets.\n```\n\n### Logging into MySQL\n\n```\nLog into MySQL with the following commands:\n\nServer is psdb.slac.stanford.edu, though you can log in from\npsdev because of the --host=psdb argument...\n\n\n(ADMIN MODE)\n\n> mysql --host=psdb --user=pscontrolsa --password=pcds pscontrols\n\n\n(USER MODE)\n\n> mysql --host=psdb --user=pscontrols --password=pcds pscontrols\n```\n",
"bugtrack_url": null,
"license": "Copyright (c) 2023, The Board of Trustees of the Leland Stanford Junior University, through SLAC National Accelerator Laboratory (subject to receipt of any required approvals from the U.S. Dept. of Energy). All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: (1) Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. (2) Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. (3) Neither the name of the Leland Stanford Junior University, SLAC National Accelerator Laboratory, U.S. Dept. of Energy nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER, THE UNITED STATES GOVERNMENT, OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. You are under no obligation whatsoever to provide any bug fixes, patches, or upgrades to the features, functionality or performance of the source code (\"Enhancements\") to anyone; however, if you choose to make your Enhancements available either publicly, or directly to SLAC National Accelerator Laboratory, without imposing a separate written license agreement for such Enhancements, then you hereby grant the following license: a non-exclusive, royalty-free perpetual license to install, use, modify, prepare derivative works, incorporate into other computer software, distribute, and sublicense such Enhancements or derivative works thereof, in binary and source code form. ",
"summary": "Parameter Manager for LCLS Device Configurations",
"version": "2.1.3",
"project_urls": null,
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "41c5f0c36b1f8fc1aa745d65b68f34d9149f59ea4f706884c9a61a4bda32dcbb",
"md5": "c2c89acf9f37ee63517883650017cbbb",
"sha256": "ae973ac46aaf06d84e0592992a1016f32153d0cc4fee314ca90def8f654390ad"
},
"downloads": -1,
"filename": "pmgr-2.1.3-py3-none-any.whl",
"has_sig": false,
"md5_digest": "c2c89acf9f37ee63517883650017cbbb",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.9",
"size": 78013,
"upload_time": "2024-05-02T21:32:53",
"upload_time_iso_8601": "2024-05-02T21:32:53.173180Z",
"url": "https://files.pythonhosted.org/packages/41/c5/f0c36b1f8fc1aa745d65b68f34d9149f59ea4f706884c9a61a4bda32dcbb/pmgr-2.1.3-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "bb8971903fbaf0b480e34649902fe9fc5d8a95074a2fa077db064e767b344486",
"md5": "f33b8a8c316570fd0152ac86650ed142",
"sha256": "ea0323655a21b3d59fed471aaa0f78de631f0c9194d454b35713aff41eb8a862"
},
"downloads": -1,
"filename": "pmgr-2.1.3.tar.gz",
"has_sig": false,
"md5_digest": "f33b8a8c316570fd0152ac86650ed142",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.9",
"size": 72303,
"upload_time": "2024-05-02T21:32:54",
"upload_time_iso_8601": "2024-05-02T21:32:54.868725Z",
"url": "https://files.pythonhosted.org/packages/bb/89/71903fbaf0b480e34649902fe9fc5d8a95074a2fa077db064e767b344486/pmgr-2.1.3.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-05-02 21:32:54",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "pmgr"
}
