Simulation Upgrade

[TimGuiteDiamond]

The simulation is reaching its limits with PVs that can be initialised and reinitialised, have limits and timestamps etc. There is also a need to add enums and arrays to the simulation.

In order to tie in with #34 it seems that an upgrade may be required. It would be nice to initialise a simulation environment of some kind from JSON which communicates through the middleware in the same was the Coniql client or other middleware.

Therefore, the simulation should:

• be initialised separately from the components rendered on screen
• maintain its own values separately from the store
• provide a mechanism for updating values
• provide a mechanism for pushing values on changes or new subscriptions
• provide a mechanism to stop pushing values when the subscription has finished

In effect, we should aim to more fully simulate the environment we wish to use the application in.

[talwrii]

I want to split out the separate changes into sections.

Remove namespaces

meta:// lives in a separate namespace. We could replace this with sim://limits.

Make some simulated values writeable

meta:// is already writeable. If we are to move meta:// in to the simulated namespace then it seems to make sense to make most simulated pv's writeable (with the exception of those that generate random values).

This could be achieved by having SimPv implement an updateValue method that can error out for e.g. sine simulated pv's.

Remove duplication when instantiating PVs

This could be achieved by using a switch (or more general switch) to find class to instantiate and then instantiate it with the same arguments.

maintain its own values separately from the store

As far as I can tell, this already happens.

Delete Pv's on unsubscribe

Non-features / delayed features

be initialised separately from the components rendered on screen

I am not sure what value this provides. Is there a use case for this?

[willrogers]

I just had a talk to Tim. We could potentially have multiple sim://limits PVs (e.g. sim://limits100) if we felt it was necessary. But sims aren't fundamental, they are for demonstration purposes, and something like meta:// isn't that flexible for other purposes.

[willrogers]

I don't think there's any need to initialise PVs other than at the time they are requested. But it might be nice to close them when the last subscriber is removed, as for real PVs.

[talwrii]

We could potentially have multiple sim://limits

I might vote for sims://limits#name so as to ape html; or perhaps sims://limits.name

[willrogers]

That's an interesting idea.

[TimGuiteDiamond]

The "initialise separately" part was looking towards initialising a simulated database from a JSON file or similar and then having the client connect to that. This would be useful because for defining multiple "meta" type PVs each with different limits.

However, that in itself might not be that useful for demonstration and perhaps there are other ways to do this on the fly based on the PV name, the # idea seems interesting to me, how much information do you think could be squeezed into something like that? PV type, limits, readonly?

[willrogers]

I think that's just to be able to use different PVs with the same behaviour. So now you can use meta://pv1 and meta://pv2 but then you could have sim://limits#1 and sim://limits#2. Different behaviour would get a different name such as sim://other.

[willrogers]

This page from the Phoebus documentation talks about both sim and loc PVs. We should try to support what Phoebus supports:

https://phoebus-doc.readthedocs.io/en/latest/phoebus/core/pv/doc/index.html

Moved to #66 (talwrii)

---

talwrii: Playing with edits but this seems to create updates as other people elsewhere see #66. I don't really like this so won't do this stuff again

[talwrii]

This would be useful because for defining multiple "meta" type PVs each with different limits.

Given that phoebus forces us to support things like "sim://sine(1, 2.0)" it feels consistent to do most things through this format.

One way to achieve limits would be to support formats like sim://limit(min, max).

As an aside, this format is probably more readable than JSON though potentially:

• More difficult to prase
• More error prone to parse
• Producing less easy to debug error messages (unless one puts in quite a lot of effort)
• More likely to contain errors (since JSON verification gives one some de facto error checking)

how much information do you think could be squeezed into something like that? PV type, limits, readonly?

I'm not really sure what the limits to storing information is. On one level, everything is bytes. We could also extend this pv name format to support embedded JSON.

I guess some issues that come to mind are:

• Very long lines
• The difficulty of reporting errors

---

I can think of two use cases for this.

• Values on display that are identical and simulated, or distinct and simulated. We might for example want to show the same sine wave in two places. Phoebus doesn't really provide a nice way of doing this. We might use e.g. sim://sine#id(1) for this.
• Being able to simulate a real life control system without having access to the control system. One might, for example, want a simulated control system that is in an extreme state more often that a real system. I can imagine wanting some quite complicated behaviour here, though there is a question about whether one should be provide a simple turing complete interface here rather than trying to be everything.

I have created a separate issue(#78) for this.

[talwrii]

I'm trying to hive off bits of this discussion into separate issues to make the discussion more ordered and potentially close this issue.

See #79 for supporting limit process variables with variable limits.

See #80 for more simulated variables.

[willrogers]

If we want to provide parameterisation to sim://limits, we should use the function-style syntax. We can add such functionality as and when we feel we need it.

However, we don't want to try and simulate a sophisticated control system. This is not the place for that.

I'll close this ticket now.