https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-154 Instrument control development <p>For the first time, we have started the ionpumps on both cryostats.</p> <ul> <li>xcu_r1 <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>port = 4001 busid = 1 pumpids = 3,4 </pre> </div></div></li> <li>xcu_r0 <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>port = 4001 busid = 2 pumpids = 1,2 </pre> </div></div></li> </ul> <p>It appears that asking for ionpump status when the bus is already busy causes timeout.<br/> To solve this problem, we have started monitoring with a shift of few seconds, it seems okay so far.</p> <p>It's just a reminder, that's not critical.</p> INSTRM-154

Monitoring two ionpumps simultaneously causes timeout

Bug Minor Won't Fix Won't Fix cloomis arnaud.lefur SM1 Mon, 17 Jul 2017 12:47:04 +0000 Tue, 8 Jan 2019 17:59:24 +0000 Tue, 8 Jan 2019 17:59:24 +0000 0 2 <p><a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-74" title="only one of the two ion pumps stop " class="issue-link" data-issue-key="INSTRM-74"><del>INSTRM-74</del></a>, <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-80" title="Ion pump start error: only one started" class="issue-link" data-issue-key="INSTRM-80"><del>INSTRM-80</del></a>, and <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-81" title="ion pump number 2 start is long and block other process" class="issue-link" data-issue-key="INSTRM-81"><del>INSTRM-81</del></a> 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. </p> <p>The individual commands from the actors come on individual TCP sessions to the MOXA. Not sure if that makes things better or worse.</p> <p>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.</p> <p>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.</p> <p>Following discussions with <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a>, this issue has been fixed by one of the dependent issues listed.</p> Development Epic Link INSTRM-513 Rank 0|ii02hz: