RobotStudio event

Office workflow

Options
How would you handle more users working on the same projects?

I'm asking this because we can't figure out a simple and effective way to handle project sharing between 2 or more robot programmers in our office. What we want, is to be able to open each others projects on our own workstations, in case one person is not in the office, but work needs to be done on the project he's working on (preferably without having to use his PC without him in the office), and without having to pack and unpack everything constantly. We also have a system modules with various weld settings for ArcWeld PowerPac, that we regularily add entries to, but handling that in 2 different RobotStudio projects is not an easy task, and often causes confusion. Is there a way of handling this automatically?

Example:
If p1 (person1) unpacks and saves the project on our server, p2 is unable to open the same unpacked project, as the controller does not start. 

Is this not possible, without packing and unpacking multiple times a day?

Comments

  • BigApe
    Options
    The solution we came up with is a it wonky, but works. I'm baffled that there's no official way of handling this in RobotStudio.
    We're managing controller and station seperately, so we don't have to pack and unpack constantly.

    We created a master controller backup that sits on our server, that has all our required system modules, and the program modules we'll be creating in the future. Me and my coworkers will be transfering to- and from this controller when we create new robot programs, need to share stuff with eachother, or if we need to edit another persons code in a module. This controller is going to contain every single line of code we create.

    We have two ways of handling our stations/geometry used in a program:
    1. Go around the entire station, and export/import the geometry used as a library to a MasterGeometry folder on the server linked under 'Import Library'. If worker3 needs to edit the program that worker1 made, he'll transfer the program module from the MasterController, then go to the geometry library and import the geometry, attach it to the station, then proceede to edit what needs to be edited.
    2. Saving/opening the entire station, then transferring the needed program module from the MasterController.

    Pros of 1:
    • Have all geometry in an easy-to-access folder from inside RobotStudio, ready to be imported
    • Enables us to have personal master projects (copy of a default master with our initials on), so we don't have to have multiple instances of RobotStudio open in case we have to edit multiple modules at the same time
    • 'Official' solution to sharing geometry
    Cons of 1:
    • Have to attach imported geometry every time
    • Personal masters are gonna be crowded with programs eventually, need to implement an archive solution outside RobotStudio.

    Pros of 2:
    • Less preperation to start working on a module
    • Never gets crowded. 1 station = 1 module
    Cons of 2:
    • No personal masters. Will have to have multiple instances of RobotStudio open at the same time, if working on more than 1 module
    • Never gets crowded, but needs archival system outside RobotStudio from day 1
    • 'Make-do' solution. Takes longer to implement, as our initial tests showed us that the installation of Robotware has to be located on the server, and every station needs to refer to this install instead of the default local one on each machine. This is a 1 time thing initially, and if we ever update to a newer version of Robotware, we'll just install the new package on the server with the other versions.

    Is the fact that there's no good, official way of sharing RobotStudio content with others in the office, other than pack&go a conscious decision? It makes RobotStudio a horrible piece of software to use with more than 1 programmer in an office. 
  • EricH
    EricH
    edited October 2019
    Options
    Your goal is to work on the same program? What about storing/restoring backups into a version control? The whole workflow is a bit uncomfortable, but it's better than working on the same system/controller at the same time.
  • BigApe
    Options
    The goal isn't to work on the same program at the same time, but to have the ability to edit/finish a program one worker has made, by another worker on a different PC. In the case of a time sensitive case where worker1, who's in charge of programming the robot, gets sick, a coworker would need to be able to access his program and finish it. 

    We've found that using a master controller backup that everyone transfers to and from, in combination with saving geometry as a library to a shared folder on the server that everyone has access to, works quite well, even though it's a make-do solution.
  • EricH
    Options
    Ah ok, I understand. Seems to be the best solution for this issue.