I'm a fan of both. I write most programs to be vertical when starting, however soon morphs into horizontal once I find code that I have already written being needed again. Each time that happens a new program is born.
The "Horizontal" programming style is considered the best practice in software development and programming in general. Keeping programs (sub-programs) small makes them easier to troubleshoot and understand. It also allows for much easier code re-use.
The One Robotics blog has some posts that do a great job of explaining why.
You may also be interested in reading general programming best practices such as:
Single Responsibility Principle
DRY (Don't Repeat Yourself)
You may also be interested in reading general programming best practices such as:
Single Responsibility Principle
DRY (Don't Repeat Yourself)
At least I'm not only one who is using program development patterns and principles for industrial robots and plc in automation.
Hard Question. If i knew i was the only one who would ever touch that code, i would do many short programs, good modular programming like i would on any other programming platform. Working with manufacturing technicians trying to read programs, fewer longer programs seems to be better and cause less issues.
Hard Question. If i knew i was the only one who would ever touch that code, i would do many short programs, good modular programming like i would on any other programming platform. Working with manufacturing technicians trying to read programs, fewer longer programs seems to be better and cause less issues.
I come across this same issue at work.
Often when I write a complicated horizontal program I will provide a flowchart so that it can be understood easily.
I3ooI3oo 
I'm impressed. That's really good
I do the same but in my mind
One thing that I would like to add and that I found useful. First of all I look on application and define what type of programming I prefer for this application to make this program easy for debug, has closed logical sections (operation with stations) and program must be scalable without needing to change a lot.
In example:
when cell was made for 1 specific type of part with specific fixture, nest, tool, robot operation is very clear and not required repeat operations to same station, then you might select vertical style. Integration time will be way smaller.
when cell was made for 1 part, but operation might change during the time (robotic pressbrake cell, robotic painting line, etc). Then you need to make decision in advance, do you want to do additional work in advance and make your cell be scalable so your next visit to this facility (1 year after or so) will save your time. Or you want to leave as it is and hope that production will not change and customer never call you back.
I saw programs that were made for injection molding machines by another integrator. Unfortunately, their program wasn't scalable and required a lot of time just to add another program.
Often when I write a complicated horizontal program I will provide a flowchart so that it can be understood easily.
Is this auto generated, or created manually?
Is this auto generated, or created manually?
It is manually created. While I write the robot process along with laser process, ultimately our field service department will be doing the install along with training the staff on how to use the system. Knowing that I task the FS department to create one based on printed copies of all the created TP Programs. This lets me know they truly understand the process and are capable of answering any questions that may arise during the install of the system.
Is this auto generated, or created manually?
I use draw.io for making flowcharts. It's free app. Especially it's important when you need to approve sequence with customer.
That one was created with Draw.IO
