[INSTRM-24] VIS CU Red 1 -- No turbo pump status anymore Created: 21/Nov/16  Updated: 18/May/17  Resolved: 21/Nov/16

Status: Done
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: fmadec Assignee: cloomis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

We lost the status of the turbo pump since the 2016/11/19 04:27

the cmd result of the xcu_r1 turbo status is:

12:51:59.483627 .hub 0 cmds d CmdIn="client.pfs","xcu_r1","turbo status"
12:51:59.484879 .hub 0 cmds d CmdQueued=4766873,1479732719.48,"client.pfs",54,"xcu_r1",426,"turbo status"
12:51:59.495176 client.pfs 54 xcu_r1 d text="sending '?V852\r'"
12:51:59.496299 client.pfs 54 xcu_r1 w text="failed to create connect or send to turbo: [Errno 111] Connection refused"
12:51:59.497489 client.pfs 54 xcu_r1 f text="command failed: error(111, 'Connection refused') at /home/pfs/anaconda/lib/python2.7/socket.py:228"
12:51:59.498529 .hub 0 cmds d CmdDone=4766873,"f"

12:58:59.675700 .hub 0 cmds d CmdIn="client.pfs","xcu_r1","status"
12:58:59.676937 .hub 0 cmds d CmdQueued=4767133,1479733139.67,"client.pfs",55,"xcu_r1",427,"status"
12:58:59.686857 client.pfs 55 xcu_r1 w text='pathetic version string: unknown'
12:58:59.687879 client.pfs 55 xcu_r1 i version="unknown"
12:58:59.689077 client.pfs 55 xcu_r1 i text=Present!
12:58:59.689966 client.pfs 55 xcu_r1 i text="monitors:

{String('turbo'): Int(15), String('roughGauge1'): Int(15), String('cooler'): Int(15), String('temps'): Int(15), String('gauge'): Int(15), String('gatevalve'): Int(60), String('ionpump'): Int(15)}

"
12:58:59.690994 client.pfs 55 xcu_r1 i text="config id=0x7f42e0733cb0 ['tron', 'xcu_r1', 'pcm', 'cooler', 'temps', 'turbo', 'rough1', 'roughGauge1', 'ionpump', 'logging']"
12:58:59.692134 client.pfs 55 xcu_r1 : controllers=turbo,roughGauge1,cooler,pcmUdp,temps,gatevalve,PCM,ionpump
12:58:59.693180 .hub 0 cmds d CmdDone=4767133,":"

 Comments   
Comment by cloomis [ 21/Nov/16 ]

There is a tcp-to-serial program (tcp_serial_redirect.py, launched at boot) running on the BEE which got killed because it was logging too much and filled up the disk. The logfile (/home/pfs-data/nohup.log) has been deleted and the program restarted.

In any case the entire mechanism is an engineering convenience which is no longer needed (it allowed running the entire actor on a machine other than the BEE). We can remove the program during the upgrade at the end of the week.

Comment by cloomis [ 21/Nov/16 ]

Hack fixed. Real problem to be removed.

Comment by arnaud.lefur [ 21/Nov/16 ]

In any case the entire mechanism is an engineering convenience which is no longer needed (it allowed running the entire actor on a machine other than the BEE). We can remove the program during the upgrade at the end of the week.

. I agree with that.
I've just power off and on the bee 10 minutes ago and restarted the actor.
Basically, I don't know if the problem was solved before, but if you say so I trust you .

Comment by arnaud.lefur [ 18/May/17 ]

In any case the entire mechanism is an engineering convenience which is no longer needed (it allowed running the entire actor on a machine other than the BEE). We can remove the program during the upgrade at the end of the week.

Does that was actually done ?
Because, when I started bee-r2, I wasn't able to communicate with the turbo, so I've looked on bee-r1 and I've seen that this tcp_serial_redirect.py was still running.

I did a python /home/pfs/tcp_serial_redirect.py -p /dev/ttyS2 -b 9600 -P 4001 and it worked, but was it suppose to work without doing that ?

Comment by cloomis [ 18/May/17 ]

There is one turbo per cryostat, so we still need a redirector running on each bee. Or did I misunderstand you?

Comment by arnaud.lefur [ 18/May/17 ]

Yes, maybe I wasn't clear.

If I understand well what you do with this script is basically what a moxa does : you can communicate with the turbo through a tcp connection with the bee ip and port 4001.
It allows you to communicate with the turbo within the pfs network and as a result you can run the xcuActor from anywhere, ( it's what we want to do for enuActor also).

But I though that it was only for engineering as you said

In any case the entire mechanism is an engineering convenience which is no longer needed


I assumed that you would remove this serial=>ethernet conversion and switch back to a direct serial connection for controlling the turbo on the bee.

Using this tcp_serial_redirect.py works well and is totally fine. But I just needed a clarification about your comment to understand if what we currently use is meant to kept or not.

Comment by cloomis [ 18/May/17 ]

Currently keep it, yes.

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