cmarion (Customer) asked a question.
I am new to PLC programming (Click Plus) and would like some advice on how to interface a Click Plus PLC with a software application my developer is creating on a PC.
The PLC is controlling a system of lights and actuators to position a product for image acquisition. The PC is connected to cameras within this PLC controlled system and is acquiring the images. The PLC needs to "notify" the PC when the product is ready for image acquisition and the PC needs to "respond" when the image acquisition is complete and if the result was good or bad. What is the preferred method for doing this? I can have the PC application read/write to a data register that the PLC uses to manage the process, but this doesn't seem very elegant and I'm assuming there's a better way. Any suggestions for me to research is greatly appreciated!
What programing language are you writing the application in?
I use quit a bit of python and use pymodbus to communicate wit the PLC.
https://pymodbus.readthedocs.io/en/latest/source/examples.html
Thanks for the response. The application is developed using Python. I believe our developer is planning to use Pymodbus to write/read registers in the Click PLC. My primary question is whether this form of handshake - using registers - is a typical/robust approach.
Here is a library we've done some testing with. By way of disclaimer, Automation Direct can't support or guarantee any part of a third-party library. However, as far as third-party tools go, this one looks pretty helpful.
https://github.com/alexrudd2/clickplc/tree/master/clickplc
Thanks for the code example. Is my approach - to read and write a set of data registers (DS) to communicate status between the PLC and computer a typical approach or are there other more preferred approaches? Thanks.
This is pretty typical. Block off two chunks of registers and comment them as such in the Click. One chunk is commented with a prefix like "FROM YourApp" and the other, "TO YourApp"
I frequently use the first one in each group as a heartbeat. In the Click, copy the scan counter (DS9) to the chosen "TO YourApp" DS register as proof that the Click PLC is running. This may be important because a loss of comms may not occur if the PLC faults, but the value in that register will stop changing. If your app can send a rapidly changing value to the first "FROM YourApp" register, a line of ladder logic in the Click will be able to detect how long it has been since fresh data has arrived and can alarm or take action, if necessary, based on that timer value.
It is common to just repeatedly read and write those values but not too much faster than required by the application. And just let another section of the external application work with and manipulate the values in the data that is constantly being updated both ways.
It is common to use 16 bit (DS registers) integers for everything. If you need floating point, you can imply the decimal to one or two places depending on the range. If you need a true 32 bit floating value to be passed back and forth, it can consume two consecutive DS registers and be block-copied into a DF (floating point) register for use by the Click.
Likewise with Booleans. Pack them into a 16 bit integer and copy-unpack them in the Click. There is rarely a need to have separate read and write blocks for floats and bools. It's more efficient to manage two large blocks of INTs rather than multiple blocks of various data types.
Always block off some spares and comment them as "FROM YourApp RESERVED" or something like that and go ahead and read and write the spares. Then when it is time to add a trinket to the code, you don't have to mess with the messaging code, just edit the comments and start using them.
All this advice comes from my world of communications between various types of control hardware (mostly PLCs) where we often use terrestrial radio modems so efficiency of communication is more important than some other situations. Also, in my world, knowing that the controller at the other end of the comms is not only responsive to polling, but is still running is important, but may not be important to your situation.
yeah the clickplc library is pretty nice. Be sure to download the master branch, as I had recently helped make some improvements in it that arn't in the released pypi version.
Here's an example of how to update your plc's clock:
https://gist.github.com/ssweber/5a860dab0f68467041a62e0eacc6ccc7
Wow @OkiePC (Customer) I really appreciate the detailed response. Your recommendations make complete sense to me and I feel better knowing that what I'm trying to implement is a common industry practice. Reserving a block of registers is smart. Thanks again - have a blessed day!