Is it possible to notify events from PLC to PC? (Siemens S7 Tp1500)

Hello.

I am a very begginer about PLCs, and I would like to know if it is possible the following case.

I have a S7 PLC and a TP1500 touchscreen which saves logs in a SD card. This logs has alarms, errors and another information.



Now, I want to save the data in a Sql Server database.


I want to develop a small application for PC, using C#, to can communicate with the PLC. I have read about S7Net, S7Net Plus, Sharp7 and Snap7, they allow the communication about both devices.



The idea is that this PC application receive notifications from the PLC, the it can handle and send and email to user, save the message in the database and do more actions.



But for me one problem is that all the examples that I have seen using the libraries for C#, it allows to PC read and write data to PLC, but I don't see the option in which the PC is waiting to be notify by the PLC. So is the PC application which has to read data periodically from the PLC, in a infite loop, and check if there is logs or not.


I have seen the possibility that I coould use Lsql blocks in the PLC program to save the data directly in the database. it is a good option, but how the process is direct, the PC application doesn't know about it at first, so I can't send notifications to the user. For that, I should to check the data in database periodically to know. So it is a bit less efficient. For this solution I see the example in the Siemens web: Connecting a S7-1200 PLC / S7-1500 PLC to a SQL Database - ID: 109779336 - Industry Support Siemens.


In sumary, I would like to know if there is some way the PLC notifies to the PC application, which is listening for events, instead to have to read PLC periodically in a loop.






Thanks.

There is no magic solution - something somewhere will have to check the plc. Setup a thread with a read and sleep in it in your C# application to check if the plc has some data to be read.

Thanks for the suggestion.


Yes, this is one of the options. But I guess it has son disavantages:


First, I have to check every 10 seconds, for example, if there is new data in the PLC. This makes I have to use more resources from PC side and PLC side, because I have to read many times values in the PLC when it is not needed. really most of the time, because alarms and another errors are not common.


Second, it is how to handle concurrency. For example, the easy case is, the PC check the PLC, if finds one alarm, handle it and clear the alarm in the PLC. No problem in this case.


But what happen if the PLC add a new alarm when the PC is handling the first alarm? I mean, PC check the PLC, finds one alarm, PC starts to handle the alarm, PLC add a new alarm. If the PC clear the alarms, it would lose the last alarm.


This solution is more complex than if the PLC could send the alarms to the PC, there not would be problem with concurrency, because the PC can handle the events in parallel.


But sure, I accept that perhaps this is not the correct whay to handle concurrency and there are better ways to do it. If there are better solutions, It would be nice to know.



It is why I ask if there is the possibility the PLC notify the events to the PC, it is more simply and better solution. If someone knows that it is not possible, then of course I can't think in this solution, but is someons knows if it is possible, I would like to explore this option.

Maybe OPC UA alarms and events is what you are looking for ?
https://cache.industry.siemens.com/...IC_NET_OPC_UA_AlarmsAndEvents_DOC_V1_0_en.pdf
Your PC application would then have to be an OPC UA client.

Apart from that, polling data is quite normal. I dont think you have to worry about the communication being 'less efficient'. Anything from 500 ms and up is no problem for todays PLCs and PCs.

You could use the method described in the FAQ you linked to, to achieve a 100% event based solution. There wont be a PC in the system, will that be a problem ?

Thanks for the documentation about OPC, I will see.


About the polling data to PLC, there is another consideration apart of the performance, it is the concurrency control.


For exmple, in a simple process I would have this:


1.- PC polls the data from PLC.
2.- PC finds an alarm.
3.- PC handles the alarm.
4.- PC clears the alarm in the PLC (I am not sure if this a good idea).


In this simple case, all is fine, because there is not conflict. But supose this another case:

1.- PC polls the data from PC.
2.- PC finds an alarm.
3.- PC handles alarm.
4.- PLC add a new alarm.
5.- PC clears the alarms of the PLC.


In this case the PC loses the second alarm and clears the alarms of the PLC, so the alarm is lost.


But I accept that this could not be the best way to do, but if not, which another way is better?

You can send data over Ethernet to a Port on a computer and have the PC watch that port for an incoming connection, once the 'data packet' is received, the PC can then 'do something'. In Linux I think would use systemd, and a .servie file that activated when the incoming data was recived.

There is a bit of 'spit balling' going on here and I am joining together bits of other stuff that I do, so don't ask me in depth questions I squirt ASCII data out of a PLC to a Port on a Linux PC, the PC receives the data and does 'stuff' with it. On the same Linux PC I have a .system file that waits until a USB stick is connected, and then runs a program. And I recently used a 'magic packet' to wake a PC device from sleep. So joining all that together it should be possible, maybe, I think, could be, perhaps

If you have an S71500, v17+, and up to date FW, then you can use the OPC UA Alarms and Events system that exists for that exact purpose. This is an extra license on the PLC side, but I think fairly minimal coding?


Otherwise, Open Socket TCP comms are probably your best bet. PLC sends, PC listens, PLC automatically gets an acknowledgement back that it was received. You can add your own protocol if you want, to include handshakes that the alarm was processed (in addition to just recieved), incrementing an alarm number so that the PLC knows which alarm in the buffer to acknowledge, etc.

mk42 said:

Otherwise, Open Socket TCP comms are probably your best bet. PLC sends, PC listens, PLC automatically gets an acknowledgement back that it was received. You can add your own protocol if you want, to include handshakes that the alarm was processed (in addition to just recieved), incrementing an alarm number so that the PLC knows which alarm in the buffer to acknowledge, etc.

Click to expand...

+1. The PC needs to be a server (listens), and the PLC is the client (sends).


How many alarms do you need to check?

It might be simplest to create a Web API using the S7 Library for HTTP Communication (LHTTP). A simple LHTTP_Get request, to a pre-defined address, is then all that is needed to notify the PLC Web API "server" that the alarm associated with that address is active. The response from the server does not have to contain any content.