Fix blocking calls in Handle Command

[ciozi137]

[ciozi137]

@ciozi137 what is the status of this issue?

[ciozi137]

Handle Command.vi is still called by Instrument.lvclass:Process.vi. The "SetMagnetField" Sequence is handled by Instrument.Oxford1820.lvclass:Process.vi. I think that the issue described above needs to be better handled by the Instrument Framework

• https://github.com/levylabpitt/Instrument-Framework/issues/51 proposed a half-baked solution
• https://github.com/levylabpitt/Instrument-Framework/issues/26 more semi-progress

Perhaps Handle Command.vi should simly call "Send Message to Process" to forward the command to the child process. But how to deal with callbacks? As it is Handle command waits until there is a response to give. Not a great architecture.

[ciozi137]

PPMS uses its process.vi to communicate with the hardware. Messages are sent to it by PPMS:MessagetoProcess.vi; Replies go to Instrument:MessageToProcess.vi [Instrument broadcasts to the public via Instrument:MessageFromProcess.vi].

Oxford 1820 and VRM use their process.vi to handle sequences of commands (Heater, match PS current, wait, etc)

I think the solution should be to move all hardware communication to the child process.vi (like PPMS does); the child process can also be used to handle sequences (like 1820 and VRM) especially if non-blocking calls are avoided (see Wait sequence). Handle Command.vi should do simple message parsing: it can respond with data if it has, or forward messages to the child to execute.

[ciozi137]

• the template process.vi should have a non-blocking wait sequence
  • add a sequencer from JKI also?
• change the way "GetAll" is handled?

[ciozi137]

• [x] Non-blocking wait (Macro: Run Sequence, Sequence: Wait, Data: [Running Step, Sequence Array]
• [x] Front panel decoration and UI initialize to decoration
• [x] SMO Event-Related (Instrument-Template.lvclass):
  • Instrument-Template.GetPrivateEvents.vi
  • Instrument-Template.SendMessageToProcess.vi (private method! called in Instrument-Template:Handle Command.vi)
  • CreatePrivateEvents.vi (override)
  • DestroyPrivateEvents.vi (override)
• [x] Template: Process.vi should handle open, close, and other hardware events In "Instrument: X" states
  • Should Open Hardware.vi and Close Hardware.vi abstract methods persist?
  • Maybe the open/close code should go inside Handle Command...this would facilitate calls from remote

[ciozi137]

• [x] take Error Handler and Macro: Post-Error Handling states from SMO v 1.4 template

[ciozi137]

Error handling updated in Instrument.lvclass:process.vi and Instrument.Framework-Template.lvclass:process.vi

[ciozi137]

CreatePrivateEvents, GetPrivateEvents, DestroyPrivateEvents, SendMessageToProcess created, configured, and called in Instrument.Framework-Template.lvclass:process.vi

[ciozi137]

Instrument.lvclass:process.vi: "Instrument: Open" and "Instrument: Close" are now disabled by default. If the user needs them (they have not moved their open/close to the child process) they can enable the states. But this is NOT recommended.

[ciozi137]

Open and Close are states in the Template:process.vi. Handle Command is perfectly capable to forward the command to the child process if the developer would like to go that route.