Luke.S

Master-Slave Equipment Protocol

4 posts in this topic

When using an auxiliary piece of equipment or a retrofit on, for example, a production line, who's responsibility is it to define the I/O specification between them? The designer of the software in the slave equipment or the administrator of the software in the line master PLC?

I am programming a servo system which works in sync with a line. The only input I have to start and stop is an "auto_run" bit from the master. Because there are many possibilities regarding what the servos are doing at any one time and it's over an industrial network, I requested the "Stop," command to be a handshake format. I want to send an acknowledgement back to the master upon actual "zero speed," feedback from the drives. The response was that it is my responsibility to sort it out on my end.

I got it to work with just the "auto_run" bit falling edge but I feel like this is the not the most professional way to do it. What if the timing changes or the equipment gets reassigned to a different process in the future? Is it not normal that I require certain I/O to be in a specific format so I can make sure my code is robust? There seems to be a lack of commonly accepted best practice in the PLC field.

Share this post


Link to post
Share on other sites

Often times, nobody thinks of the handshaking signals between equipment until the programmer(s) get involved.  I learned quite quickly that the mechanical engineers or salespeople or the process engineers involved with the equipment will have SOME idea of what is needed, but it is the programmer who will know exactly what is needed.  After getting put into tight situations in the past, I learned to insert myself the process early and state my requirements for I/O and handshake info.  I would often have to plead my case when I first started out, but after proving myself , it is much easier now.  So, the response you got to "sort it out on your end" is quite normal.  What you would do to "sort it out" would be to develop a list of the signals you need and then determine how you will get them (order from machine vendor, outsource or just do it yourself).  If you are a programmer only, without resources to design and install the additional hardware, then you would need to find another source to add the necessary I/O.  Ultimately, the programmer may have to compensate for shortcomings in mechanical or process design, so it is best to be assertive when telling others what you need to make the project successful.

1 person likes this

Share this post


Link to post
Share on other sites

drforsythe, thank you for your reply.

I suppose I just have to learn from this experience (like with many other things I learnt are harder to change later) and try to get a tentative specification out early on. Even if I don't get any answers, it might get the ball rolling.

What makes things tricky for me here is that I'm younger than most of the people I'm working with on this so I have to watch how much I assert myself.

Share this post


Link to post
Share on other sites

If others think that you are requesting changes just to make your work easier, they won't care; it's your problem.

But I've found "Liability" can speak volumes.

If the implication(s) of not having whatever (the signals you need in this case) could bring a liability by endangering either people or even productivity, then stating, in writing
- is a CYA tactic
- sometimes moves those who are otherwise reluctant to allow changes

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now