The15thwiseone
Member
Hello all,
I recently got a new job working as a controls technician. I have been doing it for 3 months, coming up on 4 now, and the company was adamant about me putting out code rapidly with copy and pasting, and in Allen Bradley using the explort import function.
I have thus far been able to perform my duties well enough that most programs for these simple machines are very easy for me to pick up and wrap my mind around. Started off bumpy but once I got to sequential logic IÂ’ve been zooming through these things. The issue is , I guess; my documentation. I am eagerly looking forward to learning new things and moving from SLC 500 series and omoron plcs to studio 5000 and beyond (adding them to my belt of knowledge).
I wrote a keycard reading program for a SLC 500 and that was what my company was trying to make for the customer for a while…., do you document even development/test code outside of “for test , do not ship with device”? Not meaning to “flout” myself but the last guy apparently failed stupendously at the task.
Outside of naming clearly bits what they are doing, ie “drill forward input” and structuring the rungs in such a way that they make sense to all programmers, and labeling/commenting rungs is there anything that is “universal” standard?
Basically to dummy proof the logic so that programmers of every level can look at it and know what it is doing? That was their primary criticism they had of me.
Thank you for your advice!
I recently got a new job working as a controls technician. I have been doing it for 3 months, coming up on 4 now, and the company was adamant about me putting out code rapidly with copy and pasting, and in Allen Bradley using the explort import function.
I have thus far been able to perform my duties well enough that most programs for these simple machines are very easy for me to pick up and wrap my mind around. Started off bumpy but once I got to sequential logic IÂ’ve been zooming through these things. The issue is , I guess; my documentation. I am eagerly looking forward to learning new things and moving from SLC 500 series and omoron plcs to studio 5000 and beyond (adding them to my belt of knowledge).
I wrote a keycard reading program for a SLC 500 and that was what my company was trying to make for the customer for a while…., do you document even development/test code outside of “for test , do not ship with device”? Not meaning to “flout” myself but the last guy apparently failed stupendously at the task.
Outside of naming clearly bits what they are doing, ie “drill forward input” and structuring the rungs in such a way that they make sense to all programmers, and labeling/commenting rungs is there anything that is “universal” standard?
Basically to dummy proof the logic so that programmers of every level can look at it and know what it is doing? That was their primary criticism they had of me.
Thank you for your advice!