As far as I understand, with DP_SEND and DP_RECV the important things to note is the SEND/RECV target type (I, Q, DBxx) and the number of bytes starting from 0.
As it says in the help for CP342-5 you can specify up to 2160 bytes with the later version CPs. The CP will then put all the bytes into its internal i/o image table and the update its physical i/o from that table.
The CP may use only a small fraction of that i/o table, but that is how it works.
I think that using the Q area is a little bit more "direct" than normal, but I cannot see why it should not work.
One thing is that I think it will take many cycles to update both CPs with 2048 bytes. Maybe it would be a good idea to put the i/o that is accessed via the CP in the start of the i/o image, and then only send the fraction of the i/o table that is necessary.
As it says in the help for CP342-5 you can specify up to 2160 bytes with the later version CPs. The CP will then put all the bytes into its internal i/o image table and the update its physical i/o from that table.
The CP may use only a small fraction of that i/o table, but that is how it works.
I think that using the Q area is a little bit more "direct" than normal, but I cannot see why it should not work.
One thing is that I think it will take many cycles to update both CPs with 2048 bytes. Maybe it would be a good idea to put the i/o that is accessed via the CP in the start of the i/o image, and then only send the fraction of the i/o table that is necessary.
