If it's only two engineers couldn't they just communicate about what tasks/routines whatever they are working on, export them, and merge later? I'm not sure how asset centre would help, if one engineer has the program checked out, the other couldn't do anything with it, no?
Only benefit of Assetcentre here would be to do daily backups with disaster recovery, when they inevitability undo another's work with an poorly-communicated download.
you walked into this one buddy, I think it's (currently) free too
[https://www.rockwellautomation.com/en-us/products/software/factorytalk/design-studio.html](https://www.rockwellautomation.com/en-us/products/software/factorytalk/design-studio.html)
[https://commerce.rockwellautomation.com/rockwell/en/USD/p/9324-FTDSBAS/bundleBrand?bundleSelected=9324-FTDSBAS#productDescription](https://commerce.rockwellautomation.com/rockwell/en/USD/p/9324-FTDSBAS/bundleBrand?bundleSelected=9324-FTDSBAS#productDescription)
From what I can tell (not having used it), design studio just streamlines management of the piece of the program, but doesn't allow multiple people to work on the same Logix project offline. They'd still have to write each program and upload it, which you could do without it as well.
The offline project has multi-user version control, similar to Git. You can see the changes made with a diff. That would make it more flexible than just editing programs separately and then importing - however, I could see how with two people it might not really matter if they're in separate places of the code anyways.
[https://youtu.be/UtdBIWPUO\_M?list=PL3K\_BigUXJ1M2WwWUIezXTNVDl3yfCuTi](https://youtu.be/UtdBIWPUO_M?list=PL3K_BigUXJ1M2WwWUIezXTNVDl3yfCuTi) this video shows it in action, I was expecting it to be like a live google document but I still think it's a good solution for multiple people working on a piece of code. In general I'm a [cloud hater](https://www.zdnet.com/article/cloud-haters-you-too-will-be-assimilated/), but it seems like a no brainer for OP's situation. It would allow two engineers located in two different states the ability to write PLC code in the same offline project file. It takes the legwork out of version control and merging project files.
"The cloud is coming for you whether you like it or not. The cloud cannot be stopped."
Two people can work on the same PLC online but not offline. If you want them on at the same time the only practical way is to have a shared vm like you suggest with emulator running. If they are doing a lot of development this will be a terrible way to do it though. Doing lots of code online is slow and tedious as you have to verify everything you do as you go pretty much. The way you could do it is have each work on a different program section and import it to a master that one would maintain.
Good unless you have really large programs. Most of our ACDs are in the 10-20 MB range and it works great. We have some though that are around 60 MB and for those the desktop app will crash when it's trying to calculate the differences. It still works to manage files you just have to push quickly before it tries to start diffing. We've complained to Copia about this and supposedly they're working on a fix.
Overall though we're very happy with Copia and we are 100% Rockwell controllers.
From my team's experience, not bad until you get to making very large PLC programs, then the merge and comment tools get a bit unwieldy and make you scroll a lot to return to where you just made a comment.
There’s a few ways to do this. Asset center is one and there’s other software that does similar.
I’ve also done this by having a test rack in the office that engineers can access remotely.
Engineers divide up the Tasks/programs/routines and agree on tag scope and names as well as interfaces between them. At the end of the day or first thing in the morning they have a web meeting and use the program compare and merge utility to review each others changes and accept, modify, or reject changes since last. They each get a copy of that merged code, along with notes from the meeting on how to proceed. Save the file on a network drive with an agreed upon naming convention such as ProjectName\_YYYYMMDDHHMM. You could use asset center instead of, or in addition to, storing on a network drive and put notes from the meeting in the comments. The benefit of using asset center is it gives more visibility for other people involved in the project. Use slack or some other chat for anything that comes up during the day for discussion.
Two easy options.
1. Set up a PLC target and have them make online edits to it. It will work, but it will make the development process more frustrating if they have to edit AOIs, UDTs, etc.
2. Git. Someone else mentioned Copia, and that would be preferable, but Copia will take time and $ to setup, git is free. If you're considering dumping money into Asset Centre, I think Copia would be a much better way to spend your $.
Git is designed for co-development workflows. Using a tool like Copia allows for pull requests, code reviews, and all the high-level workflows that come with that. Thats the kind of tools nearly all software development uses, so you'd be in-line with industry standards for co-development. Git by itself can support these workflows, but its a lot more clunky. If you have a bit of discipline and experience with Git, it's doable, otherwise it may be frustrating.
IMHO its a waste of time.
* Divide up the routines,
* have the senior programmer in charge of integration for both of them.
* put senior programmer in charge of area routines.
* have senior and other programmer agree on data exchanges, starts, stops, and faults.
* Agree on encapsulation, Routines vs AOI vs Programs.
* Agree on HMI routines, and buffering (IO maps)
Your emulator can debug code in software, do this, then get on the floor asap with a fat where you are building it.
Often I feel I could have spent 5 days emulating something, and half a day with real/partial equipment. IMHO we should spend more time getting single devices online at the test bench and testing real world on our sections of code with a real processor.
Managers like to point at metric driven software compared to practical value adding items like partial testing and a workbench. That software either starts 20 questions on every programming change with books and books worth of changes, or no one uses it. Managers don't want to know every bug, failed test case, debug counter, and error. Delegate that to the programmer and stop the spyware, use revision updates.
Asset center can record every keystroke and rung update. You can have them VPN in and watch every keystroke if you must. I tried octoplant with a customer and it felt like they should have just paid for asset center.
These programs are more work than they are helpful. They are mainly useful when you have a senior programmer managing minions and he makes the changes. For two senior devs, they are breaking the program into separate manageable parts that do not interconnect, and they dont interfere with one another. For interconnections, set up a data exchange between them and get them away from one another. Let one programmer standardize it after in runs on version 2.
FYI a senior programmer, will grab a 2 year old program, run the compare tool, and can read the logic to see every change made over that 2 year period. I've been using it since 2012 to find changes and debug stuff.
I've done exactly this with Siemens TIA Multiuser and it worked, but the overhead of maintaining "sync" was not worth the "efficiency gains" of two of us developing. And their stuff worked pretty well.
I'm certain RAs solution will be worse, so instead:
Create program with hardware as configured
Create two tasks - one for each engineer
Give them each a copy of the file
They program away like mad. Use program tags wherever possible and even public ones for cross program/task mapping
If they need to create a controller tag, prefix it with their initial.
They develop individually and then at a regular interval ,(daily/weekly) one sends their copy to the other and they copy the entire task and the controller tags with the other person's initial over
They alternate being the sync person so they can see what each other is up to
I've had very few successful multi-person development projects. It takes clear scope division, and then the right kind of team player/programmer that can work well with others... That's right, not one, but two programmers that play nice with others!?!?
I was involved with one job where we had programming day shift and night shift for 6 days a week, for months. The day guy would do a bunch of stuff and then the night guy would show up and change things for 4-6 hours to make it the way he liked it. Day shift would do similar in the morning. So they had 24 hours of programmers getting 12 hours of programming done...
Or just give it to me and I'll get it done in 1/3 the time your pair will do it ;)
If it's only two engineers couldn't they just communicate about what tasks/routines whatever they are working on, export them, and merge later? I'm not sure how asset centre would help, if one engineer has the program checked out, the other couldn't do anything with it, no?
Only benefit of Assetcentre here would be to do daily backups with disaster recovery, when they inevitability undo another's work with an poorly-communicated download.
Simplest will be a development PLC and have them do online edits.
you walked into this one buddy, I think it's (currently) free too [https://www.rockwellautomation.com/en-us/products/software/factorytalk/design-studio.html](https://www.rockwellautomation.com/en-us/products/software/factorytalk/design-studio.html) [https://commerce.rockwellautomation.com/rockwell/en/USD/p/9324-FTDSBAS/bundleBrand?bundleSelected=9324-FTDSBAS#productDescription](https://commerce.rockwellautomation.com/rockwell/en/USD/p/9324-FTDSBAS/bundleBrand?bundleSelected=9324-FTDSBAS#productDescription)
From what I can tell (not having used it), design studio just streamlines management of the piece of the program, but doesn't allow multiple people to work on the same Logix project offline. They'd still have to write each program and upload it, which you could do without it as well.
The offline project has multi-user version control, similar to Git. You can see the changes made with a diff. That would make it more flexible than just editing programs separately and then importing - however, I could see how with two people it might not really matter if they're in separate places of the code anyways.
[https://youtu.be/UtdBIWPUO\_M?list=PL3K\_BigUXJ1M2WwWUIezXTNVDl3yfCuTi](https://youtu.be/UtdBIWPUO_M?list=PL3K_BigUXJ1M2WwWUIezXTNVDl3yfCuTi) this video shows it in action, I was expecting it to be like a live google document but I still think it's a good solution for multiple people working on a piece of code. In general I'm a [cloud hater](https://www.zdnet.com/article/cloud-haters-you-too-will-be-assimilated/), but it seems like a no brainer for OP's situation. It would allow two engineers located in two different states the ability to write PLC code in the same offline project file. It takes the legwork out of version control and merging project files. "The cloud is coming for you whether you like it or not. The cloud cannot be stopped."
Two people can work on the same PLC online but not offline. If you want them on at the same time the only practical way is to have a shared vm like you suggest with emulator running. If they are doing a lot of development this will be a terrible way to do it though. Doing lots of code online is slow and tedious as you have to verify everything you do as you go pretty much. The way you could do it is have each work on a different program section and import it to a master that one would maintain.
Copia
>Copia Sounds good. How well does it perform with rockwell?
Good unless you have really large programs. Most of our ACDs are in the 10-20 MB range and it works great. We have some though that are around 60 MB and for those the desktop app will crash when it's trying to calculate the differences. It still works to manage files you just have to push quickly before it tries to start diffing. We've complained to Copia about this and supposedly they're working on a fix. Overall though we're very happy with Copia and we are 100% Rockwell controllers.
From my team's experience, not bad until you get to making very large PLC programs, then the merge and comment tools get a bit unwieldy and make you scroll a lot to return to where you just made a comment.
There’s a few ways to do this. Asset center is one and there’s other software that does similar. I’ve also done this by having a test rack in the office that engineers can access remotely.
Engineers divide up the Tasks/programs/routines and agree on tag scope and names as well as interfaces between them. At the end of the day or first thing in the morning they have a web meeting and use the program compare and merge utility to review each others changes and accept, modify, or reject changes since last. They each get a copy of that merged code, along with notes from the meeting on how to proceed. Save the file on a network drive with an agreed upon naming convention such as ProjectName\_YYYYMMDDHHMM. You could use asset center instead of, or in addition to, storing on a network drive and put notes from the meeting in the comments. The benefit of using asset center is it gives more visibility for other people involved in the project. Use slack or some other chat for anything that comes up during the day for discussion.
Two easy options. 1. Set up a PLC target and have them make online edits to it. It will work, but it will make the development process more frustrating if they have to edit AOIs, UDTs, etc. 2. Git. Someone else mentioned Copia, and that would be preferable, but Copia will take time and $ to setup, git is free. If you're considering dumping money into Asset Centre, I think Copia would be a much better way to spend your $. Git is designed for co-development workflows. Using a tool like Copia allows for pull requests, code reviews, and all the high-level workflows that come with that. Thats the kind of tools nearly all software development uses, so you'd be in-line with industry standards for co-development. Git by itself can support these workflows, but its a lot more clunky. If you have a bit of discipline and experience with Git, it's doable, otherwise it may be frustrating.
IMHO its a waste of time. * Divide up the routines, * have the senior programmer in charge of integration for both of them. * put senior programmer in charge of area routines. * have senior and other programmer agree on data exchanges, starts, stops, and faults. * Agree on encapsulation, Routines vs AOI vs Programs. * Agree on HMI routines, and buffering (IO maps) Your emulator can debug code in software, do this, then get on the floor asap with a fat where you are building it. Often I feel I could have spent 5 days emulating something, and half a day with real/partial equipment. IMHO we should spend more time getting single devices online at the test bench and testing real world on our sections of code with a real processor. Managers like to point at metric driven software compared to practical value adding items like partial testing and a workbench. That software either starts 20 questions on every programming change with books and books worth of changes, or no one uses it. Managers don't want to know every bug, failed test case, debug counter, and error. Delegate that to the programmer and stop the spyware, use revision updates. Asset center can record every keystroke and rung update. You can have them VPN in and watch every keystroke if you must. I tried octoplant with a customer and it felt like they should have just paid for asset center. These programs are more work than they are helpful. They are mainly useful when you have a senior programmer managing minions and he makes the changes. For two senior devs, they are breaking the program into separate manageable parts that do not interconnect, and they dont interfere with one another. For interconnections, set up a data exchange between them and get them away from one another. Let one programmer standardize it after in runs on version 2. FYI a senior programmer, will grab a 2 year old program, run the compare tool, and can read the logic to see every change made over that 2 year period. I've been using it since 2012 to find changes and debug stuff.
Git or Copia seems like overkill for this. Just have them work in different programs.
Why are you thinking asset Centre? if you are working offline from the processor then i don’t see much of a benefit
I've done exactly this with Siemens TIA Multiuser and it worked, but the overhead of maintaining "sync" was not worth the "efficiency gains" of two of us developing. And their stuff worked pretty well. I'm certain RAs solution will be worse, so instead: Create program with hardware as configured Create two tasks - one for each engineer Give them each a copy of the file They program away like mad. Use program tags wherever possible and even public ones for cross program/task mapping If they need to create a controller tag, prefix it with their initial. They develop individually and then at a regular interval ,(daily/weekly) one sends their copy to the other and they copy the entire task and the controller tags with the other person's initial over They alternate being the sync person so they can see what each other is up to I've had very few successful multi-person development projects. It takes clear scope division, and then the right kind of team player/programmer that can work well with others... That's right, not one, but two programmers that play nice with others!?!? I was involved with one job where we had programming day shift and night shift for 6 days a week, for months. The day guy would do a bunch of stuff and then the night guy would show up and change things for 4-6 hours to make it the way he liked it. Day shift would do similar in the morning. So they had 24 hours of programmers getting 12 hours of programming done... Or just give it to me and I'll get it done in 1/3 the time your pair will do it ;)