You have programmed a multiple read function, which also works. Unfortunatly there is no multiple write function. I am currently trying to program it, but without luck. Is it possible to multiple write ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess it will be possible and it will differ from single writes much the same way the multi-read differs from single read. I will try it. It had no great priority for me, because I allways thought of HMI applications and the like: The user changes ONE value at a time, so there is not much use for it. At the moment none of the read/write functions checks whether a call exceeds the limits given by S7 communication:
The maximum length of a PDU is nogotiated in connectPLC. Most PLCs(all 300?) set it to 240, which results in 222 bytes for a read and 218 for a write request, if I'm not mistaken.
Multiple read seems to have a further limit at 20 items addressed in a single request. Don't know whether this depends on CPU type.
As multiple write will have to communicate the values along with the target addresses, it's likely to reach the PDU size limit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have implemented multiple write yesterday. Works with multiple address parameters in a single PDU much like multiple read. The only thing is that the first addVarToWriteRequest() adds parameters AND data. This makes it necessary to copy the data to a position after the new parameters in subsequent calls to addVarToWriteRequest().
I will release this version the next days.
Please let me know about your tests with multiple PDUs. I thought about his, but never tried.
It would also cost the overhead of a complete PDU, but save the overhead added by MPI or other transport layer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It didnt work on a S7-200, i always getting a PDU which ends with 00,85. So thats an errorcode 8500, but what doest it mean? The help of Simatic MicroWin said something about a corrupted for loop, but thats an error code for something else.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, your message is quite cryptic to me! WHAT did not work on a 200? Does "on a 200" mean it DID on another CPU? If you got an error PDU, why don't you include at least your request PDU (or, if you are testing your idea of multiple PDUs, the complete request you sent to the CPU)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i was testing my theory about multiple PDU's. I have send a message to the plc with 2 PDU's.
first PDU wants to write 0x05 to position 6 of datablock.
second PDU wants to write 0x05 to position 7 of datablock.
this is the message i got from the PLC: 0x68, 0x0F, 0x0F, 0x68, 0x02, 0x03, 0x08, 0x32, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x85, 0x00, 0xC6, 0x16
I have send 2x complete PDU(header + parameters).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i forgot to say that S7-200 has only 1 datablock so DBnum is 1.
I also have another question: There is a variable localMPI. It has something to do with MPI protocol of 300/400 series PLC, but the 200 series has PPI protocol. when i put a number between 0 and 127 i still got a good response from the PLC, when the number is higher the PLC doesnt understand it and will give no response(0xE5), do you have any idea if this variable has any meaning to PPI?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
0x32, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x85, 0x00
is a single PDU reporting an error .-(. I don't know which.
Could you please:
1.Include the message with your combined PDUs
2. Tell me whether multiple PDUs per message has ever worked on any system?
About writeing to positions 5 and 6 or anyjacent positions: You can do that with no modification at all using length of 2 :-)
Multiple write would be for non adjacent memory areas/ranges. I guess you know that, but only in case...
About PPI and localMPI:
PPI also addresses multiple devices on a bus by numbers. The variables MPI and localMPI are used as these addresses. So if you connect more than one CPU, you will to set the (PPI)address od it to something other than 2 and you can address one or or the other with Libnodave putting the address where you put the MPI target address. If you have another device with address 0 (I think the TD200 has 0 as default), you should be able to set the PCs address to something else using local MPI.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more thing:
127 is the highest possible address on Profibus (and PPI) networks. E5 is a "short ackknowledge" according to Profibus specs. I guess the meaning is: "This is all I can say to your message, do not wait data anymore". This saves time on a Profibus network, as the sender would waste all its max time share waiting otherwise.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried it with DataBlock and Flags. The PLC dont understand multiple PDU's. I also have at the moment the time for doing some more tests with the PLC. Work ...:(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have programmed a multiple read function, which also works. Unfortunatly there is no multiple write function. I am currently trying to program it, but without luck. Is it possible to multiple write ?
I guess it will be possible and it will differ from single writes much the same way the multi-read differs from single read. I will try it. It had no great priority for me, because I allways thought of HMI applications and the like: The user changes ONE value at a time, so there is not much use for it. At the moment none of the read/write functions checks whether a call exceeds the limits given by S7 communication:
The maximum length of a PDU is nogotiated in connectPLC. Most PLCs(all 300?) set it to 240, which results in 222 bytes for a read and 218 for a write request, if I'm not mistaken.
Multiple read seems to have a further limit at 20 items addressed in a single request. Don't know whether this depends on CPU type.
As multiple write will have to communicate the values along with the target addresses, it's likely to reach the PDU size limit.
and when you send multiple PDU's in one request? Should that work? I will try it out tomorrow.
I have implemented multiple write yesterday. Works with multiple address parameters in a single PDU much like multiple read. The only thing is that the first addVarToWriteRequest() adds parameters AND data. This makes it necessary to copy the data to a position after the new parameters in subsequent calls to addVarToWriteRequest().
I will release this version the next days.
Please let me know about your tests with multiple PDUs. I thought about his, but never tried.
It would also cost the overhead of a complete PDU, but save the overhead added by MPI or other transport layer.
It didnt work on a S7-200, i always getting a PDU which ends with 00,85. So thats an errorcode 8500, but what doest it mean? The help of Simatic MicroWin said something about a corrupted for loop, but thats an error code for something else.
Sorry, your message is quite cryptic to me! WHAT did not work on a 200? Does "on a 200" mean it DID on another CPU? If you got an error PDU, why don't you include at least your request PDU (or, if you are testing your idea of multiple PDUs, the complete request you sent to the CPU)?
i was testing my theory about multiple PDU's. I have send a message to the plc with 2 PDU's.
first PDU wants to write 0x05 to position 6 of datablock.
second PDU wants to write 0x05 to position 7 of datablock.
this is the message i got from the PLC: 0x68, 0x0F, 0x0F, 0x68, 0x02, 0x03, 0x08, 0x32, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x85, 0x00, 0xC6, 0x16
I have send 2x complete PDU(header + parameters).
i forgot to say that S7-200 has only 1 datablock so DBnum is 1.
I also have another question: There is a variable localMPI. It has something to do with MPI protocol of 300/400 series PLC, but the 200 series has PPI protocol. when i put a number between 0 and 127 i still got a good response from the PLC, when the number is higher the PLC doesnt understand it and will give no response(0xE5), do you have any idea if this variable has any meaning to PPI?
0x32, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x85, 0x00
is a single PDU reporting an error .-(. I don't know which.
Could you please:
1.Include the message with your combined PDUs
2. Tell me whether multiple PDUs per message has ever worked on any system?
About writeing to positions 5 and 6 or anyjacent positions: You can do that with no modification at all using length of 2 :-)
Multiple write would be for non adjacent memory areas/ranges. I guess you know that, but only in case...
About PPI and localMPI:
PPI also addresses multiple devices on a bus by numbers. The variables MPI and localMPI are used as these addresses. So if you connect more than one CPU, you will to set the (PPI)address od it to something other than 2 and you can address one or or the other with Libnodave putting the address where you put the MPI target address. If you have another device with address 0 (I think the TD200 has 0 as default), you should be able to set the PCs address to something else using local MPI.
One more thing:
127 is the highest possible address on Profibus (and PPI) networks. E5 is a "short ackknowledge" according to Profibus specs. I guess the meaning is: "This is all I can say to your message, do not wait data anymore". This saves time on a Profibus network, as the sender would waste all its max time share waiting otherwise.
Multi PDU's dont work.
I tried it with DataBlock and Flags. The PLC dont understand multiple PDU's. I also have at the moment the time for doing some more tests with the PLC. Work ...:(
>The PLC dont understand multiple PDU's.
That's what I supposed.
I will release Libnodave 0.6 (with multiple write) this evening or tomorrow.
Version 0.6 just released.
Thanks :)