No way to get raw bytes for .EGU and similar fields

Open
#19 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
python
Domain
api

Research direction

Start with the caget entry point and its datatype=DBR_CHAR_BYTES handling, then reproduce the shown .EGU conversion failure. The issue is done when raw bytes can be retrieved for .EGU and similar fields without the reported conversion error.

Written by the indexing model from the issue text.

Description

This is related to issue #18: after the fix applied there we get:

>>> caget ('LI-RF-AMPL-01:KLY:T1.EGU')
'�C'

as expected, but invoking datatype=DBR_CHAR_BYTES fails thus:

>>> caget ('LI-RF-AMPL-01:KLY:T1.EGU', datatype=DBR_CHAR_BYTES)
...
cothread.catools.ca_nothing: LI-RF-AMPL-01:KLY:T1.EGU: No reasonable data conversion between client and server types

What is going on here is that DBR_CHAR_BYTES retrieves the underlying PV as a DBR_CHAR array, and we rely on the IOC automatically converting strings (type DBR_STRING) to character arrays. Unfortunately it seems that the IOC doesn't do this for .EGU, and possibly other fields.

Dominant language
C
Stars
13
Forks
11
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DiamondLightSource/cothread

All issues in DiamondLightSource/cothread

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.