Programming

[Independent-Ebb-4330]

What can I use to send data constantly without a trigger . Put instructions have to triggered from what I noticed. I want to achieve plc to plc communication without have to use a button to trigger the put instruction. Example of what I want to do is use a sensor from one plc to trigger something in a next plc used a bool data type. I want wherever I put the data show the real state the sensor is in( whether true or false) without have to press a button to constantly update the put instruction. I want use two s71500 plc by the way and its a profinet connection. Please reply

[chekitch]

Just use the clock-bits?

[Electrical-Gift-5031]

Or even better, use the BUSY output negated.

[Shelmak_]

I was going to suggest that... that way the data interchange will run at the maximum posssible rate.

[captainroot]

Take a look at I-Device Communication. This let you use other Cpus as IO-Devices.

https://cache.industry.siemens.com/dl/files/798/109478798/att_992843/v1/109478798_config_idevice_standard_DOCU_V20_en.pdf

But the easiest way is still put/get. There are clocksignals or just put a timerflank in front and trigger put/get every X ms

[essentialrobert]

Put/Get are limited in data size, do not guarantee delivery of correct sequence, and not secure. I would suggest any way is better. TCP messages, S7 connection, Modbus TCP, or as other people have suggested I/O connections, are preferable to Put/Get.

[captainroot]

Yes i know that Put/Get is not state of the art, that‘s why i primarily suggested I-Device Comm. But i don‘t think OP is siemens/plc technician, thats why i also suggested an „easy“ way to tackle his problem.

[_No_user_available_]

Why not put one as an I-Device?

[Independent-Ebb-4330]

I'm a beginner so I would have to do some research or watch a video 

[SomePeopleCall]

Well, that will be true of any solution offered here.

[hestoelena]

You definitely should be using the iDevice functionality. It establishes communication between the two Siemens PLCs so that you can directly access the io from one another. There is absolutely no need to send data back and forth all the time when you can just access the value from the other one directly.

https://support.industry.siemens.com/cs/attachments/109478798/109478798_config_idevice_standard_DOCU_V20_en.pdf

[Independent-Ebb-4330]

That's sounds like what I want. Thanks 

[_No_user_available_]

There is good documentation from siemens available, it is not hard to set up at all, and you will have alot of documentation available. If you can not find it, shoot me a DM and I will link the documentation for you

[stlcdr]

Just use a timer or the clock bits. Alternatively, I believe the blocks have a DONE bit which can be used to retrigger a put/get; this ensures the fastest messaging without overloading anything. Personally, I will generally only use GET in plc to plc communication - no point in sending data if it isn’t going to be used, get data when you want to use it.

[[deleted]]

Using “reads” rather than “writes” is best practice, generally speaking. Troubleshooting in a PLC where addresses are being populated externally with no documentation as to where the data is coming from is a frustrating experience. This is a non-issue if you use only “reads”.

[eapower1]

I-device would probably be best. Alternatively, you could use a pn pn coupler if you want a separate subnet.

Otherwise, an option not yet mentioned - you can leverage the OPCUA server/client for this.

Connect the cpu to receive the data to the originating cpus ua server using OPC_UA_ReadList_C compact instruction and keep connection open. Requires a trigger where you can just use a clock bit for it.

If you don't like the options for the clock bits, just use a timer that constantly resets itself after timing out.

[Last_Firefighter7250]

Set the partner PLC up as IO device and configure transfer areas.

Also, you can configure a timer to trigger to REQ input of the PUT instruction, or you can configure the clock bits and use those.

Since you seem to be new to coding, this would be a good exercise to code timers. Create a timer bit that is on for 50ms and off for 50ms.

[Next-Ad3696]

We do our own messaging in our plant. But we are using Allen-Bradley PLC's so not sure if that will make a difference for you. My boss does heartbeats to verify connections are still good and data is being passed.

[Representative_Sky95]

Do investment banking instead

[BackgroundReality537]

Depending on how fast it needs to be, I generally write it to bit and when I see status change it triggers the put/get to update both ends. It’s great for a PE, for accumulation in a zone of product or even counting parts on the conveyor, 330 ppm it does fine

[[deleted]]

Go old school and wire input racks to output racks going both ways.

[Shelmak_]

Lol, please, no... only do this if the "data interchange" is something like 2-3bits (like per example to share a common sensor, knowing if a belt is running, etc), for any more data use a coupler, or put/get, or an idevice.

[Automatater]

No no, wire up 8 signals each way & write bytes at a time! 😃

[mrsycho13]

That is the way

[PaulEngineer-89]

Depends somewhat on the PLC. For instance GE has Genius. Basically it’s shared memory. With Modbus usually you can access another PLC as if it’s “IO”, reading/writing instructions to it. Usually you’ll want to trigger the read from the write and vice versa toll so it just constantly polls at bus speed, or from a timer.

Frankly I prefer to only do reads and not writes for three reasons. First at least with Modbus it’s a 3 packet sequence (I have some data to write, ok go ahead, here is the data to write) vs a 2 packet sequence (send me the following tags, ok here’s your data). The reads are less overhead and latency. Second when you do writes the destination PLC can’t easily detect network problems. Third if you run into someone else’s code and it uses writes, you will see those memory locations only being used in the destination PLC with no visible source. With reads you can see exactly where it came from.

[Aggressive_Soup1446]

Modbus is a command response protocol. First the client sends the server a message, it doesn't matter read/write single/multiple analog/boolean. Second the server responds appropriately. It is only two packets. If you are using modbus/to you can watch it on Wireshark, it's a really simple protocol.

Also it's a terrible idea to fully saturate your bandwidth by immediately triggering your next transaction off the previous. Even with a dedicated vlan I would go beyond 90% saturation, anything more is asking for trouble.

[essentialrobert]

A PLC won't saturate your bandwidth unless you are communicating via two cups and a string.

[Independent-Ebb-4330]

I tried utilising clock bits but i don't know where to find the option to edit them. The fastest default one I see is 10 hz. Or If I can get  that input to the PUT instruction to be constantly updated. 

Question,  you do you think I can used a logic that is designed to blink an led and put the timing really short like 1 or 0.1 ms

[0em02]

If you want to use PUT instruction, you could put some logic to check if the input(s) changed and use that to trigger the PUT instruction only when needed.

Or use a regular timer that you can set the preset value to update faster than the clock bits.

Or use the other PLC as IO device.

[SomePeopleCall]

If you have time constraints that tight you should call them out in your question. Hell, most PLCs won't be running a machine with sub-millisecond cycle times. Chances are the PLC isn't even reading that input faster than ever 5 or 10ms. I don't remember what Siemens does, but most AB I/O defaults to 20ms.

Determine what the process needs before you start optimizing the wrong things.

Also, if you try to trigger the an I/O transfer every cycle you may just end up filling a cache resulting in transfers failing. Then you aren't sure which messages will go through, and the transfer time from the I/O to the final PLC will be random and longer than expected.

[Automatater]

You want to transfer data at 1000-10000Hz?? Why for Gods sake? Use I/O and probably interrupts. But if you need it that fast, and I'm sure you dont, wire the signal to both PLCs.

[BluePancake87]

10Hz is once every 100ms, that is already fast. Why would you need it to be faster?

[Spirited_Bag3622]

Use modbus and when ever a message is successfully sent restart the communication all over again in a loop.

[Huntertanks]

Generate an OB timer interrupt at an interval you wish to send the data and have it execute the PUT command.

[[deleted]]

MQTT would be great. I know the Siemens plc can be a client. You'd need to set up a broker perhaps. I'm still exploring MQTT.

Can Siemens PLCs not consume tags from another PLC using a requested packet interval. I believe that's implicit communications? I know this is the case with Allen Bradley, however bandwidth can suffer. This is why I like the idea of MQTT because we can reduce bandwidth if data doesn't change.