einnh said:I realize this is slightly off-topic...
einnh,
I would not say you are off topic at all. Any feedback from users as to which software currently works with which Operating System is very pertinent to readers trying to gauge whether similar software will likely work OK with Windows 10 or not. Especially references to Windows 8, as it is the predecessor to Windows 10.
The important thing to remember in all of this is the word "officially".
Where Rockwell have officially tested a specific piece of Rockwell software, against a specific edition of a Windows Operating System, and it performed at an acceptable level, then they will officially say that it is "Compatible" with that edition of that OS.
Where Rockwell have officially tested a specific piece of Rockwell software, against a specific edition of a Windows Operating System, and it has performed at an acceptable level, but with some issues or exceptions, then they will officially say that it "May be Compatible" with that edition of that OS, or they might say it is "Compatible" but with exception(s).
Where Rockwell have officially tested a specific piece of Rockwell software, against a specific edition of a Windows Operating System, and it has not performed at an acceptable level, for whatever reason, then they will officially say that it is "Not Compatible" with that edition of that OS.
Where Rockwell have not officially tested a specific piece of Rockwell software, against a specific edition of a Windows Operating System, and they unofficially know it performs at an acceptable level, or they have no evidence to the contrary, then they will officially say that there are "No known issues or dependencies" with that edition of that OS.
For whatever reasons, when they have officially tested and found incompatibility issues for a specific software environment, they will not officially support the use of that specific software environment. These reasons are usually due to a serious enough performance related issue to warrant not supporting it. It does not necessarily mean the software will not install, load up and operate, but more that there is a particular software feature that does not work, or the software crashes under certain circumstances, or when used with certain other third party software products within that environment, etc.
As I said, official compatibility is not a hard and fast rule. Operating System environments can differ from user to user, system to system. Where Rockwell have not performed official testing, then it is user feedback, such as yours rdrast, that will really provide the compatibility results, especially for the somewhat older versions of software that Rockwell are most likely not going to perform official testing against the latest OS.
In the main, they are just covering their bases, I guess. If a user contacts them saying their software is crashing, or the like, and they have not officially rubber stamped that particular software environment, then in most cases they will advise the user to implement virtualization with an older compatible OS.
A little ramble...
Rockwell have no real control over Operating Systems and their architecture, which Windows develops, no more than they have control over the processing hardware upon which they are run, of which Intel and the like develops.
The computer software and hardware market moves along at a pace far greater than the automation world does. The environment in which our automation products and applications are run and maintained is ever evolving. New Operating Systems tend to be biennial, or thereabouts. They are much aligned with the cadence of newer processor chips or enhancements which have long been predicted to occur every 2 years, according to Moore's Law. In more recent years, the average major chip or enhancement release had been around every 18 months, according to Intel, with this having slowed to around every 2-2.5 years since around 2012.
Major computer hardware and peripheral developments and releases tend to be somewhat slower. But when they happen, they can create huge headaches for automation product developers and manufacturers. I would mention the serial port once again, or lack of, as a major shift in the computing world which forced many in the automation world to redesign much of their newer hardware to compensate or keep up. Another example would be if the computing world, at some point in the future, develops a successor to the expectedly long term Ethernet standard. This would pose another huge headache for automation product developers and manufacturers. It is really out of their hands.
Realistically, automation software developers cannot be expected to rewrite older versions of software and firmware to support each successively new Operating System and processor architecture. In this regard, virtualization has really been their saviour in all of this.
My point being that as they have no direct control over the ever changing environment in which their software products must be used, then they must always be playing catch-up to try and reach or exceed the current computing standards. Whether previous or existing software products will work or not in these new and unchartered waters, will be highly variable from user to user, and so it tends to be a case of "suck it and see" a lot of the time. It is these interim periods of uncertainty, such as this thread has highlighted, in which we tend to feel somewhat unsure about the future of our past, but currently invaluable, software products.
Automation has always been driven by the need to make things easier to do, yet the methods used to do those same things easier are driven by the need to conform to current technological standards, which is not always so easy to do.
In short, in this line of work we often have to put a lot in to get a little out. It is our pains that yield their reward.
"All honest industry has a reward, and all care and pain borne for a good object bring comfort and content."
The money is just a bonus, right?
Regards,
George
Last edited: