Closed JustinLangridge closed 8 years ago
This is a mixture of a couple of problems.
Confounding this is a mish-mash of approaches down on the server. The idea behind the Instrument
class is that it can be operated sans the Actor Framework if desired. Hence, there is some decoupling. The Actor
contains the CVT reference and while configuration occurs in Instrumnent::Configuration
; hence, we have to send an update from the Instrument
object to the CVT reference.
In a standard interaction, we send a message down from the Controller
to the Instrument
via a Command
object. The Command
object implementation contains a static method that allows the Command
object to send a message via the command queue (a property of the Instrument Actor
object) down to the Instrument
object and receive a response that the command is successful.
In configuration, we bypass this mechanism. Possibly the best most consistent approach would be to have the response encapsulated in the Actor
object that sends contains both the Command
queue reference as well as the CVT
reference.
As far as the enables go, we were sending the wrong message to the Instrument
object.
Also looks like there were others that were not using the right command objects...
Speaker Vparams
now updating properly.
Both of these above are updating as expected.
Matt, that is good. Do you need us to provide a full list of which PAS/CRDS controls are not initiating properly or are you able to work this independently?
If you have them, they need to be their own issues - maybe grouped according to instrument or device. Did we fix these problems? Can we close this?
Several signals do not initialise as per the .ini file. Examples are the PAS laser enable signals, speaker voltage values, maybe others(?)