bliss issueshttps://gitlab.esrf.fr/bliss/bliss/-/issues2024-03-28T11:25:29+01:00https://gitlab.esrf.fr/bliss/bliss/-/issues/4277get_counters_iter: CounterContainer.counters can fail silently2024-03-28T11:25:29+01:00Valentin Vallsget_counters_iter: CounterContainer.counters can fail silentlyFeedback from @claustre in the chat.
Some controllers feed dynamically `.counters`, as result `get_counters_iter` protecting the call to `.counters`.
The problem of @claustre was that a hardware was offline, so what `.counters` was rai...Feedback from @claustre in the chat.
Some controllers feed dynamically `.counters`, as result `get_counters_iter` protecting the call to `.counters`.
The problem of @claustre was that a hardware was offline, so what `.counters` was raising an error.
Could we instead fix such controllers to return `[]` when the hardware is offline?
So what we could just remove the try-except from `get_counters_iter`.
A offline controller should have a normal error proof behavior.https://gitlab.esrf.fr/bliss/bliss/-/issues/4275flint: No display of ccoords with crosshair activated2024-03-28T11:44:53+01:00Valentin Vallsflint: No display of ccoords with crosshair activatedFeedback from ID11 @wright.
When the crosshair is activated the mouse coords are not displayed (until the data is hovered).
This should display always the coords.
This have to be fixed in BLISS 2.0 and master.Feedback from ID11 @wright.
When the crosshair is activated the mouse coords are not displayed (until the data is hovered).
This should display always the coords.
This have to be fixed in BLISS 2.0 and master.version 2.0.xValentin VallsValentin Vallshttps://gitlab.esrf.fr/bliss/bliss/-/issues/4274elmo : home leaves discrepenacy between position and dial2024-03-28T13:18:37+01:00Emmanuel Papillonelmo : home leaves discrepenacy between position and dialAfter a homing (tested on an elmo controller), the position and dial position are not synchronized. So next moves requires first a sync_hard(). This was not the case in bliss 1.11.
```
NSCOPE [55]: rot.home()
NSCOPE [56]: umv(rot,0)
!!!...After a homing (tested on an elmo controller), the position and dial position are not synchronized. So next moves requires first a sync_hard(). This was not the case in bliss 1.11.
```
NSCOPE [55]: rot.home()
NSCOPE [56]: umv(rot,0)
!!! === RuntimeError: rot: discrepancy between dial (0.373005) and controller position (0.365034)
diff=0.00797035 tolerance=0.004 => aborting movement. === !!! ( for more details type cmd 'last_error(1)' )
NSCOPE [63]: rot.sync_hard()
NSCOPE [64]: umv(rot,0)
Moving rot from -130.585212 to 0.000000
```https://gitlab.esrf.fr/bliss/bliss/-/issues/4273read_position: encoder is broken for all encoders .... filtered encoder is br...2024-03-28T18:31:43+01:00Jonathan Wrightread_position: encoder is broken for all encoders .... filtered encoder is brokenSo this was working perfectly before bliss was upgraded (should be a nice clean peak). It has been broken with every bliss upgrade that I can remember!
![Screenshot_from_2024-03-27_08-46-11](/uploads/a67a9e796194f47bfdcdb3635985c830/Scr...So this was working perfectly before bliss was upgraded (should be a nice clean peak). It has been broken with every bliss upgrade that I can remember!
![Screenshot_from_2024-03-27_08-46-11](/uploads/a67a9e796194f47bfdcdb3635985c830/Screenshot_from_2024-03-27_08-46-11.png)Emmanuel PapillonEmmanuel Papillonhttps://gitlab.esrf.fr/bliss/bliss/-/issues/4272New SCPI powersupply NHS (ISEG)2024-03-26T16:08:08+01:00Anthony MauroNew SCPI powersupply NHS (ISEG)Anthony MauroAnthony Maurohttps://gitlab.esrf.fr/bliss/bliss/-/issues/4271Software regulation PID loop can silently stop2024-03-26T16:21:47+01:00Perceval GuillouSoftware regulation PID loop can silently stopspawned greenlet handling the software regulation can stop if an error occurs but no warning is producedspawned greenlet handling the software regulation can stop if an error occurs but no warning is producedPerceval GuillouPerceval Guillouhttps://gitlab.esrf.fr/bliss/bliss/-/issues/4270Allow default chain to use a custom master timer object2024-03-26T15:59:32+01:00Perceval GuillouAllow default chain to use a custom master timer objectadd an option in a chain config to use a custom timer acquisition master instead of the default SoftwareTimeradd an option in a chain config to use a custom timer acquisition master instead of the default SoftwareTimerPerceval GuillouPerceval Guillouhttps://gitlab.esrf.fr/bliss/bliss/-/issues/4269Add support for sparse VDS in scan files2024-03-21T17:44:35+01:00Samuel DebionneAdd support for sparse VDS in scan filesIn a scan file, we have a VDS to aggregate Lima's dense dataset (written over multiple files), likewise we need a way to aggregate a sparse data written over multiple files.
Sparse data are made of three 1D datasets:
- `frame_ptr`: the...In a scan file, we have a VDS to aggregate Lima's dense dataset (written over multiple files), likewise we need a way to aggregate a sparse data written over multiple files.
Sparse data are made of three 1D datasets:
- `frame_ptr`: the index of the first pixel in the `index` dataset starting from 0 in each subfile (should be 64 bit integer to accommodate long scan)
- `index`: the index of the pixel in the 2D image (32 bit integer)
- `intensity`: the intensity of the pixel in the 2D image (depends on the dtype)
In the scan master files
- `frame_ptr` would be rewritten to have a continuous numbering
- `index`: is a VDS that concatenate the 1D dataset of each individual data-file
- `intensity`: is a VDS that concatenate the 1D dataset of each individual data-file
All the datasets are prefixed with the name of the channel (e.g. `eiger2_4m_sparse_frame_ptr`, `eiger2_4m_sparse_index`, `eiger2_4m_sparse_intensity`)
Here is a snippet of code which does the rewriting of the `frame_ptr` from J. Kieffer:
```
cfpt = numpy.zeros(0, dtype=int)
offset = 0
for f in fptrs:
cfpt = numpy.concatenate((cfpt, f[:-1] + offset))
offset += f[-1]
cfpt = numpy.concatenate((cfpt, [offset]))
```
The recompaction of `frame_ptr` for 100 files of 10000 frames each takes ~48ms on my computer...https://gitlab.esrf.fr/bliss/bliss/-/issues/4267Deprecation warnings doe not show what is using the deprecated bliss API2024-03-20T18:46:04+01:00Wout De NolfDeprecation warnings doe not show what is using the deprecated bliss API```
WARNING: Function user_[print|debug|info|warning|error|critical] is deprecated since BLISS version 2.0. Use 'print' instead.
File "/home/blissadm/local/bliss.git/bliss/co...```
WARNING: Function user_[print|debug|info|warning|error|critical] is deprecated since BLISS version 2.0. Use 'print' instead.
File "/home/blissadm/local/bliss.git/bliss/common/logtools.py", line 491, in deprecated_user_print
```
Line 491 in logtools.py is not very useful. We want the line where the deprecated API is used.
Similar to `stacklevel=2` in https://docs.python.org/3/library/warnings.html#warnings.warnhttps://gitlab.esrf.fr/bliss/bliss/-/issues/4266Standard python input stuff gevent2024-03-27T14:56:00+01:00Valentin VallsStandard python input stuff geventFeedback from @sebastien.petitdemange
The following stuck the gevent loop
```
input("Hey:")
```
We could replace it by `getval.bliss_prompt` by default in the BLISS session.Feedback from @sebastien.petitdemange
The following stuck the gevent loop
```
input("Hey:")
```
We could replace it by `getval.bliss_prompt` by default in the BLISS session.version 2.1.0https://gitlab.esrf.fr/bliss/bliss/-/issues/4265Multiline shell commands hidden by the tooltip2024-03-20T12:00:29+01:00Samuel DebionneMultiline shell commands hidden by the tooltipWhen writing a command that does not fit on one line of the terminal, the tooltip of the command (that prompts when writing `<arg>=`) hides the cursor.
Before typing `=`
![image](/uploads/0ffd9a12c92a69d19daf6c3d578876e4/image.png)
Af...When writing a command that does not fit on one line of the terminal, the tooltip of the command (that prompts when writing `<arg>=`) hides the cursor.
Before typing `=`
![image](/uploads/0ffd9a12c92a69d19daf6c3d578876e4/image.png)
After typing `=`
![image](/uploads/f239c7c0783cef31f916edaec27cb1db/image.png)https://gitlab.esrf.fr/bliss/bliss/-/issues/4263Please can we keep scan.get_data() ?2024-03-25T11:38:11+01:00Jonathan WrightPlease can we keep scan.get_data() ?So far as I can tell, scan.get_data still works and it is still documented (https://bliss.gitlab-pages.esrf.fr/bliss/2.0.x/scan_engine_scan.html#scan-data). But now it prints a message:
```
WARNING: Method Scan.get_data() is deprecated s...So far as I can tell, scan.get_data still works and it is still documented (https://bliss.gitlab-pages.esrf.fr/bliss/2.0.x/scan_engine_scan.html#scan-data). But now it prints a message:
```
WARNING: Method Scan.get_data() is deprecated since BLISS version 2.0.0. Use 'Scan.streams["channel_name"][:]' instead.
File "/users/opid11/bliss_scripts/nc_bliss.py", line 255, in raytrace
first_data = first_scan.get_data()
```
Can you please suppress the deprecated warning. Otherwise I have to change a lot of scripts:
```
opid11@lid11control:~/bliss_scripts$ git grep get_data | wc -l
365
```https://gitlab.esrf.fr/bliss/bliss/-/issues/4259added missing axes property for ACE controller2024-03-14T12:19:24+01:00Laurent Claustreadded missing axes property for ACE controllerthis controller creates SoftAxis but does not have an axes propertythis controller creates SoftAxis but does not have an axes propertyLaurent ClaustreLaurent Claustrehttps://gitlab.esrf.fr/bliss/bliss/-/issues/4258Scan sequence no longer holds information about the scans in the file2024-03-21T16:24:36+01:00Wout De NolfScan sequence no longer holds information about the scans in the fileIn Bliss 2.0 we have
```
pytest -x tests/nexus_writer/test_nxw_scansequence.py::test_nxw_scansequence
```
![image](/uploads/3785d8f0a1ac4bd24db2f1e10d4c79a2/image.png)
In Bliss 1.11 we had
```
pytest -x tests/nexus_writer/test_nxw_sc...In Bliss 2.0 we have
```
pytest -x tests/nexus_writer/test_nxw_scansequence.py::test_nxw_scansequence
```
![image](/uploads/3785d8f0a1ac4bd24db2f1e10d4c79a2/image.png)
In Bliss 1.11 we had
```
pytest -x tests/nexus_writer/test_nxw_scansequence.py::test_nxw_scangroup
```
![image](/uploads/5e2384ad57a1c13f90f8ddc428f989b8/image.png)
So since Bliss 2.0 there is not way to know which scans below the a sequence.Wout De NolfWout De Nolfhttps://gitlab.esrf.fr/bliss/bliss/-/issues/4257ctrl-c can leave axis in moving state2024-03-13T16:49:25+01:00Perceval Guillouctrl-c can leave axis in moving stateversion 2.0.xPerceval GuillouPerceval Guillouhttps://gitlab.esrf.fr/bliss/bliss/-/issues/4256ascan shell display points instead of steps2024-03-13T15:20:37+01:00Wout De Nolfascan shell display points instead of steps```python
DEMO_SESSION [4]: ascan(energy, 8.8, 9.6, 1599, 0.1, mu)
ascan: step elapsed energy ...```python
DEMO_SESSION [4]: ascan(energy, 8.8, 9.6, 1599, 0.1, mu)
ascan: step elapsed energy
1468/1600 11.697 s nan
```
1599 is the number of intervals (or steps) and 1600 is the number of points.
So maybe this would make it more clear?
```python
DEMO_SESSION [4]: ascan(energy, 8.8, 9.6, 1599, 0.1, mu)
ascan: points elapsed energy
1468/1600 11.697 s nan
```
This the code responsible
https://gitlab.esrf.fr/bliss/bliss/-/blob/master/bliss/shell/data/display.py#L726https://gitlab.esrf.fr/bliss/bliss/-/issues/4255test: There is still occurency of all_image_references in the base code2024-03-13T10:52:01+01:00Valentin Vallstest: There is still occurency of all_image_references in the base codeThis was dropped and replaced by blissdata.
So there is some clean up to do.This was dropped and replaced by blissdata.
So there is some clean up to do.version 2.1.0https://gitlab.esrf.fr/bliss/bliss/-/issues/4253"Axis not ready" error on icepap2024-03-27T18:38:37+01:00Lucio Martinelli"Axis not ready" error on icepapSince the update to Bliss 2.0 (and at the same time switch to a new (faster?) control PC and firmware upgrade on icepas....) we start observing on BM32 some non-systemetic errors during scans on motors controlled by icepaps. Error messag...Since the update to Bliss 2.0 (and at the same time switch to a new (faster?) control PC and firmware upgrade on icepas....) we start observing on BM32 some non-systemetic errors during scans on motors controlled by icepaps. Error message is :
"Cannot move axis 22: Axis is not ready (check http://wikiserv.esrf.fr/bliss/index.php/ICETIPS) command sent was: b'MOVE'".
We got a full debug log on an error, and it looks like the first status query (made with ?FSTATUS) after a MOVE command arrives before the state register on the master is set to moving. The motion is hence supposed as done, and if the next MOVE can eventually be sent when the axis is not yet ready.
From the log:
```
36,892 Icepap_d9e.Command DEBUG : write bytes=112 b'#MOVE GROUP 22 31342 28 -5 1 1006 2 -833 11 -1019 12 7624 13 7630 15 288082 16 740260 17 746065 5 42784 6 64851\n'
36,900 Icepap_d9e.Command DEBUG : readline bytes=7 b'MOVE OK'
36,901 Icepap_d9e.Command DEBUG : write bytes=12 b'?FSTATUS 22\n'
36,901 Icepap_d9e.Command DEBUG : write bytes=12 b'?FSTATUS 28\n'
.
.
.
36,902 Icepap_d9e.Command DEBUG : readline bytes=19 b'?FSTATUS 0x00A01203'
36,903 Icepap_d9e.Command DEBUG : readline bytes=19 b'?FSTATUS 0x00A00403'
....
```
The status code for axis 22 in the master register (0x00A01203) is still set as READY, so the motion is considered ad done and the status for this axis is not polled anymore, while the other axis (which are in MOVING state) do their job.
At the end of the previous movement a new MOVE is sent (in this case a backslash on some axis, including axis 22 which in reality is still moving) and we got the error:
```
45,392 Icepap_d9e.Command DEBUG : write bytes=36 b'#MOVE GROUP 22 31542 1 1056 5 41784\n'
45,396 Icepap_d9e.Command DEBUG : readline bytes=49 b'MOVE ERROR Cannot move axis 22: Axis is not ready'
45,397 Icepap_d9e.Command DEBUG : write bytes=12 b'STOP 22 1 5\n'
45,397 Icepap_d9e.Command DEBUG : write bytes=12 b'?FSTATUS 22\n'
45,397 Icepap_d9e.Command DEBUG : write bytes=11 b'?FSTATUS 1\n'
45,398 Icepap_d9e.Command DEBUG : write bytes=11 b'?FSTATUS 5\n'
45,431 Icepap_d9e.Command DEBUG : readline bytes=19 b'?FSTATUS 0x00A05403'
....
```
Note the status for axis 22 is 0x00A05403, so the axis were MOVING.
Would it be possible to force the synchronization of the master status registers after a MOVE command, or eventually use for the first query after the MOVE command ?STATUS instead of ?FSTATUS ?
If you need the full log file I can send it.Cyril GuilloudCyril Guilloudhttps://gitlab.esrf.fr/bliss/bliss/-/issues/4252blissshell: Drop script fetching fg and bg color2024-03-25T15:13:12+01:00Valentin Vallsblissshell: Drop script fetching fg and bg colorThis can be done inside prompt toolkit instead.
https://gitlab.esrf.fr/-/snippets/327This can be done inside prompt toolkit instead.
https://gitlab.esrf.fr/-/snippets/327version 2.1.0Valentin VallsValentin Vallshttps://gitlab.esrf.fr/bliss/bliss/-/issues/4249blissdata: h5py-like API question2024-03-12T09:05:40+01:00Marius Reteganblissdata: h5py-like API questionCurrently, there are two APIs, one static and the other dynamic. What API should I use to build an application for both online (during acquisition) and offline data analysis? The dynamic one enters a continuous waiting loop, so I can't u...Currently, there are two APIs, one static and the other dynamic. What API should I use to build an application for both online (during acquisition) and offline data analysis? The dynamic one enters a continuous waiting loop, so I can't use it to read HDF5 from the disk.
@felix @denolf