Comments (17)
For all of these, < devicename > refers to the tag of the particular device in the config file. This will (probably) be advertised by Nora/Mr. Freeze periodically so clients don't have to know them ahead of time and can just discover them. The config file specifies what kind of device each thing is, so the command dictionaries can be written per-device.
All Devices
- Set device hostname/port
- < devicename > setconnection < hostname:port >
- This one will not be valid for the 'arc-loisgettemp' device types, they're special kludges.
- < devicename > setconnection < hostname:port >
- Enable/disable device query
- < devicename > setstatus < 'enable' or 'disable' >
from mrfreeze.
Sunpower Cryotel Specific
For all of these, < value > is optional; if it's None, the command will return the current value of the given command.
Gen. 2 controllers only
- Enable/disable cooler software stop (SSTOPM)
- < devicename > stopmode < value >
- In this case, value should only be 'enable' or 'disable'
- < devicename > stopmode < value >
- Start/stop cooler (SSTOP, only if SSTOPM == 0)
- < devicename > stop < value >
- In this case, value should only be 'on' or 'off'
- < devicename > stop < value >
- Get/set min/max cooler power
- < devicename > minpwr < value >
- < devicename > maxpwr < value >
- Get full cooler config/state
- < devicename > state
- Get cooler measured power
- < devicename > mpower
Gen. 1 & 2
- Get cold tip temperature
- < devicename > coldtip
- Get cold tip set point
- < devicename > target < value >
- Get current min/max/commanded power
- < devicename > cmdpower
from mrfreeze.
Lake Shore Specific
LS 218
- Get all temperatures
- < devicename > readall
- Note that I'm skipping the individual reads. I don't think I'll ever need it but it's trivial to add if that changes in the future.
- < devicename > readall
LS 325
Temperature inputs are referred to as "A" or "B" inputs.
Heater/setpoints are referred to as "loop 1" or "loop 2"
For us, loop 1 is the (higher power) loop attached to the getter, and loop 2 is the detector temperature regulator. Could rename things accordingly to reduce confusion I suppose.
- Get temperature input A/B
- < devicename > reada
- < devicename > readb
- Get temperature setpoint 1/2
- < devicename > getsetp1
- < devicename > getsetp2
- Set temperature setpoint 1/2
- < devicename > setsetp1 < value >
- < devicename > setsetp2 < value >
- Get heater 1/2 power
- < devicename > gethtrpwr1
- < devicename > gethtrpwr2
- Get heater 1/2 status
- < devicename > gethtr1
- 0 = Off, 1 = Low (2.5 W), 2 = High (25 W)
- < devicename > gethtr2
- 0 = Off, 1 = On
- < devicename > gethtr1
- Set loop 1/2 heater on/off
- < devicename > sethtr1
- For this one, value should either be 'high' or 'low' or 'off' which is mapped to 2, 1, 0
- < devicename > sethtr2
- For this one, value should either be 'on' or 'off' which is mapped to 1, 0
- < devicename > sethtr1
- Just read all the things
- < devicename > readall
- This is really a macro/combo command; it incorporates all of the above. It's defined in the remoteAPI, not the
allCommands
set. I have to do this because the LS325 lacks a built-in bulk read function like the LS218 has.
- This is really a macro/combo command; it incorporates all of the above. It's defined in the remoteAPI, not the
- < devicename > readall
There's an opportunity for nanny-code/logic in the 'setheat1' command, which could either require an extra argument (a password/keyphrase of some sort) before it actually enables. But that's overkill IMHO.
from mrfreeze.
MKS Specific
MKS 972b
One could query things from the vacuum gauge controller (PDR900) as well, but querying the gauge directly gets you both a faster answer as well as the individual measurements broken out. The only reason to query the gauge controller is to use it's built-in logging capability as far as I can tell.
- Get micropirani value
- < devicename > micropirani
- Get cold cathode value
- < devicename > coldcathode
- Get combined value
- < devicename > comboprec4
- If you want the one with 3 significant digits, you can use the 'comboprec3' instead
- < devicename > comboprec4
- Get all pressures
- < devicename > getvals
- As with the LS325, this is a macro/combo command defined outside of the
allCommands
set.
- As with the LS325, this is a macro/combo command defined outside of the
- < devicename > getvals
from mrfreeze.
There's a general roadblock because of how this is stuck in my brain; I'd like to declare all the commands up front, but the ambiguity of some of them is posing a logic problem.
For Sunpower Cryotel coolers, SET TTARGET
queries the current cold tip set point. But, SET TTARGET=XX.X
actually sets a new set point. The Sunpower cooler is a modern marvel so I'll let this slide I guess.
from mrfreeze.
Bulk of the remote-side work completed by 9fbfdec; now testing! Actual command-side/construction work is up next.
from mrfreeze.
Just realized I need to handle the case where someone requests/sends an action for a device that's disabled. UI/UX stuff is so damn complicated.
from mrfreeze.
When thinking about how to construct the command packet for real just now, I almost gave up and just did a text packet with no XML schema or formatting, completely going against my silent crusade of the last year.
Almost.
Here's the new idea:
<?xml version="1.0" encoding="utf-8"?>
<MrFreezeCommunique>
<Command>
<Instrument>NIHTS</Instrument>
<Device>sunpowergen2</Device>
<Tag>BenchCooler</Tag>
<Command>coldtip</Command>
<Value></Value>
</Command>
</MrFreezeCommunique>
from mrfreeze.
Here's what I settled on; I think these tags are worded better
<MrFreezeCommunique>
<request>
<instrument>NIHTS</instrument>
<device>sunpowergen2</device>
<tag>BenchCooler</tag>
<command>coldtip</command>
<argument></argument>
</request>
</MrFreezeCommunique>
from mrfreeze.
Working on the advertisement of available things from Nora to the outside world; current wrinkle is that I've explicitly designed all of this to check for the sections in which enabled == True
but now I also realize I need to care about the disabled ones too.
from mrfreeze.
Here's a first draft of the advertising packet:
<?xml version="1.0" encoding="utf-8"?>
<MrFreezeCommunique>
<advertisement>
<device>
<instrument>LMI</instrument>
<device>arc-loisgettemp</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>false</enabled>
</device>
<device>
<instrument>LMI</instrument>
<device>sunpowergen1</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>false</enabled>
</device>
<device>
<instrument>DeVeny</instrument>
<device>arc-loisgettemp</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>false</enabled>
</device>
<device>
<instrument>DeVeny</instrument>
<device>sunpowergen2</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>false</enabled>
</device>
<device>
<instrument>NIHTS</instrument>
<device>vactransducer_mks972b</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>true</enabled>
</device>
<device>
<instrument>NIHTS</instrument>
<device>sunpowergen2</device>
<tag>DetectorCooler</tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>true</enabled>
</device>
<device>
<instrument>NIHTS</instrument>
<device>sunpowergen2</device>
<tag>BenchCooler</tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>true</enabled>
</device>
<device>
<instrument>NIHTS</instrument>
<device>lakeshore218</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>true</enabled>
</device>
<device>
<instrument>NIHTS</instrument>
<device>lakeshore325</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>true</enabled>
</device>
<device>
<instrument>TravellingPumpSystem</instrument>
<device>vactransducer_mks972b</device>
<tag></tag>
<hostname>NNNNNNNN</hostname>
<port>XXXX</port>
<enabled>false</enabled>
</device>
</advertisement>
</MrFreezeCommunique>
This lets me have a schema that is super generic and simple, rather than worrying about a schema that has to account for each and every instrument type in each instrument section. With this style above, I don't ever have to touch the schema again.
from mrfreeze.
Ok so I'm able to finally prototype the final commands, the adjustment of a defined instrument device. If I keep the same command packet style I don't have to create a new schema; I just have to create a new command dictionary. Would this work?
<MrFreezeCommunique>
<request>
<instrument>NIHTS</instrument>
<device>sunpowergen2</device>
<tag>BenchCooler</tag>
<command>X</command>
<argument>Y</argument>
</request>
</MrFreezeCommunique>
These would take no argument:
queryenable
querydisable
These take a sensible argument:
devicehost < value >
deviceport < value >
They're different than what I sketched out a week ago, but I think they fit better into this scheme. There's just the lingering question of how to actually get the command back into Nora, which I'm working on now.
from mrfreeze.
Should also make the 'advertise' functionality requestable rather than regular; that'd let Victor (or whomever) immediately get the answer. But to do that properly, I'd have to make the instrument dict that contains everything part of the listener class, since that's who would be responding.
from mrfreeze.
There is so much wrapped up in this project! I've got to go and fix LowellObservatory/NightWatch#37 because the root cause of that is the lack of data within a given time window, and in order to start developing the plots next I've got to deal with that.
from mrfreeze.
Aaaaaaand to properly fix that, I should take a look at https://github.com/LowellObservatory/NightShift/issues/4 again because it involves restructuring the calling sequence. (edit: I did, and I decided to wait on that a little longer)
In order to get a guaranteed result no matter if the query actually finds data or not, I have to adjust getResultsDataFrame
to always fill the dict values...and to do that, I've got to probably mash it together with queryConstructor
and to do that, I should just suck it up and close the above-mentioned dangling issue.
from mrfreeze.
A lot of these don't really need to be exposed to the end user, and I've mixed up the requirements for the internal command names/options and the externally supported ones all throughout this. I'll be collating this stuff into a Confluence page for a more clear description, and will probably export it/put it into the eventual documentation back in here once the dust settles.
from mrfreeze.
I think this issue has served it's purpose, and I've started documentation elsewhere (https://jumar.lowell.edu/confluence/x/gQhCAg) so I'm content to finally close this one.
from mrfreeze.
Related Issues (16)
- Proper packaging
- Query all enabled devices at startup HOT 1
- Migrate old instrument temperature data HOT 2
- Add CSHELL Devices: Scientific Instruments 9620-1, Lake Shore 331, and Varian AGC-100 HOT 8
- Fix hardcoded config items HOT 2
- Calculate and store temperature ramp rates
- Fix up LOIS log parsing more HOT 1
- Sort out serComm HOT 4
- Fix listener HOT 3
- Documentation!
- Parsers need rails HOT 3
- Planning out the 'gettemp' replacement HOT 5
- Figure out log file support
- Figure out enabling/disabling modules without restarting manually HOT 5
- Tie broker subscriptions to 'enabled' statuses? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mrfreeze.