Need advice for sending/receiving commands though PLC

opmal7

Member
Join Date
Dec 2014
Location
Moline
Posts
35
Hi everyone, not a native PLC programmer here, just an engineer trying to make the thing work.

I have a sensor that I'm working with that communicates over RS-232. However, due to limited number of inputs in the PLC, I'm using a communication device (RTA Automation's 435NBX) to send/receive the communications from the sensor. Basically it converts the RS-232 message to a string and writes it to a string variable in the PLC. I have a string variable ST1 for incoming messages (from the sensor) and another variable ST2 for outgoing messages (to the sensor).

I have to send a few commands to the sensor to set it up for measuring, i.e. 'mode 1' (response: ok), 'calc method 1' (repsonse: "ok"). Then I send a command "measure" and the sensor responds back "measuring" then "calculating" and then "idle" once the measurement is completed. Once complete, I send a "read" command and it tells me the number that I want to display to the user.

My question is how to approach this from a programming standpoint. Is there a common method used for sending/receiving a series of commands? The only data I want to display on the HMI is the final number, but I feel that I need to make sure the sensor comes back with the "ok" response before sending the next command. I think I can use a bunch of compare, and move commands but that kind of seems cumbersome and I'm just wondering if there is a more straightforward method.

Thanks!
 
I have a sensor that I'm working with that communicates over RS-232.

RS232 is the physical layer of the sensor's implemented communications; there is a communications protocol running on the serial communications electrical connection and this is the relevant information you will need to provide us with (is it ASCII?).

The PLC controller (which's type you haven't posted either) will need to be capable to implement the sensor's native communications protocol and also have an available RS232 physical interface.

Please provide us with a little more info about your system.
 
Last edited:
RS232 is the physical layer of the sensor's implemented communications; there is a communications protocol running on the serial communications electrical connection and this is the relevant information you will need to provide us with (is it ASCII?).

The PLC controller (which's type you haven't posted either) will need to be capable to implement the sensor's native communications protocol and also have an available RS232 physical interface.

Please provide us with a little more info about your system.

Sorry, yes the communication is in ASCII. I'm using a Mircrologix 1100 PLC, and RSLogix Micro for programming.
 
However, due to limited number of inputs in the PLC, I'm using a communication device (RTA Automation's 435NBX) to send/receive the communications from the sensor.

I/O count is not relevant with regard to the implemented CPU communications; the Gateway is probably used for keeping the PLC's Port 0 available to PC software communications (DF1 over RS232).

I am not sure the Gateway will allow full ASCII control of the sensor.

Chapter 20 of http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1763-rm001_-en-p.pdf provides all the information required for establishing of and usage of the ASCII Port and String control instructions.

The sensor's User manual should provide you with the sensor side of required commands and data exchange for implementing of the intended functionality.

I believe you will need to connect the sensor directly to Port/Channel 0 of the ML1100 and use the LCD Communications Toggle feature to switch between DF1 (when Uploading/Downloading/Monitoring the PLC application) and ASCII when the sensor is being controlled and transferring data to/from the CPU controller.
Page 73 of http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1763-um001_-en-p.pdf

It will be a pain to implement, however, I think it's doable...:D
 
My question is how to approach this from a programming standpoint. Is there a common method used for sending/receiving a series of commands? The only data I want to display on the HMI is the final number, but I feel that I need to make sure the sensor comes back with the "ok" response before sending the next command. I think I can use a bunch of compare, and move commands but that kind of seems cumbersome and I'm just wondering if there is a more straightforward method.

The tool of choice for programming this sort of communication is a "state machine" or more precisely a "finite state machine". This is a well structured way to deal with things like sequences of communication messages going back and forth and not only make it work in a perfect world but also handle the many ways in which things can go wrong.

Think of each message going back and forth as a trigger to make your program go from one state into another state. It helps to start with a graphical diagram of states that your communication can be in, draw arrows from one state to another for all state transitions that may occur. Then write down under which condition your program would move from one state to another. Every arrow (= every state transition) should have one or more well defined conditions. Only under these conditions will your program follow the arrow to move into the next state.

E.g. before sending any messages, your code is sitting in an "idle" state (starting point for all communication). At this point there can be something that triggers the sequence of messages with your sensor (operator pushes button, another sensor sees a product, whatever). This would be the condition to go from state "idle" to state "send mode 1". The action to be performed once you are in that state is the actual send command.

Upon sending it, you would immediately move into a next state, which is "listening for OK. In that state, three things could occur:
1. Receive OK -> move to the next "send" state
2. Wait for quite a while then decide something has gone wrong: this is known as a "timeout" situation. Move to an error condition where you show or log some kind of error message, then either go back into "idle" state right away, or have a user acknowledge the error and only then move to "idle".
3. Receive an unexpected response: you get something back but it is not what you had expected hence your program "knows not how to go about". Again you may want to move to an error condition where you show or log some kind of error message, then either go back into "idle" state right away, or have a user acknowledge the error and only then move to "idle".

So three arrows are leaving the "wait for response on send mode 1" state.

Draw a simple diagram as you see fit for the description of normal communication with your sensor. If that looks OK, you have described what your program should do in every state and how it would progress to another state, then add the things that you think can go wrong along the way (typically timeouts, unexpected responses). Once you have your states, actions and transitions drawn and written down on paper, see if you can find a few examples of state machine implementation in your PLC language of choice. If you have your states described properly, it is not all that hard anymore to make it into a program if you have seen a few examples.

Your first state machine can be a bit daunting, and quite time consuming to make. Don't let this put you off. State machines can make your PLC programs robust and user friendly, it is a powerful tool to have in your programmers' toolbox.
 
The tool of choice for programming this sort of communication is a "state machine" or more precisely a "finite state machine". This is a well structured way to deal with things like sequences of communication messages going back and forth and not only make it work in a perfect world but also handle the many ways in which things can go wrong.

Think of each message going back and forth as a trigger to make your program go from one state into another state. It helps to start with a graphical diagram of states that your communication can be in, draw arrows from one state to another for all state transitions that may occur. Then write down under which condition your program would move from one state to another. Every arrow (= every state transition) should have one or more well defined conditions. Only under these conditions will your program follow the arrow to move into the next state.

E.g. before sending any messages, your code is sitting in an "idle" state (starting point for all communication). At this point there can be something that triggers the sequence of messages with your sensor (operator pushes button, another sensor sees a product, whatever). This would be the condition to go from state "idle" to state "send mode 1". The action to be performed once you are in that state is the actual send command.

Upon sending it, you would immediately move into a next state, which is "listening for OK. In that state, three things could occur:
1. Receive OK -> move to the next "send" state
2. Wait for quite a while then decide something has gone wrong: this is known as a "timeout" situation. Move to an error condition where you show or log some kind of error message, then either go back into "idle" state right away, or have a user acknowledge the error and only then move to "idle".
3. Receive an unexpected response: you get something back but it is not what you had expected hence your program "knows not how to go about". Again you may want to move to an error condition where you show or log some kind of error message, then either go back into "idle" state right away, or have a user acknowledge the error and only then move to "idle".

So three arrows are leaving the "wait for response on send mode 1" state.

Draw a simple diagram as you see fit for the description of normal communication with your sensor. If that looks OK, you have described what your program should do in every state and how it would progress to another state, then add the things that you think can go wrong along the way (typically timeouts, unexpected responses). Once you have your states, actions and transitions drawn and written down on paper, see if you can find a few examples of state machine implementation in your PLC language of choice. If you have your states described properly, it is not all that hard anymore to make it into a program if you have seen a few examples.

Your first state machine can be a bit daunting, and quite time consuming to make. Don't let this put you off. State machines can make your PLC programs robust and user friendly, it is a powerful tool to have in your programmers' toolbox.

This is very helpful, thank you for the detailed info. The way I was thinking originally would work, assuming everything goes right, but if something unexpected happens it could screw up the whole process. So, I think this will be very helpful.
 

Similar Topics

I'm currently working on a PLC setup and could use some advice on the best way to manage my power supply units (PSUs). Here's the configuration...
Replies
3
Views
355
So, I'm about to start my first ever project that include a servo motor Here some of the component i bought for the project so far: - PLC: Omron...
Replies
0
Views
368
Dear connoisseurs of antiquity and non-standard solutions, welcome) I don’t really hope, but suddenly someone had a deal and, most importantly...
Replies
0
Views
536
Hey guys, We have a metal container at work, we fill with saw dust (20fts x 15fts x 10fts) with the top open but we normally put a container...
Replies
4
Views
1,522
heya guys, For my project, i'm currently looking to add this type of linear encoder. The control company i'm working with told me they had bad...
Replies
6
Views
1,177
Back
Top Bottom