I'm glad it helped! That address is used in other blocks and it gives a lot of people trouble. It took me a while to figure it out the first time I used it all those years ago! I hope your project goes well!
Thank you very much for accepting my suggestion last time. This enlightens me about questions in my mind ever. So when plc "reserve" the data before comunication cycle starts then it can increase the PLC cycle time and response time because plc have to wait for a consistent data completly copied into Profibus/profinet area memory and afterward Profibus/profinet comunication can start to a slave. Am i right?
I will need to look into this a little, but the cycle time shouldn't be affected greatly by this because the actual transmission is completed by separate hardware. The PLC moves the data into the registers then the DP hardware completes the transmission, then signals the main processor that the action is completed (usually triggering an interrupt). While it is transmitting, the main processor is running other code. This block just makes sure that when you move the data into the transmission register it is "locked" during the time it is moving. Look at my livestream where I talk a little about memory (I think it was the Pointer stream). Eventually, I am going to do some content specifically about the basics of Hardware, but for the time being I just talk about it a little in my streams, so make sure to at least turn them on in the background. I hope this helped! Thank you for being part of this community!
Jason, i want to thank you for this thourough explanation 🙏. A lot of videos just explain the inputs and outputs of these two blocks but not the reason we're using them and the data transfer problem they solve 😡. Couple more QUESTIONS 😁, and i know they are braud but bear with me : 1- Using these two blocks with profibus and it's slow 1.5 Mbps (or less) is convincing, but would the same fear arise with profinet and its higher transfer speed ? or should we just use them anyways to guarantee the best results ? 2- Since you explained with the drive example i decided to implent these two in my VFD "CONTROL - FB". However, i want to know where else i should (must) use them ? (pumps, valves, measuring temperature, presssure..) maybe PIDs in general 🧐 Signature N00B_Lvl_ONE_THOUSAND
One thing about ProfiNet is that since it uses TCP an entire telegram can fit into one packet. So the actual transmission is protected from this to a point. There is a problem if your actual network is in so much trouble (Some versions of Powerflex drives are notorious for breaking regular LANs) that there are collisions and buffers in the switches, but ProfiNet RT (what is used by PLCs to drives) by passes a lot of this. Second thing, you set the RT update rate in the PLC project for ProfiNet, so as long as your update rate is longer than the transfer time it takes to create the TCP packet (think a few microseconds) you are good Anything that has data that has a significant amount of data that needs to be "tied together" for proper function. Most of what you just named will only use a couple bytes at a time at the most so this wouldn't be needed... the only thing I can think of off the top of my head would be something like an RFID scanner that has a payload that is fairly large (think 200byes+). You would definitely want to use this to make sure that when you send the packet stuff doesn't get updated in the middle of the process.
No problem! I always want to help. It's just that I usually have to schedule my time pretty tightly. You caught me on a break so you get a quick response!
Yes, that would most definitely help (and is handled automaticallyin Portal), but you would still want to use these blocks on ProfiBus systems. I didn't say this in thevideo, but you can actually use this block on ProfiNet or others as this is just a way to "reserve" the data as it is being transferred.
@LFC2702 I do not (for drives) and here is the biggest reason why. Siemens' own technology objects don't use these blocks for ProfiNet. Now, Portal does set a lot of settings behind the scenes that make things work smoothly with TOs, but they use a "actor interface" tag with the datatype of "PD_TELx" and points the tag to the IO address. I have used this method with many general purpose drives without problems, but that doesn't mean I am necessarily doing it the "100% proper" way. If your process is at risk to inconsistent data using these blocks is a fairly easy way to sleep better at night. You are going to have your data stored somewhere (even if it is in the instance data in an FB) and you can always reference that data with these blocks. This pointer structure also works with the use of TCP_SEND and TCP_REC to send generic packets over TCP.
@@jasonwattsae Hi Jason, Thanks for the above… Feel I’ve been looking into this for a while and gained more understanding from these comments that I have on my own research. Videos are great Jason enjoying the format of them. Curious to know what you got next coming up?
I am planning on doing our first livestream with one of the other owners of my company Alpha Industrial Technologies this Sunday where we are planning on going through our most recent Motion control program. The next edited video will probably be on MC TorqueLimiting and how it can be used. Is there a topic or block that would be helpful for you?
If you make it through the off centered intro without unsubscribing like this comment! I will accept all shame! 😅
Thank you. The part about starting typing the device name on the LADDR input of DPRD really helped me.
I'm glad it helped! That address is used in other blocks and it gives a lot of people trouble. It took me a while to figure it out the first time I used it all those years ago! I hope your project goes well!
Thank you very much for accepting my suggestion last time. This enlightens me about questions in my mind ever. So when plc "reserve" the data before comunication cycle starts then it can increase the PLC cycle time and response time because plc have to wait for a consistent data completly copied into Profibus/profinet area memory and afterward Profibus/profinet comunication can start to a slave. Am i right?
I will need to look into this a little, but the cycle time shouldn't be affected greatly by this because the actual transmission is completed by separate hardware. The PLC moves the data into the registers then the DP hardware completes the transmission, then signals the main processor that the action is completed (usually triggering an interrupt). While it is transmitting, the main processor is running other code. This block just makes sure that when you move the data into the transmission register it is "locked" during the time it is moving.
Look at my livestream where I talk a little about memory (I think it was the Pointer stream). Eventually, I am going to do some content specifically about the basics of Hardware, but for the time being I just talk about it a little in my streams, so make sure to at least turn them on in the background. I hope this helped! Thank you for being part of this community!
Jason, i want to thank you for this thourough explanation 🙏. A lot of videos just explain the inputs and outputs of these two blocks but not the reason we're using them and the data transfer problem they solve 😡.
Couple more QUESTIONS 😁, and i know they are braud but bear with me :
1- Using these two blocks with profibus and it's slow 1.5 Mbps (or less) is convincing, but would the same fear arise with profinet and its higher transfer speed ? or should we just use them anyways to guarantee the best results ?
2- Since you explained with the drive example i decided to implent these two in my VFD "CONTROL - FB". However, i want to know where else i should (must) use them ? (pumps, valves, measuring temperature, presssure..) maybe PIDs in general 🧐
Signature
N00B_Lvl_ONE_THOUSAND
One thing about ProfiNet is that since it uses TCP an entire telegram can fit into one packet. So the actual transmission is protected from this to a point. There is a problem if your actual network is in so much trouble (Some versions of Powerflex drives are notorious for breaking regular LANs) that there are collisions and buffers in the switches, but ProfiNet RT (what is used by PLCs to drives) by passes a lot of this.
Second thing, you set the RT update rate in the PLC project for ProfiNet, so as long as your update rate is longer than the transfer time it takes to create the TCP packet (think a few microseconds) you are good
Anything that has data that has a significant amount of data that needs to be "tied together" for proper function. Most of what you just named will only use a couple bytes at a time at the most so this wouldn't be needed... the only thing I can think of off the top of my head would be something like an RFID scanner that has a payload that is fairly large (think 200byes+). You would definitely want to use this to make sure that when you send the packet stuff doesn't get updated in the middle of the process.
Eyyyyyy thanks so much for the quick response and the clarification Jason ✌you made me pay attention to some very important points.
Much appreciated 👊
No problem! I always want to help. It's just that I usually have to schedule my time pretty tightly. You caught me on a break so you get a quick response!
thank you for the good presentation, it is very handy
I'm glad it was helpful!
Shouldn’t process image updates for telegram be disabled?
Yes, that would most definitely help (and is handled automaticallyin Portal), but you would still want to use these blocks on ProfiBus systems.
I didn't say this in thevideo, but you can actually use this block on ProfiNet or others as this is just a way to "reserve" the data as it is being transferred.
Would you use this block on a profinet system still?
@LFC2702 I do not (for drives) and here is the biggest reason why. Siemens' own technology objects don't use these blocks for ProfiNet. Now, Portal does set a lot of settings behind the scenes that make things work smoothly with TOs, but they use a "actor interface" tag with the datatype of "PD_TELx" and points the tag to the IO address. I have used this method with many general purpose drives without problems, but that doesn't mean I am necessarily doing it the "100% proper" way. If your process is at risk to inconsistent data using these blocks is a fairly easy way to sleep better at night. You are going to have your data stored somewhere (even if it is in the instance data in an FB) and you can always reference that data with these blocks.
This pointer structure also works with the use of TCP_SEND and TCP_REC to send generic packets over TCP.
@@jasonwattsae
Hi Jason,
Thanks for the above…
Feel I’ve been looking into this for a while and gained more understanding from these comments that I have on my own research.
Videos are great Jason enjoying the format of them.
Curious to know what you got next coming up?
I am planning on doing our first livestream with one of the other owners of my company Alpha Industrial Technologies this Sunday where we are planning on going through our most recent Motion control program.
The next edited video will probably be on MC TorqueLimiting and how it can be used.
Is there a topic or block that would be helpful for you?