• Not Answered

Risk of Downloading a Redundant M-Series Serial I/O Card on a Running Process

I have need to download a redundant M-series serial I/O card while the process is still in operation and am wondering if the download will be bumpless. I would normally wait until the process is idle for a short period of time or down, but don't know if that will be an option in this case. I have found some references that suggest that it may NOT be bumpless, but wanted to see what experiences others have observed. Thanks!

3 Replies

  • It is difficult to guarantee that all downloads will be bumpless; it usually depends on many variables. Can you explain what you are downloading? For example, do you have current Modbus connections to several devices and want to add a new device, or are you wanting to bring more data from a current device, or are you adding a new device on the second port, which is currently not used? Are you using the programmable serial card? If so, what protocol are you using? In general, when downloading a serial card the status of the inputs will go bad, so if your configuration handles the status to not take action until the download is complete, you shouldn’t have any problems. When it comes to the output, a download will cause the database values to be written and if they are different than the online values, you will experience a bump in the outputs. I would suggest testing the download out on an offline system if you are concerned about bumping the process during the download.
  • There was once a redundancy testing app on one of the install DVD's, which will examine your configuration and flag any vulnerabilities. Bussed I/O used in interlocks or control schemes gets called out, so you can examine the affected modules for anything that is tied to the other datasets on the card.
    From another post, the application I found on DVD1 of the 14.3.1 install pack, under \Migration Utilities\Upgrade Wizard\, where you will find the help file ACRviewer.chm and the executable ACRUtil.exe.
    If your systems configuration folks were meticulous about "abort on read errors" or checking "<variable>.CST" before executing any code, you might be okay. Otherwise I would say your experience will be less than bumpless . . .
  • In reply to John Rezabek:

    Here is what I think happens on the download of the Serial card. First, there is only the option to download the entire card. All Datasets are downlaoded on both ports. The values of the data sets go to 0 with bad status. Then the devices are polled in order and the dataset values are pulled from the devices, including the OUTPUT values. This aligns the data in the IO card registers with the field devices and sets status to good.
    Output datasets can be enabled for readback, which includes these in the input polling. If not enabled, the Output dataset is only read on the first input scan to initialize the registers.

    The Status is key. If your modules have some tolerance for transient Bad Status conditions and do not take action on their outputs, then the download should be bumpless. However, if your modules see the initialized 0 with bad status and change the state of their outputs, this could result in the values sent to the devices to be changed.

    It is good practice to monitor status of registers and to delay a response to Bad Status, which could be a transient condition, as with a card download or a connection loss. The ultimate behavior will be based on how the control modules respond. If the Dataset values are used in Interlocks or other logic in other modules, the bad status should be taken into account there too. The Bad status caused by the download will persist until the Data set is polled successfully and the Serial card is able to update the controller IO map with the data. You should assume that modules will see the Bad status for one scan.

    Andre Dicaire