Query for Enum type properties in Java

Hi,

I’m creating a Java application that uses Pulse to simulate a patient. I’ve been working without major issues until I got to get some properties from the Anesthesia Machine that are not numbers. Up to this point, I didn’t have any problem querying the anesthesia machine, an my guess is that it was because I was always querying for numeric values. For example, the following Data Requests work fine:

      {
         "propertyName":"OxygenFraction",
         "unit":"",
         "category":"AnesthesiaMachine",
         "precision":2
      },
      {
         "propertyName":"RespiratoryRate",
         "unit":"1/min",
         "category":"AnesthesiaMachine",
         "precision":2
      },
      {
         "propertyName":"PositiveEndExpiredPressure",
         "unit":"cmH2O",
         "category":"AnesthesiaMachine",
         "precision":2
      }

But, if I want to query for the Connection of the Anesthesia Machine, I would have expected the following Data Request to do the trick:

      {
         "propertyName":"Connection",
         "unit":"",
         "category":"AnesthesiaMachine"
      }

But the Data Request above gives me the following error message: [FATAL] : [0.02(s)] Unknown Data Request : Connection

And same thing happens with the OxygenSource property too. I think I can generalize this behavior to properties that are enums.

Am I doing something wrong? Or is this a known limitation in Pulse?

Thanks,

The Connection is actually an enum, so it is currently unsupported as a DataRequest

Data Requests are essentially tied to double values from the engine.

It is possible to add support to have DataRequests associated with enums return an integer value in the double. Off the top of my head, I think it would not be too complicated, but there would probably need to be some additions to the Data Request piping to get this to work.

That being said, enums have a initial value in the engine (Off in the case of the connection) and the only way it can change is by an action you provide it. So in sense, you are asking the engine for a value that you set. Unless you did not, in which its going to be at its default value (Off for a Connection).

The same would apply to substances applied to the right or left chamber. It’s empty until you provide an action putting a substance in it. But there is not currently a way piggyback a thunk of the substance name (that you provided in a previous action) in the chamber over the JNI.

Thank you for your prompt response.

In my case, we have a Pulse Engine running and multiple applications connected to it. So it could be the case that one application changes the connection without the others knowing. My first approach to solve this was to expose that value from Pulse itself, but if that’s not possible, I’ll have to deal with it at the application level (i.e. keep track of all the actions applied to a scenario) and not at the Pulse Engine level.

Thank you again for your time,

Everything in the engine is exposed at the C++ level.
Its really a question of how to thunk it over the JNI.

I have been thinking about supporting a mode in the engine so it keeps track of all incoming messages.
I believe I started it, but I don’t remember where I ended up…so it may be an option to just finish that support…But that would probably be pretty simple to do on your Pulse node as well, before you pass an action along to Pulse.

Another option is to support thunking a whole system over the JNI rather than individual Data Requests. Everything in Pulse is backed by a Protobuf definition, so this would be pretty easy and I think very helpful in general. And you would not have to sort though actions to get the current state.

Yes, I think I can handle this at the application level for now. Having a way to expose the entire state of a system at once would be nice though.

Thanks,

@esteban.aliverti,

Do you have any thoughts/concerns with Pulse being developed using Java 8?
I have run a build using further Java versions (11/12 I believe) And things built fine, but is there anything for us to keep in mind for moving to a more modern version?

Thanks!

Privacy Notice