There is yet another duplicated (and possibly outdated) source of information:
https://www-acc.gsi.de/wiki/FESA/FESA3StandardPropertiesAndValueItems
I suppose we should close/remove that Wiki site to prevent duplication of information.
It looks like currently we have some separate Wiki Page for that:
https://www-acc.gsi.de/wiki/FESA/FESA3UnitsSuffixNames
If it makes sense, we should have that stuff in the guideline instead and remove the WIki page (To prevent duplicated information)
al.schwinn (c17573bc) at 12 Mar 11:32
Testing multiplexed setting
al.schwinn (73b5a826) at 07 Mar 09:35
Added printf output to cmw-tester
al.schwinn (198f0f72) at 06 Mar 13:12
initial commit
al.schwinn (2c36ee64) at 06 Mar 13:11
initial commit
@m.marn: While I further think about it, I suppose it could be beneficial to not introduce the creation/processing of a fully fledged Fesa class into silecs-testing, but instead only test our generated AllTypes.cpp
/AllTypes.h
by injecting some Fake classes. As far as I can see, we would need Fake-classes for ServiceLocator
, MultiplexingContext
, Device
, MyRWBlockPropPropertyData
, MyWOBlockPropPropertyData
and MyCBlockPropPropertyData
.
You think it would make sense to Test like that ? Or would you rather go for a full Fesa-Class ?
Besides that, suppose we would net something like this:
The testing client(or Fesa class) should get/set each possible PLC value via the different get/setOneDevice/someDevice/AllDevices methods
Closes #106
Thank you for the changes @m.marn!
Finally, I found some time for testing and got it to work for both, device-mode and block-mode \o/
I did a few additional changes:
tsts7001
in the instance file, and automatic creation of a symlink during release to load the correct *.silecsparam
Question ariesed during discussion of the PPOS Property API together with @a.walter, @b.peter and @r.hari
For devices, there is often the situation that they can be either operated multiplexed, triggered by Timing-Events or non-multiplexed, triggered by some manual-move property or in local mode.
This creates the need of having both, multiplexed and non-multiplexed Setting and Acquisition Properties.
For PowerSupply e.g., there is Acquisition
(muxed) and DCValueAcq
(non muxed)
For PPos we are currently planning to have Setting
(muxed) and SettingDirect
(non muxed)
Since the use-case actually is the same for probably many more devices, it would be nice to use some standard-naming convention for these properties. (E.g. always call them AcquisitionMuxed
and AcquisitionNonMuxed
?)
This seems to collide with the wish to always have one setting property, called Setting
, to be used by LSA. (Maybe we should have SettingLSA
instead?)
Edit: For Acquisition properties, it actually seems to be possible to only use a single, multiplexed Acquisition Property for both, multiplexed and non-multiplexed values (Here a demonstrator Fesa class and its DU). Though the problem remains for the property Setting
for which that is not possible (a muxed setting prop throws an error when called with non-muxed context). And in any case, standardization is required for this issue.
Technically, could be solved like this (Having the FESA XML Documentation linking to this Guideline instead of having duplication)
Doing that for GSI specific items would be no problem. Doing so for general items would require to touch the part we share with CERN (though might not even be needed).
Filters are not optional for the client. When a property has a filter, the client cannot ommit it.
I think you are wrong with this statement. E.g. in the DigitizerClass I always leave some of the filters blanc in the FEX … they are optional. There are dedicated Fesa methods to check if a filter is available in a Fesa server action, or if it is missing. See e.g. here.
al.schwinn (aab27303) at 24 Feb 16:48
Use new yoctoSDK path
al.schwinn (5d5bf124) at 24 Feb 16:47
Use new yocto SDK path path
We just realized that on our discussion on PPOS:
https://git.acc.gsi.de/awalter/FESA-API-Comments/pulls/1#issuecomment-21307
E.g. if the Aquisition Property has 10 value-items, it does not make much sense to add another [value-item-name]_status
value-item for each single item, if these extra-items anyhow all would contain the same data.
Specifically for PPOS we decided to not send the data at all if it might be corrupt. However, for other FESA classes, this might be relevant.