Designed to Run or Run to Design?...
dmargineau said:
...I don't remember once in hundreds of developed applications having the need of using it; 99% of the time, the Development network topology does not match the Runtime one; who develops an application patched directly within the HMI's functional, runtime networking?
That may be your experience, but I would not imagine it being the same for everyone. I, contrastingly, and quite similar to Ken, have developed countless applications where I specifically connected my workstation to the intended Runtime controller using the intended driver under the Design (Local) tab. This method not only allows me to use the Test Application feature via the intended driver, but also serves to test the driver in advance of copying across to the Runtime (Target) tab. Also, by browsing, or drilling down to the intended Runtime controller, using the intended driver under the Design tab, potentially convoluted paths will be automatically predefined for you. Something you may normally have to manually configure under the Runtime tab.
Creating your intended driver under the Design tab, testing it, and then copying it to the Runtime tab, is specifically why the Copy feature exists.
In advance of going to Runtime it is not always possible to use this method during application development. This can be dependant on the driver involved and the availability of the hardware. But when it is available I do try to use it for reasons mentioned.
When users either accidentally copy the Design driver configuration over, or do so with the understanding that it's the correct thing to do, they often do not realize that the Copy feature is only to be used when the intended Runtime driver configuration exists, exclusively and validly, under the Design (Local) tab. Any driver configuration other than this will potentially be invalid under the Runtime tab i.e. is not supported at Runtime on the currently configured terminal for the application.
The extra "baggage" that often gets copied over is usually as a result of previous communications endeavours under the Design tab that were not removed before proceeding to develop the current application.
The key points for users to remember are...
1. Configure only the intended Runtime driver under the Design tab when pretesting during development
2. Everything that may be configured under the Design (Local) tab may not be supported under the Runtime (Target) tab
3. Everything configured under the Runtime (Target) tab will represent the RSLinx Enterprise Server that runs on the terminal, if the terminal is configured to use the application's driver setup
4. The RSLinx Enterprise Server that runs on the terminal will only support the drivers for the communication ports available to the terminal
I would agree that the tabular format for the Communications Setup is far from perfect and that it has never been easy to understand all its nuances. But once you get to know your way around it, it does do its job adequately, in my experience.
118608 - FactoryTalk View Machine Edition validation ERROR: Unsupported driver detected. Driver name = 'RSLinx Server'
Access Level: TechConnect
The newer Ethernet only terminals create this issue because they do not support any driver other than the Ethernet driver. The presence of the virtual backplane driver under the Design tab, which of course is not supported under the Runtime tab, automatically rules out the ability to use the Copy feature. If your gripe is solely based on this fact, and how they did not foresee it or since correct it, then I am 100% in agreeance with you. But I cannot agree that the Copy feature itself is useless and should be completely removed just to solve this issue. I would be more in favour of a patch to the software which would allow it to default the Communications Setup to the required base drivers for the terminal currently selected for the application. Or, at the very least, warn a user that the current configuration is not compatible with the selected terminal, while attempting to validate the Communications Setup.
Regards,
George
