Remote/broker command set definition about mrfreeze HOT 17 CLOSED

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.
• 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'
• Start/stop cooler (SSTOP, only if SSTOPM == 0)
  • < devicename > stop < value >
    • In this case, value should only be 'on' or 'off'
• 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.

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
• 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
• 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.

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
• Get all pressures
  • < devicename > getvals
    • As with the LS325, this is a macro/combo command defined outside of the allCommands set.

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.