Discuss method of showing moxa ports and their COM mappings to scientists

[rerpha]

So many of our support calls are scientists asking what COM ports map to which moxas etc. - we should make a perspective/web page or something helpful and obvious to show this.

Some ideas;
macros for moxa IPs and COM start numbers are stored in globals.txt, served by INSTETC and then shown on a perspective/help page/somewhere very obvious to the scientists - we should say on this page to go and check the moxa IP on the front panel to see whether it matches whats in the GUI.
ie. MOXA1=x.x.x.x
MOXA2=y.y.y.y

and therefore COM ports 5-21 are on moxa 1, which has IP x.x.x.x,
COM22-38 are moxa 2, which has ip y.y.y.y
this needs to be obvious when setting up IOCs, so a web page may be better

we may have something in the user manual already, but clearly the scientists are not finding it/its too generic and doesnt say where COM ports start.

Acceptance criteria

• A short discussion is had on how to do this
• A ticket is created to do the work with implementation details on.

[rerpha]

this could be added on to the home page/landing view if we are doing that too #7403

[rerpha]

Right, here is my idea, but we need to discuss this so will organise something.

In globals.txt INSTETC loads in MOXAXX__NAME, MOXAXX_IPADDR and MOXAXX_STARTNUM for each Moxa where XX is the moxa number and STARTNUM is the first COM port the moxa maps to. This is then served by INSTETC or similar as PVs then we either use an OPI or a webpage (json_bourne?) to show the list of IPs. if it's stored in globals.txt it's not config specific and is also stored in version control.

For displaying the mapping we should use a perspective as this is very obvious to the user/scientist, however we may need to also show it when someone hits help in the edit component/configuration "edit IOC" dialogue as well as that's where COM ports etc. are most useful.

(apologies for rubbish quality mockup - hope it conveys the rough idea though)

We need to discuss these edge cases (and maybe others?):

• Moxa port nums - do we always have 16 ports on a Moxa or are there any models in use which use less?
• Contiguous ports - Is every moxa port contiguous everywhere?
  • So long as they are contiguous, they can have any start number

And need to discuss whether adding this to the web dashboard might be more accessible/futureproof than just INSTETC with an OPI to display it, in which case json_bourne will need to be modified as will ARINST if possible.
Personally I think modifying the web dashboard to show it would make most sense as
A) the perspective only has to display a web page
B) a user can hit the help icon in the "edit ioc" page and get taken to the web page

I think this ticket should only cover permanent Moxas, not the floating models which go around with temporary sample env equipment.

[FreddieAkeroyd]

It would be nice not to have to duplicate moxa details in globals.txt. Moxa names and IP info can be obtained from the windows registry at
HKLM\\SYSTEM\\CurrentControlSet\\Services\\npdrv\\Parameters\\Server and it may be possible to get other info from the registry too, or query the moxa web page, or use the moxa cli tool etc.

[FreddieAkeroyd]

actually just noticed it has a COMNO array under server in registry listing the com port number for each moxa port. I have some python code to read the registry that builds the moxa details for http://beamlog.nd.rl.ac.uk/inst_summary.xml that migth be useful as a basis

[rerpha]

ok, i think that solves both edge cases as well.

[rerpha]

right, just confirmed we can get all we need from the registry ie.

import winreg as wrg
import socket

location = wrg.HKEY_LOCAL_MACHINE

params = wrg.OpenKeyEx(location,r"SYSTEM\\CurrentControlSet\\Services\\npdrv\\Parameters")
server_count = wrg.QueryValueEx(params, "Servers")[0]

for server_num in range(1, server_count+1):
    soft = wrg.OpenKeyEx(location,f"SYSTEM\\CurrentControlSet\\Services\\npdrv\\Parameters\\Server{server_num}")
    ip_addr_bytes = wrg.QueryValueEx(soft,"IPAddress")[0].to_bytes(4)
    ip_addr = ".".join([str(int(x)) for x in ip_addr_bytes])
    hostname = socket.gethostbyaddr(ip_addr)[0]
    print(f"IP {ip_addr} hostname {hostname}")
    start_num_com = 1
    com_nums = enumerate(wrg.QueryValueEx(soft,"COMNO")[0], 1)
    for count, value in com_nums: 
        print(f"physical port {count} COM number {value}")

Gives us the IP, host, physical port->COM mapping, which i think is perfect

edit: sorry freddie, this is probably the same as your inst_summary.xml code

[rerpha]

one option we could do i suppose if wanting a web page is just run up a flask server from procserv with the above code and point a perspective in the client to it, though this means that it wont be accessible outside the ndx.

[FreddieAkeroyd]

I also seem to be checking 'SYSTEM\CurrentControlSet\Enum\ROOT\PORTS%04d\Device Parameters' % ( i ) if service is
"nptdrv2" so maybe there is more than one variety to consider

[FreddieAkeroyd]

We could build a static page same way an we do beamlog and then just refer to it from each ndx

[rerpha]

is that the newer nport "driver manager" rather than nport administrator?

[rerpha]

ok, might as well do that if the info is already there and COM mappings exist?

[FreddieAkeroyd]

question is now whether to do it centrally or on a per instrument basis. Doing it centrally makes it easier to refer to off instrument and means not running a web server per instrument, though doing on instrument we don't have to make a web page - a python script could make an OPI directly or some other table, csv or xml etc format that can be loaded by an opt - even a mysql database table. Doing on instrument would allow for private network moxas if we were to use them ever.

[rerpha]

Discussion had. To summarise:

• OPI view or similar to display mappings, with a button to force an update.

• Data will be served via channel access by instetc

• db server will poll registry when button is pressed and PV put to, then push values to local mysql instance and push to INSTETC

• OPI will also be visible in edit ioc dialogue by help button or similar.

Will create ticket for this later

[rerpha]

Discussion was had. Ticket is #7720

[KathrynBaker]

@rerpha the central aspect is missing from your notes and tickets
The other thing is the other ticket makes sense within the context of those of us who had the discussion, but anybody else (or ourselves after time) but I don't think there is enough detail to fulfil the above summary in it. Could you detail the sub tasks better please, e.g. split off a python script which will read the registry and post it to the SQL database when the trigger is seen from INSTETC getting that information and displaying it.

[FreddieAkeroyd]

Data will be served via channel access by instetc`
db server will poll registry when button is pressed and PV put to, then push values to local mysql instance and push to INSTETC

do we need INSTETC in the loop - doesn't db server already serve PV's as it is pcaspy?

regarding central aspect, we don't necessarily need it in a central mysql, what we wanted I believe was a central summary page independent of an instrument being up, which could be done by polling mysql on each instrument (a similar idea to http://beamlog.nd.rl.ac.uk/inst_summary.xml - it just polls and summarises information across instruments to build a static html page)

[rerpha]

we don't need INSTETC, sorry had put that on the new ticket already but not updated here.

ok - will add that to ticket

[davidkeymer]

Attended meeting, read ticket documenting resulting work.
Marking as reviewed and complete.