Cross-Collaboration PLC code development feasibility

[mike.shinoda]

Hi All,

I wanted some feedback/thoughts on code implementation or development across several offices. What has been your collaborative experience been like?

I am concerned about it impacting efficiency and creating misunderstandings. But, I plan to mitigate using DevOps tools like Git Hub Version Control. Simply creating a standard procedure to follow seems insufficient.

Any other suggestions?

 

[mk42]

One important question is what brand PLCs you're working with. Just AB? Some Siemens? Beckhoff 4 eva? Little bit of everything?

Some brands have PLC projects that don't work well with git style version control. Some do. Some don't work well normally, but they have features to improve the situation. What might be a best practice in one platform is a terrible idea in another, and just sub-optimal in a third.

 

[mike.shinoda]

Right now the PLC is Siemens. Eventually I will have to mimic it in AB as well.
However, the offices are global, PLCs used will vary greatly if projects end up coming from multiple regions.

I was following the thread below and scoping out ***** as a possible option.
https://www.plctalk.net/qanda/showthread.php?t=123604&page=2

Usually the approach is to just leave everything to the local office but that hinders resource allocation. I haven't been in the PLC world long enough to know if that is the practical reality or something can done about it.

 

[James Mcquade]

what i have done is as follows.

gather all programmers together, sit down and discuss ideas.
for me personally.
in the main routine
define an always on and always off contact.
have a power up timer, once done, start allowing the logic to function.
inputs
have a section dedicated for inputs and assign internal bits for them.
this way, if an input type needs to be changed or reassigned, you have only
1 place to do it
outputs
do the same as inputs
one shots
define an array for one shots. a consecutive set of words
debug bits
define a set of words like one shots.
i have seen where programmers use their initials and a set of words.
for me, its jm.debug[x].y x it the word and y is the bit
subroutines
define a routine for each part of the machine
name each subroutine to identify what it is.

establish these parameters and have everyone adhere to them.
this will change as other ideas or requirements arise.
hope this helps,
james

 

[mk42]

Right now the PLC is Siemens. Eventually I will have to mimic it in AB as well.
However, the offices are global, PLCs used will vary greatly if projects end up coming from multiple regions.

I was following the thread below and scoping out ***** as a possible option.
https://www.plctalk.net/qanda/showthread.php?t=123604&page=2

Usually the approach is to just leave everything to the local office but that hinders resource allocation. I haven't been in the PLC world long enough to know if that is the practical reality or something can done about it.

I think they're probably the main cross platform machine builder focused solution out there right now. I think Auvesy-MDT is more end user focused.


In Siemensland, with newer versions of Portal, they have 2 relevant solutions out now. They have something called a Project Server where the projects can be stored remotely, and then users check in changes. It doesn't give you network by network comparisons of what changed, but it does at least tell you which objects changed in each check in. HW changes are a little rougher to make than SW changes, but it can support PLC & HMI. The other solution is the Version Control Interface, which allows you to easily import/export PLC code in a text based format, and includes plugins for things like Git.

Something coming down the pipeline from Siemens is Simatic AX, which allows you to do your PLC programming completely text based in VS Code, which then gives you full traditional IT style code management capabilities.


They also have Test Suite as an option for TIA, which allows you to do unit tests as well as run style guide checks.


These are all technical controls, you still need administrative guidelines like style guides, common libraries, etc, to help ensure code familiarity between engineers.

 

[mike.shinoda]

what i have done is as follows.

gather all programmers together, sit down and discuss ideas.
for me personally.
in the main routine
define an always on and always off contact.
have a power up timer, once done, start allowing the logic to function.
inputs
have a section dedicated for inputs and assign internal bits for them.
this way, if an input type needs to be changed or reassigned, you have only
1 place to do it
outputs
do the same as inputs
one shots
define an array for one shots. a consecutive set of words
debug bits
define a set of words like one shots.
i have seen where programmers use their initials and a set of words.
for me, its jm.debug[x].y x it the word and y is the bit
subroutines
define a routine for each part of the machine
name each subroutine to identify what it is.

establish these parameters and have everyone adhere to them.
this will change as other ideas or requirements arise.
hope this helps,
james

I plan to propose something similar as the standard code layout or as best practices.
But, I don't know if there any possibility of code quality audit etc. Most of the programmers are across different time-zones compounding this challenge.

 

[mike.shinoda]

I think they're probably the main cross platform machine builder focused solution out there right now. I think Auvesy-MDT is more end user focused.


In Siemensland, with newer versions of Portal, they have 2 relevant solutions out now. They have something called a Project Server where the projects can be stored remotely, and then users check in changes. It doesn't give you network by network comparisons of what changed, but it does at least tell you which objects changed in each check in. HW changes are a little rougher to make than SW changes, but it can support PLC & HMI. The other solution is the Version Control Interface, which allows you to easily import/export PLC code in a text based format, and includes plugins for things like Git.

Something coming down the pipeline from Siemens is Simatic AX, which allows you to do your PLC programming completely text based in VS Code, which then gives you full traditional IT style code management capabilities.


They also have Test Suite as an option for TIA, which allows you to do unit tests as well as run style guide checks.


These are all technical controls, you still need administrative guidelines like style guides, common libraries, etc, to help ensure code familiarity between engineers.

Thanks! These are great points. I will have to discuss them internally and gather feedback.

The main conundrum is everything is siloed currently. With new acquisitions it's a challenge to break old practices or facilitate code familiarity. Very little incentive to change and oversight structure is limited.