One of the newer AS setups create the folder
C:\BRAutomation
while the older versions created a folder
C:\BrAutomation
Not sure when it started, but AS 4.12 creates it in the new format for sure.
We backup all of our project with 7-Zip (described there) to preserve the project with all its time stamps to prevent a re-compile when it gets transfered between machines.
If you install an old version at first and then later AS 4.12, it keeps the old name as it was and all works fine.
But if you install AS 4.12 first, then you run into the issue that it re-compiles your full project since it thinks the path has changed.
It took us quite a while to figure out why it re-compiles on some laptops/PCs and on some not.
We never found out what exactly (folders/Registry keys) need to get renamed, so we had to completely uninstall all AS versions and re-install them starting with a low version.
In my opinion is this a bug, it should not be case sensitive since the Windows file system isn’t. If that is a gcc compiler thing which B&R can’t change easily, then the name of the folder never should have got changed.
just my 2 cents: The default path can always be changed - and if known, maybe you should agree to a default within your organisation. For example since the very first time I used AS, I never installed it in the default path - C:\ is not the place for a program to be in (!) and I think(but I might be misremembering) AS6 also changes the default to C:\Program Files (x86)
No need to install older versions just for the path to be “correct” is the tl;dr
I would be careful about this statement, especially for older versions of AS. In the past, there were, if Im not mistaken, some issues reported regarding minor functionality of AS if the default installation folder C:\BRAutomation was changed to a different path.
For sure, this is not a problem for AS4.12 and AS6, which are installed in C:\Program Files (x86) per default
Making my statement more specific: For all of my own usecases and starting with AS 3.0.90, the installation path of C:\Program Files\BRAutomation worked for me
Right, I also did install some older AS versions into C:\Programm Files, but in the end we decided to follow all hte B&R standard of
C:\BrAutomation
to have all the same environmen, but that has now obviously for some reason changed to
C:\BRAutomation
which causes now problems.
But to change the installation path is a good hint, it probably help to install AS 4.12 to
C:\BrAutomation
if it is the first AS setup on a PC to prevent these problems.
I also can remember comments like this from the B&R support, that was also a reason why we changed to the B&R default path.
I just did. I propose that community managers forward matters bugs to the support or development if reported here (maybe there is an option to flag a post for the support to check).
I would even like to have the option to handle support cases here, if the do not contain sensitive information, means to get answers from the support here, maybe by mentioning them. Discourse is a handy platform for conversations, so why not have the option to use it for support cases/communication as well?
Take care, AS 4.12.6 requires a complete removal of the AS 4.12.5 version and it re-installs everything into C:\Program Files\BRAutomation4 for some reason (there is no option anymore in the setup to chose another path) which causes a re-compile of all of my projects.
Why got the path changed?
In my opinion the installation path should not get changed within the same minor releases.
Independed from that, C:\Program Files is meant for 64-bit software installations, C:\Program Files (x86) is meant for 32-bit software which AS actually is.
Not sure why it ended up in there in general.
Looking at this screenshot, just taken from a fresh start of the 4.12.6 setup, it gives me at least the choice until I actually reach the install button - which I of course won’t click since I already have the 4.12.7 SP installed and use AS 6.1 currently.
I have my 4.12 installation in “C:\Program Files\BrAutomation”, just like I always had (disclaimer: path existed already due to lower versions being installed as well)
The community managers (me included) are not a replacement for the proper support channels. We are here to moderate the forum posts, other than that, any help we give or other interaction is not in that role but simply the same as any other user.
The community is a “user help users” way of connecting, not a replacement for the proper support channels, as outlined above. A few of the support personel also do share their knowledge on here, but just like that: as users.
If you chose C:\BrAutomation\AS412
as install path in the setup, then the installation ends up in C:\BrAutomation\AS412\AS412,
means you have to chose C:\BrAutomation,
which was not clearly to see in the setup process and caused me to re-install everything again.
However, even if AS 4.12.6 gets installed in the same path as AS 4.12.5, it causes a re-compile of my AS projects, which is a no-go for us when we just update a minor version to receive the latest bug-fixes.
To check “transfer only relevant changes” did not work, it still tried to download all tasks. Independend from that does it not look like a clean solution to me if it shows then permanently changes in the project.
while I get the point of not wanting rebuilds due to the time they might take, they don’t hurt either. Why AS chose to perform one or not is not up to us unfortunately and obviously there is not much you can do about it, it seems.
I am unsure if this thread will lead to any conclusion you will be happy with, to be honest.
It started with the path change - which I could show you could be changed and has now drifted to rebuilds after minor version changes - which I can’t check right now but might have been a thing forever? (and, speaking as a user, after a version change (even if minor) I pretty much expect such a thing, I’d be (positively) wondering if it didn’t happen)
That’s not the problem.
We have operational plants in production to maintain and we can’t transfer easily all tasks and do PLC reboots just to adapt small software changes.
With a re-compile we also can’t confirm that we have the latest project version available for the plant PLC before we apply changes to it.
We never experienced re-compiles when we just installed minor updates (I call it minor when AS x.x stays the same, maybe I should call it patch, its naming is not clear since AS does not use semver).
The point is, a re-build is a no-go for us and it looks is just caused by setup/installer issues where and how AS gets installed.
the installation path change from C:\BrAutomation to C:\BRAutomation causes just problems with no benefits
a project recompile should not happen just because the installation path of the AS is different to the last build (different computers could have different installation paths)
the installation default path should not change within a minor/patch update
We usually stay for a long time with an AS version and we only need bugfixes for it without any project rebuilds.
