What all does Enable Communication to I/O unit do?
I have a customer with ethernet PACs over radio links (high latency, lots of dropped packets) that refuse to get past that command for long periods of time (sometimes days). I can ping and access via PAC Terminal and PAC Manager and the I/O Unit ready command succeeds.
Its a single command that does all the configuration on the I/O unit.
Sets the PUC (Power Up Clear), sets the temperature units of degrees C or F, configures any watchdogs, sets the scan time for each I/O unit, configure all I/O channels and PIDs.
The software engineer and my self are trying to figure how this can take so long. Its a simple command that should complete on the I/O unit within a second.
We suspect that the observed delay is not so much the result of the command itself, but the subsequent I/O unit and strategy getting back in sync after the PUC.
Not sure if its possible, but the engineer would love to see a wireshark capture of before, during and a few minutes after the command.
If you can do this, open a ticket with support and get the ball rolling.
Thanks for looking into this - much appreciated.
I’ll see if I can setup a test strategy on SoftPAC to easily get a packet capture - hopefully it will exhibit the same behavior as an R1.
The remote device is an R1 running a strategy. It is configured as a generic MMP device in the local strategy just to read the scratchpad. Not sure if that changes what the Enable Communication does. It will sit at that command and timeout after 30 seconds or whatever it is set to on the timeout/retries. Eventually the stars align and it finally enables and there no more communication issues until the strategy is restarted/downloaded.
To get around the connection issue, I am testing sending/receiving OptoMMP commands directly using a comm handle which has been working fine so far, but more difficult to work with.