Protocol Macro PMCR String Format

[RickyQ 1]

Hey guys, any help in how to format the receive message to read this ascii string would be greatly appreciated. $xxxx-x,Axxx,Bsxxxxxx.,Csxxxxxxx. Header is always $ packet lenght is always the same i would like to read field 1, 2 and 3 as ints and i guess field 4 and 5 as long ints.

[Jay Anthony 118]

I didn't test it. You might get moderator PMCR to rule on it. Also, I bet there is a <CR> on the end of the string.

[Michael Walsh 268]

I am not sure by the description if it is a message that is being received or being sent. It is a receive message, then all of the "(R(DM" pieces of the message should be "(W(DM".

[Jay Anthony 118]

OK. So it was 5;00am... Good catch, Moderator Mike!

[RickyQ 1]

Oh wow. Awesome!!! Thank you guys, i was hoping for some guidance, got a lot more than that! Thanks Again! I have a question, i setup a simple test with a little c# app that has an incrementing counter over the serial port. Inside PMCR i setup the read as such:<h>+(W(DM 00000),31) I setup the comms on both the card and the PC port @: 38400 baud. Even though i know for a fact the PC is sending a new packet every 10 milliseconds or so, i'm reading a new packet at the PLC every 60 or 70ms According to my calculations receiving the 33 bytes over 38400 should be a lot faster than what i saw in the trace. Any ideas? i assumed the macro and running the PMCR function in ladder would add some overhead but i did not think it would be that much!

[Michael Walsh 268]

Several delays go into receiving a message. First, you have the time that it takes to send a message across the wire. 33 bytes at 38400 should be around 7ms. The table below shows the expected time to receive a message from when it has been received to when it has been received in the PLC: This table would add another 10.5 ms. You are up to 17.5 ms now. You then need to consider 2x your PLC scan rate as a worst case scenario. Lets say your scan time is 3ms. So, now you are up to 23.5 ms. Already you can see that it will not catch the 10 ms rate. Of course, there could be issues with the way that your ladder is set to re-trigger the PMCR instruction. There are also timeout timers set for the protocol that could be causing some delays (depending upon what is happening). See these below: If you really need a fast response, look into the CJ1W-SCU22 style High speed SCU modules. As you can see in the first chart, it only takes about 700 microseconds to get the data to the PLC (compared to 10.5 ms).

[RickyQ 1]

Michael, All good info, Thank you! The numbers you came up with are still a ton better than what i'm getting for some reason. I setup the PLC to run free for testing purposes and it's running at about 1.1 ms. The PMCR instruction is running on P_On and Not the PMCR executing bit. Based on some traces, i saw that it is taking the PMCR about 40 ms to complete. and i am getting a new data point at about every 60ms. I made sure i had no filters in the macro and i have only one receive step "00". I ordered a SCU42 but i would still like to know why i cant get at least into the 30 to 40 ms range with 232 @ 38400... My receive message looks like such:<h>+(W(DM 00000),31)+"." The trace is setup to get a sample every 10 ms.

[Michael Walsh 268]

I would definitely use a normally closed Protocol Macro executing flag in front of the instruction (1909.15 for port 1 and 1919.15 for port 2). If you are triggering it all the time, it could be causing some errors and adding to the time that it would take to re-trigger the PMCR instruction. Since your code is relatively empty, you should not have to worry about the logical port enabled flag, but you could add it in just in case if you want (A202.00 - A202.07 depending upon which port you selected). Can you attach your CX-Programmer and CX-Protocol files?

[RickyQ 1]

I'm using Unit 3 for the SCU so the bit is 1594.15 or at least i think that's the correct one :D As far as the logical port i have it on auto = "F" the manual said i could do that with a CJ2. I've also parsed a value and it is being moved to "Bat" it is just an incrementing counter for testing purposes. Anyways, I've attached both files, The trace attached came from running the attached files. THANK YOU SO MUCH for looking into this with me. PMCR_Rev000_Post.cxp PMCR TEST 2_Post.zip

[Michael Walsh 268]

I cannot really see anything that would be causing delays. Try setting your logical port to 0. Perhaps it causes some delay to automatically determine the port number. Quite often when things are made to be automatic for the programmer overhead programming is added in the background. There may also be more delays in the mix of which I am unaware.

[PMCR 66]

RickyQ Great work on learning Protocol Macro on your own. It is not easy, but once you get the hang of it, it is very powerful! Michael is correct, you should always use both the PMCR Executing bit and the Logical Port Busy bit together. Even thought you can use the code of F for automatically selecting the Logical Port, I highly recommend not doing this. You have much better control and monitoring of the A202.xx bits if you manually assign a Logical Port for use with the PMCR. The timing diagram below shows the relationship of the A202.xx and 1509.15 (or similar) bits. There is an additional delay to consider. When you execute a PMCR instruction in ladder, it takes time get the call to the SCU card buffered across the CPU bus. I did some benchmark testing years ago on this, and it take approximately 60ms to get a PMCR started on the SCU once you make the call in ladder. There is a way to get around this. You can set the PMCR to go back to step 0 after each reception. This make receiving data much faster. I have tested the modifications to your code, and I can receive back to back messages without missing any with a 10 ms gap between messages. I tested up to 1000 consecutive messages, and I got them all. PMCR TEST 3_Post.zip PMCR_Rev003_Post.cxp

[Michael Walsh 268]

I figured that there was another delay that I did not know about in there somewhere. Nice solution with the goto 0 option. Just kick it off at power on and it runs until the PLC is no longer in Run / Monitor mode. This way the 60 ms additional delay only happens one time.

[RickyQ 1]

Yup. the goto loop did it! i had no idea and i could not find any info on the 60 ms delay for the instruction to run... THANKS FOR THAT TIP!!! Well, i jumped to serial after uncovering that the receive TCP socket FB (the CMND) instruction in particular takes 40 ms to execute. i wish there was a way to make that puppy run faster. Thanks for the props PMCR but i cant take all the credit, michael and jay gave me the first syntax that caused the click in my brain. After taking a look at that, everything became much clearer... im running some tests now and im receiving every message every 10ms. which is awesome. i cant wait to receive the scu42 and run some numbers with it. Here's another question for you guys: Right now im dumping the whole 31 bytes to memory and plan do write the FB's to parse them myself. If i were to separate them in PMCR eg: 3 digits to DM00, 6 digits to DM01 etc... (using the syntax suggested by Jay and Mike) Would that add processing time to the macro? Again guys, thanks a bunch for all the help! :D

[Jay Anthony 118]

From my history with Protocol Macro, it wouldn't make any difference. I would let the PMCr do the parsing. But as always, in matters of PMCR, I defer to PMCR.

[RickyQ 1]

Awesome. Thanks! i wrote the FB to do the parsing in ladder. i will experiment with PMCR. Thanks again to everyone!