PMCR

PdL You are correct as usual. The CIF41 has a frame length of 1000 bytes as a limit (could be 1004, I don't remember). That frame length would not be a problem unless the command or response was longer than 1000 bytes. An 0501 should definitely be a shorter response.

Most likely it is a FINS Routing problem. A 'Quick Fix' is to set the FINS Net and FINS Node to 00 for the source and destination. So Local Node Net = 00 Node = 00 Unit = 00 Remote Node Net = 00 Node = 00 Unit = 00 This will probably fix the issue. The better way to fix it is to use proper FINS routing. I did a quick video on Youtube last week on how to setup a FINS routing table. You would use Unit 253 and 252 for sockets 1 and 2 (yes that seems backwards).

You actually need a lot more than what comes with CX One. You need a full installation of FINS Gateway, which is purchased seperately. I added the online functions for a specific project that I was doing, not for 'normal' use. Alternately, you can use CX Programmer to monitor the IRs, and then convert from the RAW addresses to actual memory using the conversion part of the IR Monitor.

Easy Button I would not say that this is a bug. The Omron PLCs have 1 or more EM (extended data memory) banks. They are typically denoted as E0_1, where the '0' indicates the EM bank number, and the '1' indicates the channel in the EM bank. E0_1 is an explicit reference to EM bank 0, channel 1. When you use the syntax E1, this is a different way of accessing EM. E1 is a reference to channel 1 within the 'currently selected' EM bank. This type of addressing is a carryover from the old days (C200HX), when this was the only way to address EM banks. So, there is no actual 'E1' memory area, just address 1 within the selected EM bank. Since the compiler has no way of knowing what bank number is selected, you are prevented from creating problems with overlapping memory. If you simply use E0, E1, etc, you can address all the EM banks. If you truely need to switch between EM banks, use IR /DR indirect addressing to accomplish the same thing.

The module will write FFFF to unused entries. You do not write these in the DM area. You need to remove them via the web interface.

Looking at the DM Addresses, you still have 2 entries in the IP Address table, and 3 entries in the IP Router table. Remove these entries, and I believe the errors LED will go away.

CX Integrator is not required for this module. I have successfully setup a CIF41 using 192.168.250.1 as you have shown, and I have no errors. I still believe that it is a setup problem in the module. Can you capture a screen shot of the DM area for this module? It should be D32000 - D32299 or D32300 - D32599.

The Web Interface of the CIF41 is obviously different from ETN21. In the IP Address and IP Router tables, you can only see one line at a time. Try going through each 'line' one at a time to see if you have anything setup. Click '01', and then Show. If there is an entry, delete it. Click '02', and then Show. If there is an entry, delete it. Click '03', and then Show. If there is an entry, delete it. ....

A few things to change to start out simple. In Picture # 1, change the FINS/UDP option to Destination IP address is changed dynamically. In Picture # 1, uncheck Use FINS/TCP Protection Function. In Picture # 2, delete any and all items in the IP Address table. If a node is on the same first 3 octets (192.168.250), you do not need to list it here. In Picture # 3, delete any and all items in the IP Router table. Unless you are accessing FINS nodes on other segments, you do not need this. In Picture # 4, delete the FINS/TCP Server settings. These would be connections from this PLC to other PLCs via FINS TCP. You should not need this.

Frank The NULL characters will be received by the PLC, and stored in the PLC as character 00. In the world of PLCs, these are just as valid as any other character. If you received NULL characters, you may need to remove them. Obviously, this depends on your protocol and application. The PLC does not handle NULL any differently if you are using a serial port or a TCP socket, if this helps.

Andy_PSorry about that. I was obviously way off on my first post.I took a look, and I do not have an NT21, and my 2 NT31Cs (which should function the same as a 21) are out on loan.I was referring to loading an updated 'system' in the NT. Not possible in PLC.

Jay You are correct. Taking a look in the manual, it appears as though the newer models should be able to access the higher DMs, as well as the W area, etc. The model that Andy_P has may require a newer 'firmware' be loaded.

I doubt that the NT21 will be able to connect to any DM above 9999 in any Omron PLC. The N21 was designed ~ 10 years ago, and at that time there were no PLCs with DMs above 9999, so I don't think the NT Link protocol in the NT21 will support high DMs. You also probably cannot access the W area in the PLC. Same issue. 10 years ago, there weas no W area. I would consider the NT21 an older product. There are plenty of other Omron touchscreens that could address the areas above D9999, the W area, etc. The NS, NV, NP series would all be capable. What data are you trying to access in the DM30,000 + area? Easy Modbus by any chance? If so, can you copy data from a lower memory area into and out of the D30,000 area?

Frank Glad to help. Hopefully those examples will also help others. Good luck on your project. PMCR

Frank For your generic Socket Service app, the Modbus TCP is a little too specific. Attached is a more appropriate example (created from the Modbus one). Note: The addressing that I am using is for an ETN21 configured as Unit 1 (on the single digit rotary switch on the module). This sets 2 of the addresses, and 1 parameter input to each FB. The 2 addresses are 1534.13 (Unit 1 Socket 1 message received) and D30101 (Unit 1 Socket 1 Number of Bytes Received). Generic_TCP_Application.cxp Also attached is a TCP app that I did several years ago for a customer (no function blocks) to communicate with 3 Microscan QX-830 bar code readers. Microscan_Bar_Code_Reader_via_TCP_MS_QX830.cxp

File Name: Generic TCP Client and Server in VB6 File Submitter: PMCR File Submitted: 12 Mar 2010 File Category: Utilities The attached 2 VB projects are 'generic' TCP client and TCP server applications that allow the user to test PLC socket services, as well as other non-Omron applications. I cannot take author credit for these 2 tools, but they are items that I use frequently. Click here to download this file

The PLC is on the same segment (same first 3 octets and same subnet mask). When it is setup properly, the PLC has no way of knowing that it is on a wireless LAN.

I connect regularly to Omron PLCs on Ethernet through a wireless router. My normal configuration is PC to Router on wireless, and then router to PLC is wired. I have also put the PLC on a wireless access point, with no problems.

I will try to help with the explaination. If I misunderstand your questions, and I am stating the obvious, I appoligize. The values of the octets of the IP address are passed in as Inputs to the FB. When you look at the inside of the FB, there are 5 types of variables: Internals, Inputs, Outputs, In Out, and Externals. These types have different ways of interacting with the code outside the FB. The DestIPAddress1, DestIPAddress2, etc are Inputs. The fact that they are inputs indicates that they are passed into the FB as Parameters, so they do not take their value from the initial value setting in the FB. See the attached image. Internals will use their initial value until the ladder code changes them. In reality, the Initial Value is very seldom used in Function Blocks.

The FBs used are generic TCP FBs for opening, closing, sending, and receiving. The only thing that really makes this Modbus TCP is the data that is sent in D200 - D205, and the port number used on the remote node (port 502). Basically, to do Modbus TCP, you establish a connection to port 502 on TCP, then start sending Modbus commands (with a few other items like MBAP Header).

papa francisco Good luck on your project. I like your 'can do' attitude! Modbus TCP does use the Modbus protocol, wrapped up in TCP.

papa francisco Welcome to the forum. I will answer some questions for you, and then ask a few of my own. Your most specific question was the difference between Modbus TCP and TCP in general. (TCP = Transmission Control Protocol). I will simply the answer, so others may disagree with a few points in my explaination. TCP is really more of a delivery protocol, than an actual communications protocol. TCP is the mechanism by which 2 devices connect to each other, to be able to pass messages back and forth. The data that is passed back and forth once the connection is established is really the communications protocol. Examples: Modbus TCP. This is actually a communications protocol used over a TCP connection. It is referred to as 'Modbus TCP' so that it is not confused with the other Modbus protocols such as Modbus RTU, Modbus ASCII, or Modbus Plus. Modbus TCP is basically the Modbus protocol on TCP. FINS TCP. This is the Omron FINS protocol over a TCP connection. Another popular communications delivery protocol is UDP. (UDP = User Datagram Protocol). UDP does not use a 'connection' between 2 devices. It is much more like RS232 comms for Ethernet, where a device sends a message to another device, without knowing that the device is connected on Ethernet. The software application must look for a response from the device to know that the message was delivered. Typical Omron Ethernet communications are done on UDP, not TCP, as the FINS protocol looks for a response from the PLC. There is also FINS TCP, but from my experience, it is used less often. Now a few questions. If your ultimate goal is to communicate to Omron PLCs on Ethernet, you would be much better off using the FINS protocol, that way you only need to write the PC part of the communications. If you use Socket Services in the PLC, then you need to write the ladder code to do the socket services, and handle the protocol (that you create) in ladder. In the world of Omron, Socket Services are normally only used to communicate to devices that do not use the FINS protocol. I have use Socket Services to communicate with bar code readers, torque wrenches, and other devices that have no way of using the FINS protocol. So my question to you is: are you trying to learn TCP communications, or how to communicate to Omron PLCs? The answer to this will help us to steer you in the right direction.