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.
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/
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!