I've been code-bashing on the RTU955 via remote connections via RMS.
I keep getting premature ejection on both SSH and Https sessions.
First I thought it was because I neglected to change the default duration when creating the remote access link
it looks like the default is only about 20 min.
After that I set it for several days in length....
However that did not in any way change the summary-execution timeline...
and even that was bizarre because when I got killed, the browser's SSH process still came up with
login: and password: prompts - even though the connection was dead.
So then I kill that session and discover that the whole link, which (I think) still had the several-days-ahead expiry date on it
was also dead...
I had to keep recreating, from scratch, new remote access links which all kept summarily committing suicide out from under my work.
Definitely some brain damage going on there...
Also, when setting up the remote access profile, at first I had only an HTTP connection, I added an SSH connection but it appeared as a second HTTP connectoid. I edited that connectoid and changed the port and the name, such that it appeared to be a valid SSH connectoid, but it was still an HTTPS connection. I had to delete it and re-create a new SSH connectoid.
Just seems flaky and shaky - non-robust. I didn't observe this instability while connected directly with ethernet, inside my 7-layer faraday cage laboratory ;-) (not really)
I was trying to config the modbus connection stuff, and test them, but that seemed to be a lost cause.
Sometimes when configuring new modbus connectoids, the name of the connection was retained, but other parameters just got ditched
It isn't clear whether the Save down below Alarms applied to the connectoids too - since they didn't have a save...
Anyway, eventually, after repeated poking I got a rudimentary setup - but the testing function was hopeless... spinning/connecting.............
but no results. When the white-screen-of-death overlay appears, the session is screwed.
It seems like browser Back and Refresh are often terminal to the session - need to exit out and recreate a whole new connection link.
Back really should be trapped and not be allowed to terminate the session. I never want to go "Back" to RMS... I expect to have to kill the current session to go back to RMS - not have it mysteriously die because I want to get out of a timeout-induced white-spinner-screen
or just refresh the current screen...
We are looking forward to the remote-management capabilities, but things feel pretty sketchy...
At this point the RTU955 is connected to a fast wifi connection and I'm connecting via a fast wired connection.
I imagine when the signals devolve to Cell connections in remote locations, and we're trying to tweak things via cell login to RMS things are likely to get even less robust. It will have to be space-mission level careful, calculated, meticulous, methodical, patient, careful tweaking
