RickyQ

hard wired 24v relay is definitely the best  / safest way to go about it. the problem is not really that the EIP comms keep going, its due to the fact that the menory area the EIP card is sending is stale from the last cycle. i believe there is anTag Data Link Start/Stop Bit in the diagnostics area, maybe play with only turning this high while scanning and see if it resets on its own like some reserved areas.

yes, check that the node set on the rotary switch matches the last octet of the IP address configured on the card. Post some captures of both sides!

been waiting for this!  

i answered my own question. nevermind :D

Dear PMCR experts, i have a question. I need to read a variable length ASCII string that represents a float via 232, i can get the data with PMCR but i am wondering if there is a way to programmatically parse this thing into a real. Say you receive 2 frames over serial with delimiters of 0D0A: Frame 1: 0D0A12.120D0A Frame 2: 0D0A95525.54D0A Now, if i just move the bytes over to a CJ, whether i choose to move them in ascii or hex i cannot use a standard instruction to FLT the binary. in Frame 1 i would have 5 bytes of data and for frame 2 i would have 8 bytes of data. if i move them in hex i would have half but i am still looking at bytes that represent char values and not a floating point encoded number. Any ideas? Can i do this with protocol macro?

WITS is a standard protocol used in oil&gas, stands for: Wellsite Information Transfer Specification it's basically an ascii stream on rs232 they use && and !! as delimiters and the records even though fixed in size are variable length. sample record: &&\r\n RRIIDDDDDDDDDDDD\r\n !!\r\n && 80070.0 80084.161 80090.004 80100.004 8012109.551 80130.000 80176.808 80181229.000 80222902.303 80231878.568 !! i'm thinking of doing this in structured text to avoid PMCR, but wanted to check if someone had a working parser.

Do any of you fine gentleman have a working sample of a PMCR for a WITS stream? THANK YOU!

Does anyone have a sample of a working forward_open to a wago EIP coupler? I am developing this in .net, even a WireShark capture would be great! Thank you.

Does anyone have a sample of a working forward_open to a wago EIP coupler? I am developing this in .net, even a WireShark capture would be great! Thank you.

Hey Guys, i want to get some input on something... I wrote some ladder using the TCP FB's in the library to communicate to a third party unit. I also wrote a C# TCP client for comparison, and here is the deal: When connecting with the C# client i see a new packet coming from the device every 20 ms or so. this matches what the vendor told us. However, the fastest i can get a new packet in CX is about 60ms, i did some traces and found that the Receive FB takes about 40ms to complete regardless of scan times or trigger times, I've attached a picture of the trace. What im wondering is: Is this a limitation of the FB? Limitation of the ETN? Could i do it faster without the FB? Any thoughts are welcome! Thanks!

I agree, I never measured the time to read the socket without the FB. it’s a question of going into the standard FB and hacking out the unnecessary stuff!

What is the data type of your D on this instruction? it requires a UINT, it looks like you have a string with the equivalent of ii in ASCII or maybe #6969? The ' ' is how cx-prog denotes "Strings"

Can you take a picture of how the drive is connected to EIP? i am also interested in how to change parameter of VFD over EIP

If you happen to have an omron PLC around, you can format the card with cx-programmer if you plug it into the omron CPU.

Confirmed that the function to recv data from etn to mem area of plc has a 40ms run time.

Since you are mostly doing p2p you should be fine, however, as you put more and more devices online i would multicast to improve overall performace. Once you go multicast I would recommend you get a managed switch that supports IGMP. I have seen unmngd switches get overwhelmed by multicast traffic. Point to point basically means that if your plc needs to send the same data to multiple devices it must send the data to each device one by one. In multicast mode the plc (or devices) only send the data once and listeners that need this data subscribe to the multicast group. Igmp will help the switch determine who the subscribers are and only forward the traffic to the appropriate port. Hope that helps...

All, i have been testing Wago and Siemens Profinet IO coming into a CJ2 PLC with a PNT21 card on it. In order to get some good round trip cycle time comparisons of data i am also receiving the data via profibus and hardwire IO cards. Doing some data anlysis I came to the conclusion that with the CJ2 running at 20ms i get new profinet data every 4 to 5 cycles, where profibus and hardwire is closer to 1 cycle or two at the most. In my profinet configuration in fdt i set the IO blocks for 8ms refresh and have tried a couple of other things to no avail. I have heard trough the grapevine that wago and siemens profinet IO blocks can get IO to the controller closer to 5ms or below. Im beggining to think the Omron implementation of Profinet in the PNT is my problem here. Has anyone had any experience with the PNT's??? could this be operator error? Hardware: CJ2-66EIP Acting as Field Device CJ2-66EIP as Controller PNT21 WAGO 750-333 SIEMENS ET200SP The topology looks like this: CJ2PLC Acting as field device with a 4 channel 4-20mA AO Output1 to Wago Profibus Coupler Output2 to AI card on CJ2 Output3 to AI card on Wago Profinet Coupler Output4 to AI card on ET200SP CJ2PLC as Controller with PRT, PNT, AI. Any input is welcome!

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.

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

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

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, 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.

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!

Yes! i did my updates and the "issue" has been resolved! :D

Here's an interesting one for you guys... I short, Cx-programmer does not want to connect using EIP trough the wireless adapter on a laptop, however, connecting with a cable on the same laptop works fine. We got new laptops with windows 7. We have a CJ2 with an ETN (fins) and the PLC's integrated EIP port. If you try to connect wirelessly to the PLC via Fins, it works. Via EIP it does not. However, if you connect the PC to a switch via Cable, everything works fine. I even went as far as to wireshark the packets and very simply if you select EIP as the connecting option, cx-programmer sends all packets trough the Wired NIC not the wireless. I messed with provider order, drivers, metrics to no avail. So far, im pretty convinced cx-programmer has a driver problem with these new wireless adapters we got but i cant prove it. I have tried a million things. nothing works. i installed XP-Pro on the new laptops and the issue is fixed. So far the problem is linked to: Lenovo W520 with Windows 7 pro 64-bit. the wireless adapter is: Intel® Centrino® Advanced-N 6205 does anybody else have the same issue? We have 3 different brand new laptops and the problem is replicated on all three. Cx-Programmer ver is: 4.03