What’s new in Pyrame 3¶
Pyrame 3 is the last release of the Pyrame online software suite. It brings a lot of new feature and improvements. This document expose them by theme.
Robustness¶
In order to guarantee a better stability of the system, an environment has been implemented in cmdmod. The module can now store all information in this environment provided by cmdmod. This environment is saved regularly on the disk. This way, if a module crash, it can be relaunched with its previous environment and thus the system recover from this very severe problem. More than that, the environment is automatically coupled to cmod which allow to syncrhonize the values of the module and the value of the xml configuration file. The programmer does not need anymore to register the object in cmod nor update the value of its parameters. All is handled automatically by cmdmod.
To ease the use of this environment, two python modules has been written to help you storing data in it: penv and pool. Please, see their documentation for more details.
To increase the robustness of the system, all modules using established connection has been rewritten to verify their connection and re-established them if necessary, any time they need it.
Data management¶
Pyrame 3 includes now a data disptching system. Any module can generate data and made them available in the system. It registers as a data source and publish data with the submod dispatching function. Other modules can than connect to this data source and publish their own derived data. This mechanism has been described in the article #TODOref.
event loop
Easyness of programming¶
Setres replacement¶
- The first and more visible change is the end of the use of setres: instead of writing::
- submod_setres(0,”error message”)
- you can now write::
- return 0,”error message”
The benefit is that there is no more need to have external and internal function. Any function can be handled as an internal function because setres is not anymore a side effect.
execcmd¶
- submod_execcmd has also change. Instead of calling::
- submod_execcmd(“func_module”,params)
- we are now using::
- submod_execcmd(“func@module”,params)
This way, we can use underscore(_) in the module name.
Automatic function discovery¶
There is no more need to fill the xml module file with the name of the functions. They are automatically exctracted from python programs. For other languages, pragma tags are used to export their api. Thus, the xml file is really easier to write and has typically only five lines.
String identifier¶
In Pyrame 2, all identifiers were numerical. This could be confusive and it was a pain to find the id of a device. In Pyrame 3, all devices has string identifiers. They can be choosen arbitrary and are similar to the cmod name. This ease a lot the debugging and CLI use.
New feature¶
cmdmod¶
The submod api has been drastically increased. A lot of new functionality has been integrated to avoid module writer to handle themselves heavy system treatments.
Here is a quick list of the new function. Please, see the cmdmod documentation for complete description
- submod_bgcontext and submod_sendres allows to execute a command in background and let other command executes. Beware the deadlocks!
- submod_setvar, submod_getvar, submod_delvar, submod_gettype, submod_newns, submod_checkns, submod_delns, submod_dumpns, submod_listns: all this functions allow to manipulate the environment.
- submod_setmyname, submod_getport, submod_exit, submod_getip: this functions are system manipulations
- submod_wakemeup: allow to wake up the module in the future
- submod_init_dispatcher, submod_flush_dispatcher, submod_new_block, submod_new_event, submod_add_block, submod_set_field_block, submod_set_field_event, submod_finalize_block, submod_set_chans: this functions allows to dispatch data from the module
storage¶
New hardware modules¶
- New module for OMEGA’s SKIROC2CMS
- New module for Tektronix AFG 3000 series pulse generator
- New module for Keithley 707B matrix switch
- New module for Keithley 6517 electrometer
- New module for Parker XLI stepper motors
Acquisition chain¶
start/stop per unit
Signal¶
New api to merge sigpulse and sigsquare
logger¶
persistence periodicity per variable multithreaded implementation data injection
dp¶
generic data plotter
