[INSTRM-154] Monitoring two ionpumps simultaneously causes timeout Created: 17/Jul/17  Updated: 09/Jan/19  Resolved: 09/Jan/19

Status: Won't Fix
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: arnaud.lefur Assignee: cloomis
Resolution: Won't Fix Votes: 0
Labels: SM1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Epic Link: Blue channel perf Test

 Description   

For the first time, we have started the ionpumps on both cryostats.

  • xcu_r1 
    port = 4001
busid = 1
pumpids = 3,4
  • xcu_r0 
    port = 4001
busid = 2
pumpids = 1,2

It appears that asking for ionpump status when the bus is already busy causes timeout.
To solve this problem, we have started monitoring with a shift of few seconds, it seems okay so far.

It's just a reminder, that's not critical.

 Comments   
Comment by cloomis [ 20/Jul/17 ]

INSTRM-74, INSTRM-80, and INSTRM-81 boiled down so the controller and the bus being fragile, so this is no surprise. I should have thought about the fact that in the end there will be three actors talking to the bus.

The individual commands from the actors come on individual TCP sessions to the MOXA. Not sure if that makes things better or worse.

One possibility is to pull out a "private" ionpumpActor, which handles all communication to that bus. All normal commands and responses would still be through the xcuActors, so the current API would not change.

Alternately, if an actor is too heavyweight we could make a tiny serializing program, and have the actors connect to that. I think I prefer this solution. If we can gain by being clever about chunking commands in the xcuActor, it could just keep a connection open.

Comment by hassan [ 09/Jan/19 ]

Following discussions with cloomis, this issue has been fixed by one of the dependent issues listed.

Generated at Sat Feb 10 16:22:06 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.