ENH: expanded sim ioc generation, mfx example tree

[ZLLentz]

Description

• Expand the sim IOCs to build themselves from real PVs to create a mock IOC as similar as possible to the real deal.
• Add tests for this expanded functionality
• Add an examples folder
• Include an example tree that could be used to prepare some portion of the MFX beamline for beam.
• Include helper scripts for testing and iterating on this example tree offline

Motivation and Context

• closes Ability to simulate a real BT easily || generate moc IOCs from a real world example OR swap in a blackboard equivalent of the tree #53
• addresses https://jira.slac.stanford.edu/browse/BEAMS-6
• The more realistic example IOCs this generates were very impactful for doing offline testing of the MFX tree.

How Has This Been Tested?

Interactively we can make it all the way through the tree!
I added and updated some unit tests.

Where Has This Been Documented?

Helpful docstrings and commments
Pre-release notes

Pre-merge checklist

• Code works interactively
• Code follows the style guide
• Code contains descriptive docstrings, including context and API
• New/changed functions and methods are covered in the test suite where possible
• Test suite passes locally
• Test suite passes on GitHub Actions
• Ran docs/pre-release-notes.sh and created a pre-release documentation page
• Pre-release docs include context, functional descriptions, and contributors as appropriate

[ZLLentz]

The special launcher script here helps me run and test my tree and sim like this which is quite a bit better than some of the previous test variants:

[ZLLentz]

Updated version:

[ZLLentz]

I'm intending to add a copy-the-ioc test and a pre-release docs before asking for reviews.

[tangkong]

tests go boom :(

[ZLLentz]

I should have caught that one, I forgot to re-run the tests after making "just one small change"

[tangkong]

There's a lot less to review here than I originally thought, though I'm mostly just assuming the autogenerated files are fine.

I don't really have much to criticize here. The new sim utilities look very useful and I look forward to using them even outside of BEAMS

I really appreciate all the comments / explanations, I think we'll be very grateful for them in the future.

[tangkong]

there are too many contexts. I see this is not quite the same as pyepics' context, we just use it to gather PVs

[ZLLentz]

It's actually a close analog of the epics context in a lot of ways, just like pyepics's context (I think?) but the python apis are quite different between the two

[tangkong]

TIL this exists. This is a neat little alternative if a library is using caproto.

[ZLLentz]

Yeah, I decided to use caproto to measure since I was generating a caproto script anyway, so I assumed it would grant some consistency advantages. I'm not sure this assumption ended up being true but I learned a few tricks from the docs this time.

[tangkong]

Does it matter that we sort the PVs? Or is it just for ease of reading through the rendered template

[ZLLentz]

Two reasons:

• In this implementation, the PVs are in essentially a random order (from the batch call) and I wanted a deterministic order to make regenerations of the same script consistent
• Easy of reading as you say

[tangkong]

As far as defaults go I might pick something that doesn't collide with the STRING default

[ZLLentz]

that's fair, I wanted all the values to be pi and took it too far

[tangkong]

This is the most python-y test I've seen in a while haha.