PMCR step counter not incrementing

[lchamarthi 2]

Hi, In my program, PMCR step counter not incrementing with the bit 1634.15 for SCU unit no.5 Step counter is at 1 only. I am unable to understand why 1634.15 is not going on/off to increment counter. pl help me attached are the programs. unable to attach standard ModbusPM_v5.psw protocol file, which is available in Forum. Thanks for the help 3PMCR.cxp

[PMCR 66]

Without seeing the rest of the data, it is a little tough to diagnose. Here are some suggestions, 1. Change the first control word from a DM to a constant. You should know the Logical Port number, physical port number, and SCU board number. #0115 would be the correct Control Word 1 for Port 1 on SCU 5, when using Logical Port 0 (a202.00). 2. If you can, use a constant for Control Word 2 (sequence #). &50 would be correct to call sequence 50. This is an example. I don't know which sequence you are trying to call. 3. Add an error trap as shown, to look for an error executing the PMCR. If DM5000 is incrementing, then there is a problem with the PMCR instruction. a. Port not setup as User Setup, PMCR b. Protocol Macro not loaded to the SCB. c. Wrong Control Word 1 or Control Word 2 PMCR_Error_Trap.bmp

[lchamarthi 2]

Hi PMCR, Thanks for the inputs for trobleshooting. Right now it's working fine, after ensuring Data registers and setvalues. Guys, Right now 1. I am facing problem of Modbus node fail set bits are set even during the normal operation like For example W6.0 (Transmission error) and W6.1(read error) become high then go low, this is enough to throw a fault and display. How can be avoided this? 2. Response from node is significiantly slow as the Nodes are more because Polling/Step counter value becomes more. So there any best method apart from the concept which i have opted in the first thread attached program. May using one PMCR per node for both reading and writing something like that, so that step counter will become half for right now size. 3. Protocol Macro I have downloaded from Forum only. It is having Master and Slave routines with Sequence Nos. I didn't understand fully. So is there any document on macro like Data field example – what does this code mean? <a>+SOH+(R(2),4)+<c> Thanks Lakshmi Edited 29 Oct 2008 by lchamarthi

[PMCR 66]

<a>+SOH+(R(2),4)+<c> <a> is a substitution from the Address column. SOH is a CHR(01), which is Modbus speak for Read Coil Status (command code 01). (R(2),4) = Send data from an offset of 2 in the send data table (3rd word, since the first is considered 0). 4 = send 4 bytes of data. <c> = check code. the text in blue is the text over which the check code is calculated. If you are using this macro, http://forums.mrplc.com/index.php?autocom=downloads&showfile=259 there is a Word doc that is very good as PMCR documentation goes. As far as reading from more nodes faster, the only way to do this is to use more serial ports. A single serial port can only execute 1 sequence at a time. So, for faster updates you could use multiple serial ports, each executing a PMCR simultaneously.

[lchamarthi 2]

Thanks for the reply. I solved that issue with your suggestions. Method mentioned in attached program is used to communicate with 13 slave devices using PMCR instruction. I am using one PMCR for read and one more PMCR for write of slave. like wise 26 PMCRs for all 13 nodes, and am using a counter to poll based on PMCR execution finishing flag completion status. But when I poll for all 26, response from slave is nearly 5sec delay. I am looking for possible options of reducing this delay either 1. Can we use one PMCR only for both read and write functions so that poll will limit to 13 and becomes faster. 2. Is there any another method of polling to make fast Expecting response is about 2s for 13 slaves config. PLC used is CJ1 CPU13 Thanks Lakshmi

[PMCR 66]

I am glad to hear that you are having success. You can combine the send and poll into 1 sequence, but obviously it still take 4 serial string (Send Data, Get Response, Poll for Data, Get Response), so you will not save a whole lot of time. What you would save is the time that it takes to get the PMCR started. I timed it years ago, and if I remember correctly, it takes somewhere around 50ms to get a PMCR started. So, if you are executing 1/2 the number of PMCRs by combining send and poll, you should save somewhere on the order 1 - 1 1/2 seconds over your 26 devices. The other thing you can do to speed up a PMCR is reference the memory in the PLC inside the Protocol Macro directly, as opposed to using the 'table method'. so, &~(W(D500),1) is slightly faster then &~(W(1),1).

[lchamarthi 2]

Really Happy to see some different ideas..... combininig send and poll into 1 sequence, i understand that for read and write will happen in only one pmcr ...right.but i was confused protocol macro to be changed as i am not good handle on understnading of macro as i said last time. You have suggested me to go through manual provided for macro....May be i can't able to undestand data fields what really mean like what you have given an option of applying or referencing plc memory in macro &~(W(D500),1) is slightly faster then &~(W(1),1). Could you provide me some sample how to do it...... Thanks for the great help.

[PMCR 66]

Above is an example of what I call 'Table Method', where you are specifying data from the send and receive tables specified in the 3rd and 4th parameters of the PMCR, and also an example of what I call 'Direct Method', where I directly specify DM500. You will get more speed increase by combining write & poll into 1 sequence than by changing from 'Table Method' to 'Direct Method', so if you are not familiar with this, it probably is not worth investing the time for the small increase that you would get. 'Operand' setting which is the default is what I call 'Table Method'. Edited 14 Nov 2008 by PMCR

[lchamarthi 2]

Thanks for immediate reply. any reference manaul for understanding macro Data fileds in sent and receive messages.....apart from the one you suggested... If i understand data fields, i will only keep try different options.... Thanks