Project

General

Profile

Bug #12058

R42 is having a problem with new DPM

Added by Richard Neswold over 3 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
03/24/2016
Due date:
% Done:

0%

Estimated time:
Duration:

Description

Ming Jen reported (via Jim Smedinghoff):

How to reproduce:

- Go to page R42
- Select "2 8 Gev beam in RR"
- In the upper left box, labeled "Acquiring data", click on "*Frame". With new DPM, errors will be reported in the Messages window.

BPMUTI: Error reading TBT data from BPM R:VP337 ! DPM_BAD_FRAMING
BPMUTI: Error reading TBT data from BPM R:HP338 ! DPM_BAD_FRAMING

History

#1 Updated by Richard Neswold over 3 years ago

I looked into where new DPM returns DPM_BAD_FRAMING. This is the only test that triggers that error:

(Offset rem AtomicSize) /= 0 orelse (Length rem AtomicSize) /= 0

This looks like a valid test (both the length and offset have to be multiples of the atomic size.) R:VP337 is an array device made up of two floating point numbers. I can access all three subsets of the array from a D80 dump through a new DPM without problem. Since the reading fails, I can't pull anymore information from the DPM (if it was active, I could see the length/offset parameters.) I asked Ming Jen to see how he's asking for the data.

#2 Updated by Richard Neswold over 3 years ago

I instrumented the test DPM and ran R42 against it. The validation code is getting an offset of 512, a length of 6236, and an atomic size of 6236. 512 is not a multiple of 6236, so the code is correct. Why are these parameters being used, however? Is this a non-linear device? If so, the database entry needs to be corrected. The front-end is owned by John Diamond, so I'm adding him to the list of watchers for this issue.

#3 Updated by Richard Neswold over 3 years ago

  • Status changed from Assigned to Closed

The error message in the application was misleading. The errors were due to R:TFV337 and R:TFH338. Marking them "non-linear" fixes the problem. Ming-Jen needs to verify this.

#4 Updated by Richard Neswold over 3 years ago

  • Status changed from Closed to Feedback

I'm re-opening this issue until I get feedback from Ming-Jen. The two devices that I fixed are only used in one configuration of R42. Ming-Jen is going to test other set-ups to see if there's still lingering issues.

#5 Updated by Richard Neswold over 3 years ago

  • Status changed from Feedback to Assigned
  • Assignee changed from Richard Neswold to Brian Hendricks

From Ming-Jen:

This problem, in fact, is not about R42 but rather the database devices that it reads. We have 208 flash TBT devices and another 208 user TBT devices, and their associated intensity devices, all need to be marked. Given that Recycler system is a clone of Main Injector there are another (208 + 208) x2 also need to be marked [using non-linear addressing].

I'm reassigning this issue to Brian Hendricks, since he knows which devices his BPM library accesses and so he'd know which devices need to be marked with non-linear addressing.

#6 Updated by Brian Hendricks over 3 years ago

  • Status changed from Assigned to Resolved

I have marked the appropriate Main Injector and Recycler BPM devices as nonlinear.

#7 Updated by Richard Neswold over 3 years ago

  • Status changed from Resolved to Closed

Marking it "Closed" actually removes it from the open issues list. What is the difference between "Closed" and "Resolved" anyways? :D



Also available in: Atom PDF