Request for tips and advice concerning best Practice use for Visilogic Software environment

[MarvinP]

Hello Visilogic Users,

I am currently trying to optimize the software for a new company where I am working for and would like to create a bassline for the structure and organization of the program. I would prefer to base this baseline on practices from other more experienced users since I am fairly new to the software environment. 

Most of the software has been added during the years by best practice by one or two employees. The software is currently bloated with features which are built on top of one another, where you need to find variables all around the program and naming conventions which don't have a definite structure. 
Now I would like to know from the community if there are other ways specific to Visilogic which makes sense considering to (re)order the program and to create a baseline from where you can work further and develop the software. 

Per Example:

One of my concerns is the description per variable and the visualization of that variable within the software. I tried to make something logical but noticed if I exceeded the name with a few too many letters the full name wouldn’t be readable. So my question is what do experienced users use for naming conventions so the name has clarity but is also readable from the software itself.

This is just an example but are there any other concerns which I can take with me or best practices from experienced Users which I can use when developing a new baseline or code for myself and future users of the program. I understand that most of it comes down to preference but if anyone has any tips for me or concerns to take into account it would be very much appreciated. 

Thank you for the help!

Kind Regards,

Marvin P.

 

[yyh2]

I asked a pretty similar question here -

And found zero resources on the subject.
PLC programming is a top secret subject, apparently.

[Flex727]

There is an entire forum here on this board dedicated to this question.

https://forum.unitronics.com/forum/61-best-programming-practices/

[John_R]

On 3/7/2024 at 3:27 AM, MarvinP said:

I am currently trying to optimize the software for a new company where I am working for and would like to create a bassline for the structure and organization of the program. I would prefer to base this baseline on practices from other more experienced users since I am fairly new to the software environment. 

MarvinP; Seems to me you are making assumptions about the PLC programming environment, this is not some structured thing that you can treat like some Excel/Access/Powerpoint program.

It entails understanding control logic, which is something you have to embellish from a real hands on type of structure, not spreadsheets and databases...

7 hours ago, yyh2 said:

And found zero resources on the subject.
PLC programming is a top secret subject, apparently.

yyh2, sorry, but no, this is not some  top secret subject, but it is something you have to learn and understand. Nobody can wave a magic wand over your head and give you all knowing  knowledge. You have to try (and yes fail from time to time), but if you first try (and that is the prerequisite), then ask questions, folks on this forum will gladly help you.

But, sorry Charlie, nobody is gonna hand you a Golden Ticket...

[MarvinP]

 

13 hours ago, Flex727 said:

There is an entire forum here on this board dedicated to this question.

https://forum.unitronics.com/forum/61-best-programming-practices/

Thank you for the link! I checked it out and it seemed to go deeper into smaller bits of best practices instead of creating a baseline from where to restructure my program. I can't really seem to find a answer to problems I currently am encountering, but I will post a question in this forum if this is more appropriate.

13 hours ago, yyh2 said:

I asked a pretty similar question here -

And found zero resources on the subject.
PLC programming is a top secret subject, apparently.

Something which helped me a little bit on the way was the following website, it provides additional infrmation about the control logic and best practices for structuring certain elements. I try to implement these structures for troubleshooting as I go on the way. : https://www.contactandcoil.com/

6 hours ago, John_R said:

MarvinP; Seems to me you are making assumptions about the PLC programming environment, this is not some structured thing that you can treat like some Excel/Access/Powerpoint program.

It entails understanding control logic, which is something you have to embellish from a real hands on type of structure, not spreadsheets and databases...

 

Hello John,

Thank you for the comment. I will try to provide a little bit more explanation in order to gain a better understanding of my situation. Form the way you phrased your post I have the idea that I might have some misunderstanding of what I am trying to achieve here with my question. My main goals is not to gain a better understanding of the logic of the individual programming of a PLC or how that the ladder code works. But to create something where a team could work on together which would make sense and make sure that the team could work on it without getting in each other’s hairs.

I currently am working on an existing program containing 15, routines, each with 6-8 subroutines. 8 HMI main pages with each more than 9 subpages per Page. This goes for 11 machines with different settings which also have several different slave PLC’s which they can communicate with.

The program contains more than a 1000 MB’s . MI’s etc. All in the program phrased like:

-          Central arm here

-          Enable encoder

-          test molding unit

Most of them have been built on top of one another, so the same rung uses MB1015 in conjunction with MB50 etc. etc. The result is that whenever I try to implement something it costs me so much time to first make an understanding of what is happening in the code and the machine before I can go on with the actual task I am doing.

The program has mostly been written by my supervisor. Which prior to me was the sole engineer of the company and tasked with improving the situation whilst simultaneously trying to keep all the machines running. He knows almost everything by heart and this system would have worked if it stayed just him.

The problem for me mainly is that the program needs to be organized in some regard or way which makes sense for me and future engineers to work on the program. One of my tasks is to create a  new baseline for us as a team to work further with.

So to better phrase what I am trying to accomplish. I am trying to rebuild an existing program so it can make sense for the both of us to work further on it and improve it without getting lost in too much organisation.

I know most of it comes down to do your research and search for something that works for the both of you. And just try trial and error. But It would be nice to get some tips specifically to the structure of Visilogic in order to make sense of things.

I tried to implement a new form of structure for a different machine we had. I gave everything shortcuts like REC_DATA_MATERIAL_STRUCTURE. Recipe datatable, material, structure of material per example. But then I could’t read some them and I was still searching beforehand. I also tried to take a look at PackML for some type of structure, but it wasn’t something my supervisor wanted. He preferred rewriting the existing structure and reorganising a bit.

I didn’t want to overexplain my first post but I hope this gives a better explanation of the problems I am currently facing. If you have no definite answer that is also alright and I appreciate your time. I also understand that you cannot really give me a finite answer since every program and machine is different. But taking a look at how a more experienced user would handle restructuring a program would be a great help.

 

Kind Regards!

[Flex727]

7 hours ago, MarvinP said:

21 hours ago, Flex727 said:

There is an entire forum here on this board dedicated to this question.

https://forum.unitronics.com/forum/61-best-programming-practices/

Thank you for the link! I checked it out and it seemed to go deeper into smaller bits of best practices instead of creating a baseline from where to restructure my program. I can't really seem to find a answer to problems I currently am encountering, but I will post a question in this forum if this is more appropriate.

I hope you caught this message:

 

[MarvinP]

 

25 minutes ago, Flex727 said:

I hope you caught this message:

 

I am afraid I missed this particular post. I Looked through it and it was very helpfull! Thank you for your response.

[sgull]

Hi Marvin

If there is a particular program you are having problems with then you should upload it.

Someone may be able to look at it and suggest better ways of structuring it.

There are many ways of achieving the the same result with PLC programming. It is not a case of right or wrong, but many things can be simplified with good habits.

 

[yyh2]

On 3/12/2024 at 1:48 AM, John_R said:

yyh2, sorry, but no, this is not some  top secret subject, but it is something you have to learn and understand. Nobody can wave a magic wand over your head and give you all knowing  knowledge. You have to try (and yes fail from time to time), but if you first try (and that is the prerequisite), then ask questions, folks on this forum will gladly help you.

But, sorry Charlie, nobody is gonna hand you a Golden Ticket...

Nobody asked for a magic wand...
just a well written  book about programming techniques.
its basic in every other field.
for example, you can find many books like it for the leading microcontroller platforms (Arduino,PI, etc...)

[Colin1976]

On 3/7/2024 at 11:27 AM, MarvinP said:

Hello Visilogic Users,

I am currently trying to optimize the software for a new company where I am working for and would like to create a bassline for the structure and organization of the program. I would prefer to base this baseline on practices from other more experienced users since I am fairly new to the software environment. 

Most of the software has been added during the years by best practice by one or two employees. The software is currently bloated with features which are built on top of one another, where you need to find variables all around the program and naming conventions which don't have a definite structure. 
Now I would like to know from the community if there are other ways specific to Visilogic which makes sense considering to (re)order the program and to create a baseline from where you can work further and develop the software. 

Per Example:

One of my concerns is the description per variable and the visualization of that variable within the software. I tried to make something logical but noticed if I exceeded the name with a few too many letters the full name wouldn’t be readable. So my question is what do experienced users use for naming conventions so the name has clarity but is also readable from the software itself.

This is just an example but are there any other concerns which I can take with me or best practices from experienced Users which I can use when developing a new baseline or code for myself and future users of the program. I understand that most of it comes down to preference but if anyone has any tips for me or concerns to take into account it would be very much appreciated.  And I almost forgot to mention, whoever faces similar questions, I advise you to read the article https://www.cogniteq.com/internet-things/consulting in which you will find how to redefine your operational processes, technological systems and increase income streams.

Thank you for the help!

Kind Regards,

Marvin P.

 

For variable naming, keeping names short but descriptive is key. Consider using abbreviations or acronyms that are commonly understood in your field. Ensuring consistency in your naming conventions will make the code more readable and maintainable. Breaking down your program into smaller, reusable modules can help reduce complexity and make the code easier to manage, with each module handling a specific task or set of related tasks.

Comprehensive documentation is essential. Include comments within your code to explain the purpose of variables and functions, and maintain an external document that outlines the overall structure of the program and key components. Group related variables together and use clear, logical names for variable groups, perhaps prefixing variable names with their type or usage, such as "int_" for integers, "str_" for strings, etc.

[Ausman]

Apart from the old printed (yes, printed manuals that formed the entire basis of learning in the old days) instruction manuals that come with various plcs I've used, there is a plethora of info on the web. Colin's post touching again on this subject, with good advice,  made me do a simple google on: PLC ladder programming basics.   

Multiple hits, some much better than others.  Most relate to the use of ladder in a particular maker.  However, there were also numerous hits to books.  Careful screening of reviews would ensure you get something that covers needs.

However, the main amount of learning comes from finding the basics and going from there through hands on experience. 

You can't expect to get a great new CAD program and use all of it's functions immediately without having to physically try it's particular ways of doing something, can you?  Same thing for a PLC, the often huge amount of things they can do takes time to learn how to correctly use that particular function.  They all follow the basic way of doing things, but they also handle the same sort of operations vastly differently in their ladder structure, particularly for more complex operations.  

If working with a variety of plcs, it can become a bit of a brain sieze shifting b/n them... 🤔 

cheers, Aus