Version compatibility

[Controls Guy]

How is DMD <-> PLC version compatibility going to work?

Obviously, PLC's will frequently if not always need revised firmware/OS to support new features, and flashing same typically wipes out the program, which is certainly understandable.

But, will later DMD versions be able to upload apps from old version PLC's?

That would certainly be desirable, because the alternative is to have to maintain all old versions of DMD so as to be able to upload/flash/[edit]/download.

AB went this way on the ControlLogix (having to have multiple versions installed), which has been alleviated to some extent, or at least made less manual (not sure how they actually implemented multiple-version compatibility under the hood, but it's more seamless than it used to be), and it's always been a big pain.

[franji1]

Generally speaking, here are the rules:

First, remember that firmware upgrades and Designer programming software are FREE.  However, that doesn't mean that you MUST upgrade (we understand not every system needs/should/can be upgraded, but I am just pointing out that this is different than some vendors who require an exchange of $$$ for the opportunity to get their bug fixes, er, upgrades).

Second, Designer will always be able to upload OLDER projects from the PLC.  As long as you don't add any "features" to the project that are incompatible with the OLDER PLC's firmware, you should be able to DOWNLOAD the project to the OLDER PLC.  If you attempt to ADD a NEWER feature to an OLDER uploaded project, Designer will WARN you, and DOWNLOADING will be DISALLOWED.

Third, if for whatever reason you MUST maintain 1.0 projects and 1.1 projects and 1.2 projects and... (e.g. FDA requirements, system integrator w/multiple customers/projects, etc.), Designer 1.1 installs "side by side" Designer 1.0 in two different installation folders, two different .INI files, two different project folders, two different icons, etc.  So you can maintain version consistency across all your projects and PLCs if necessary.

Hence, the only planned limitation is that OLDER Designer versions may not be able to understand/upload projects in NEWER PLCs (e.g. a 1.1 instruction in a 1.1 PLC can not be understood by Designer 1.0).  However, NEWER Designer versions should always be able to upload projects from older PLCs and with enough care, should be able to download to older PLCs (see the previous caveat).

Lastly, to help differentiate FEATURE SET/SPECIFICATION VERSION from the software and firmware versions, we have defined the term "Do-more Technology Version" to define THE CONTROLLER'S FEATURE SET.  So, this latest version of Designer and firmware support Do-more Technology Version 1.1 (the initial release last fall was 1.0).  The Do-more Technology Version may or may not be bumped with each subsequent Designer release or subsequent firmware release, although the SOFTWARE and FIRMWARE versions WILL be bumped.

For example, the next version of Designer, 1.2, is planned to NOT bump the Do-more Technology Version (1.1), because we are not planning on adding any new PLC FEATURES.  The firmware version may need to be bumped to handle any "anomalies", but that will not cause a bump to the Do-more Technology Version (1.1).

The Updates.pdf file goes into a little more detail about the Do-more Technology Version.

[Controls Guy]

Second, Designer will always be able to upload OLDER projects from the PLC.  As long as you don't add any "features" to the project that are incompatible with the OLDER PLC's firmware, you should be able to DOWNLOAD the project to the OLDER PLC.  If you attempt to ADD a NEWER feature to an OLDER uploaded project, Designer will WARN you, and DOWNLOADING will be DISALLOWED.

OK, that's about what I envisioned as the optimum solution.

Third, if for whatever reason you MUST maintain 1.0 projects and 1.1 projects and 1.2 projects and... (e.g. FDA requirements, system integrator w/multiple customers/projects, etc.), Designer 1.1 installs "side by side" Designer 1.0 in two different installation folders, two different .INI files, two different project folders, two different icons, etc.  So you can maintain version consistency across all your projects and PLCs if necessary.

I suspect developers who don't foresee this need may occasionally run into it.  For example, say an integrator normally doesn't encounter that situation and customarily deletes old versions.  (Or someone who doesn't typically use Do-More is revising a program in such a scenario.)  So I think (and you guys are probably way ahead of me on this) you'll want to have downloads of old versions continue to be available.  Not sure, but this might require a slightly modified installer for version 1.0 for example, so it doesn't overwrite relevant v1.1 settings.  (Or a user config setting "vX.y compatibility mode" that will not just warn, but affirmatively limit changes to the specified DM Tech level.

So if we DON'T plan to keep multiple versions, what's the best procedure to delete the old one?  Just Windows' Remove Programs?

[franji1]

Not sure, but this might require a slightly modified installer for version 1.0 for example, so it doesn't overwrite relevant v1.1 settings.  (Or a user config setting "vX.y compatibility mode" that will not just warn, but affirmatively limit changes to the specified DM Tech level.

Version 1.0 is a different installation program, different install folder, different settings, different icon, etc.  1.1 install will migrate your 1.0 settings across, but you manipulate them independently.  We stuck the version number in the title bar of the main application window so it will be obvious (note 1.0 does NOT have the version in the title bar, but it will be the only one that doesn't).

So if we DON'T plan to keep multiple versions, what's the best procedure to delete the old one?  Just Windows' Remove Programs?

Yes.  However, any 1.0 project files will be left behind in the old directory structure, just in case you need to "migrate" them to the new version.

[Controls Guy]

Version 1.0 is a different installation program, different install folder, different settings, different icon, etc.  1.1 install will migrate your 1.0 settings across, but you manipulate them independently.  We stuck the version number in the title bar of the main application window so it will be obvious (note 1.0 does NOT have the version in the title bar, but it will be the only one that doesn't).

So I take it that all versions will continue to be available for download?

Yes.  However, any 1.0 project files will be left behind in the old directory structure, just in case you need to "migrate" them to the new version.

That shouldn't be a problem.  I never really got the idea of keeping data files with their app.  I (like I suspect most people do) keep all files associated with a project together in subdirectories of a directory for that project.  Doing it the other way is like keeping every document you write in a directory under \Program Files\Office\Word, which I can't imagine anyone doing.  Yet for some reason, most apps assume you organize your files that way.  Strange.

[franji1]

So I take it that all versions will continue to be available for download?

We will need to do this, but yes, they will be made available.

[Controls Guy]

Perfect -- thanks!  

(It sounds like just having the latest version will address 99.99% of cases, since it can both upload from older version PLC's and also open and edit older version programs without automatically stamping them as newer version DM Tech and thus incompatible with the old PLC they've been in.  The very few cases where you may need more than that, the old version is available for download anyway.)

[franji1]

ADC's Do-more Designer download page has a link at the bottom to the "previous version"
http://support.automationdirect.com/products/domore.html