Contr_Conn

Chris RSnetworx v9 does not work when V21 of logix installed You must install ver 21 of RSnetworx Also - I would recomend you to install RSlinx 3.60 - it is more stable and has some important fixes

Your SI was correct - he did not do anything This is a known "497 days" anomaly that was corrected in 2005 - just upgrade FW to 5.50 or higher (7.xx is better) and it will take care of it. It was a service advisory on this back in 2005

in this case open sockets will not do anything for you since they can redirect data connection only, not RSlinx traffic If you have one PLC only then you can use you router's port forwarding for TCP ports 44818 and 2222 A much better solution is to use a router with VPN capabilites and install VPN client on your computer

Jeff With Ethernet TCP/IP is a transport layer, it delivers a payload packet of data from one device to another How data organized inside a packet and how devices respond to a specific request called protocol Rockwell PLCs talk on the Ethernet using Etnenet/IP (CIP) protocol (older PLCs use CSP protocol) If a 3-rd party device does not speak CIP or CSP, then it will not undestand or be able to send data to a PLC (MLX1400 in this case) In this case open sockets (or raw sockets or raw ascii) comes in play - it allows RA PLCs to read non-CIP data and respond to it. Typically used with non-CIP RFID readers, barcode scanners, printers. 1756-EWEB, 1768-EWEB do it for logix platform, MLX1400 does it also In a near future 1756-ENxT[R] will have open sockets too. Profosoft modules can do it as well.

Are you talking about RAW ASCII data or just redirect RSlinx or HMI to port 81?

Most likley this has nothing to do with power. In RSLogix 5 under Tools menu select Extract PLC5 Memory Loss Fault data file Contact Technical Support to analyze this file Log File will be erased if battery disconnected. Reloading the program will not erase it.

I did not go through your program, but as I said before, you should be using TN 33672 that already has all proper timing, sequence and error handling you need FYI: unlatching DN and ER bits is ILLEGAL in controllogix and can cause unpredictable operations.

I deleted post I had earlier today as I misunderstood what sample you have. If you are looking for a TCP server sample then you should be using TN 33672 and test application assosiated with it TN 32962 is for demonstration purposes only, to show you instruction sequence and can't be used in real appllications as it does not have any error handling or out of sequence events. As paulengr said - it does not check MSG DN bits and any errors. What ports to use? have you try to google it? - it is up to you - these are Ethernet rules have nothing to do with EWEB. Page 143 of the user manual tells you what ports are in use by the EWEB - all other numbers are up to you. What is Instance Number? In general Instance is a key part of CIP specification and is a pointer to the memory location of the specific object. In case of sockets Instance refer to a "memory location" where socket was created. Again, this described in the user manual page 143.

Path 0,1 is incorrect, it will be 1,1 Bob: you don't add 2, <IP address> to the path as message sent to EWEB not to a remote device controlsdude: can you specify exact errors you are getting with server application and steps to duplicate them - I am not aware of any problems - all socket samples working just fine.

ControlLogix can't handle vertical mounting as it needs heat dissipation. Only Flex I/O is approved for vertical mounting. See TN 34499 for details

As far as I know catalogs from this page: http://www.ab.com/catalogs/ are available as printed publications from your local distibutor or AB office. I can't speak for all catalogs, but I got Safety, Industial and Connectivity catalogs few months ago. So talk to your local office.

V17 does not support L55's anymore V16 (FW16.21) is end of the road for them along with flexlogix. You must flash motion modules if you have them to V17 also. All comm modules are compatible with V17 but it is always good idea to keep all communication modules at the latest major/minor rev no matter what controller version you have

To finish our SRM Clock conversation - see TN 57158 - this is exactly what you want to do. If you switch primary to program mode then secondary will go to program mode also - this is done by design. Secondary always follow the primary. You will have to initate switchover first and after that you can put secondary (former primary) to the program mode.

Check with E-H, I believe they know about this issue, at least I heard something similar for sister product RA uses.

CLX does not have "get local time" as 64 bit value, it has only GMT as 64 bit valueLocalTime available in PLC as DINT[7], but not implemented in SRM. To build 64bit local time from GMT you will need 64bit multiplication that is not available in CLX yet. Technically you need this only if you want to set time programmatically. RSlinx GUI sets it to workstation time correctly.

Ok, here is what I got so far: Attribute 6 is not implemented in SRM. When you read CST from controller (GSV) it comes as GMT value When you write it to SRM (attribute 11) SRM will be set as GMT So both devices will be using same CST Problem is that SRM does not have Time Zone offset implemented If you read time from controller properties online it will display time as Local Time, applying time zone offset found in PLC. If you read SRM properties it will display GMT (no time zone offset in SRM). Also it looks like SRM configuration tool does not apply workstation Time zone to display correct time. It looks like you can add time zone offset before sending message to attribute 11, but luck of 64 bit math makes these calculations complicated. I will try to get more information about this later on.

I am not sure what value you are writing to it - your V16 controller uses GMT, and SRM attribute 11 is with local offset. You can try attribute 6 (UTC time), but I never tested it and can't say if it works

What redundancy version you have? In V16 attribute number changed due to new clock format. It is now attribute 11 (0B-hex) See TN 54971

Bob, Unfortunately MSG and AIOs are not very friendly as you found, you must have external messgae tag that technically kills its purpose as you have to configure this tag externally. Here is a "Workaround" for this, I really don't like it, but this is the best solution so far. - Create AOI with message, do not export it to L5X - Create a rung of logix with this AOI, including MSG tag and configure it - Select this rung (or rungs) and exprot them to L5X. It will save all backing tags, definitions, AOIs etc. Next time you need AOI, import whole rung instead of single AOI, it will create all data types and tags for you. Take a look at TN 50122 - it is not EWEB EMAIL related, but shows how use MSG in AOIs

For DeviceWho message configuration see tn 55301 and 55305

Class 1, Instance 1, Attribute 1 is "Get Device Identity" object. Look at the data returned as "ASCII" and you will see device description Did you try TWControls parameters?

"Class or Instance not supported" message comes from B&R and it means that they don't understand class or instance that you put in your CIP message. Do you have example from B&R? if you do then post it here along with your program and someone will take a look.

You don't need EDS for 2.54, they should be already there,

RSlinx 2.43 is 5 years old and it has no idea what 1768-ENBT can do. It does not know anything about this controller as well. To make your life easier install current version of RSlinx (2.54) and it will take care of it. As alternative you can try to add EDS files for ENBT, backplane and controller, but I would not recomned to go this route.

I think this is the best explanations that I saw for COP/CPS instruction functionality as well as UID/UIE. Recently one of my customers experienced short time local I/O connection loss while using CPS instructions with very large arrays of internal tags. I was told to check this technote and replacing CPS with UID/COP/UIE resolved the issue.