I’m using Automation Studio 6.7.0.187 project in Git without Binaries and Temp.
I have one big problem.
Situation: developer A transfers the project to the machine. Developer B checks out the same commit on another PC, or the same PC after a Rebuild All, or a service technician opens it a year later. The build regenerates every module with a new build stamp, even though the sources are identical. On transfer, AS compares stamps, not content, so every task and library is “changed” and the whole application is downloaded. Since ashwd, asfw, arconfig and sysconf are also “changed”, the transfer list ends with a warm restart of the CPU.
So a one-line change in one task stops the whole line, only because the person doing it is not the one who did the last download.
What we tried: the “Transfer only if object doesn’t exist on target” flag on the four system modules removes the restart, but not the full download, and it silently skips real hardware changes. Versioning Binaries and Temp does not help, since Git does not restore timestamps and the build rebuilds everything anyway. Archiving the complete project folder after every download works, but on a large industrial line with different people over years it is not a realistic rule.
Questions:
Is there a supported way to make the transfer comparison content based, or to make builds reproducible?
Is there a documented B&R workflow for teams using Git that avoids this?
If not, can this become a feature request for Automation Studio 6?
I believe at my last job we got this to work in 4.x with temps versioned, the “transfer only if…” turned on, but then also making sure the build paths were the same. I.e. C:\Projects\… If the paths weren’t the same, then the temps didn’t ‘match’ where they were previously built so the system thought there were changes.
i think you are looking for the option of “Transfer only if relevant changes have been made” that can be found under “Transfer” in the Configuration Settings (Project → Change Runtime Versions)
This causes the comparison on the target to be content based. This change is applied directly on the Automation Studio side as the comparision happens between the old “Binaries” and “Temp” files. This also means that the Binaries and Temp need to be present for this comparision.
This will still lead to the project being compiled but will prevent a restart just because one line of code was changed. I hope this helps.
The “Transfer only if relevant changes” option has been enabled in this project since the beginning, and the reboot still happens from a fresh checkout. I built the same sources twice from scratch in two folders and compared the modules: sysconf, arconfig, ashwd, iomap and asfw differ only in the header timestamp and checksum, so their content is identical.
But 11 of our IEC tasks and libraries differ over a whole compressed section, so a content check can never match them. Also, the check seems to compare against the previous local Binaries, which a fresh checkout does not have.
Two questions for B&R:
Does the target also perform a content check, and if so why is the warm restart still requested for content-identical system modules? And can the build be made reproducible, so that identical sources compiled in a different folder produce identical modules?
i have checked with our B&R experts and have revised my previous answer.
The content is being compared on the PC/AS side and not on the PLC. This means for the “Transfer only…” option to work you will need the “Binaries” and “Temp” folders to be checked out/in as well as the new made files during compile get compared to the old files. No old files means that it assumes that its a new build and everything needs to be downloaded.
Sorry for the previously wrong information. I hope this clears this up.
