PMCR

Rob That is interesting. On Modbus RTU, the Modbus RTU master does not get assigned a Node Number. Only the slaves do. Can you post the documentation that you are looking at?

Dick Great point! Not only the RXD / TXD / SG, but also make certain that RTS / CTS are satisfied, either by jumpering on the Omron side (pins 4 and 5) or connecting through to the scanner RTS / CTS.

Double check a few things: 1. Check that the port is setup to be 'RS-232C' mode, and that this setting is downloaded to the PLC. Sorry. I know this is obvious. 2. Check that DIP Switch 5 on the CPU is Off. If both of those are correct, and the wiring is correct, you should see data in A393. I like gtsupports idea of disabling the RXD. This would leave the data in the buffer.

The CJ2M needs a routing table. I used FINS Network 1 for ethernet. Use CX Integrator for this. If you don't know how to use CX Integrator, watch the Youtube vidoe here....http://www.youtube.com/watch?v=kDYP-bUMzEg The CP1 also needs a routing table. Note: I have the CIF41 in the left hand socket of the CP1H. If you use the right hand socket, the SIOU is 252. Cycle power to the CP1 after transferring the routing table. Below is the code SendRecvExample.cxp

speakerman Great feedback. The reason that Omron Ethernet modules require the setting of the Node Number (in HEX) to match the last Octet of the IP Address is that the FINS protocol (around since 1990) defaults to the last octet for Ethernet. You can make custom setting in the Ethernet modules for other situations. The beauty of this is that FINS is transparent across network types. This week I was working with a colleague (another Omron Expert) on Omron to Brand X communications. What we found was that Brand X had numerous variations of Ethernet protocol, depending on what specific processor was in use. FINS is consistent across processor and network types.

CP1W-CIF41 is really only a FINS Slave (UPD and TCP). No EtherNet/IP. To share data from a CJ2 PLC, execute SEND and RECV instructions in the CJ2 to send and receive (read) data to and from the CP1 PLC. If you need more specifics and an example, please provide the IP Address info for the CJ2 and CP1.

What is the PLC power supply? If it is a PA216, and the supply voltage is 110, check that the jumper is in place for 110V.

The Node number does not matter if you specify node 0 in your FINS command, however this format would never allow you to route through different levels of FINS networks. If you specify the Node Number of the PLC in your FINS command, then you need to set the Node Number correctly.

Dick It is a software setting in 'Settings' , on the 'Buit-in Ethernet' tab. Set this to '101' to match the last octet of the IP.

As far as Ethernet, I am not aware of any FINS differences for the CP1L-E, other than a few new FINS commands. The 'Direct Connection' feature is an addition to the Ethernet functionality that allows you to connect directly to the PLC without knowing the IP address. This is done by using a Multicast IP address. This was done because the USB port was removed for the CP1L-E, and the user needs a quick way to be able to connect directly. I suspect that the reason your FINS/TCP program will not connect is that the node number in your project is 0. Change this in the Settings, so that the node number is the same as your PLCs last octet of the IP address, and I suspect it will work for you. Cycle power after changing this setting.

Dick Sorry the SuperMon did not work. It does have some limitations, as it is a VB6 project. It is strange that you have to send NULL characters out the port. I have never had to do that. Attached is a simple echoback program. Whatever comes in the port (as an entire string, marked with a terminator) is sent back out the port. It shows the way that I handle port resets. Could you try this in your PLC to verify basic operation and cabling? Note: The ethernet port is not setup to match your settings, so the comms setup does not match yours, and the Ethernet port setting in the project does not match yours. Do you have RTS / CTS jumpered on the CIF01? (pins 4 and 5). Port 2 Echoback.cxp

Interesting. Are you using a terminal emulator that sends character at a time, or line by line? SuperMon sends line by line, which may help on the emulation. http://forums.mrplc.com/index.php?app=downloads&showfile=575 Here are a few other things that I have noted. 1. In Com_Handler, you have a P_First_Cycle executing an @Set. This will never execute. The @ requires a rising edge, and the First Cycle flag by definition has no rising edge, only a falling edge. I doubt that has anything to do with what you are seeing, but it will not reset the port on startup. 2. When you execute the RXD, you are reading &255. I would recommend reading a size of A393 instead. With Supermon you can also send multiple strings at once (see pic below). SuperMon.bmp

A few other cases where you would see this. 1. The code is in a Task that is not running. 2. The code is in a subroutine that is not being used. 3. The code is in a section that is after the END statement. 4. The code is in a section that is after subroutines (like below) <code section> <code section> <code section> <subroutines> <code section> <END>

Can you post the snippet of the code for the serial comms? I can troubleshoot on my end.

If you want to do a FINS / TCP send, you must setup a FINS TCP Client connection to your PC in the Ethernet setup of the CP1L-E. For this to work, you must be running something like SYSMAC Gateway, which will respond as a FINS/TCP client.

Here are some basic diagnostics that will point you in the right direction. 1. Add the P_ER code as IO_Rack suggested. This is always a good starting point to see if the instruction generates an error. 2. Make certain that you have downloaded the code. In the haste of testing, we sometimes forget to download the code to the PLC. 3. Look at the output LEDs on the PLC. Are they turning on, or simply remaining dark? 4. Can you post a copy of your code? There may be something else that we can't see from the pictures. If you can, I can load it into a CP1L and test it.

NASIR When I do PID in an Omron PLC, I use '9' for digit xxXx in C+6. Instead of 0404 in D00036, try 0494.

Great. Thank you for the feedback. As a user of the code (and documentation), can you point out anything that was not clear for a user implementation?

The link below will provide you Modbus RTU master code for Omron PLCs that will be the most efficient possible. Reads are sequential, and 1 starts immediately after the previous one finishes. Writes are event driven, and will occur immediately after the previous read has completed. http://forums.mrplc.com/index.php?app=downloads&showfile=867

I think I can fill in the gaps. I am an Omron guy first, and a Modbus guy second. Jay Anthony taught me everything I know about Modbus (and most of what I know about Omron). I developed the generic Modbus RTU master code at the link below for someone who is not a 'Modbus Guy (or Gal)', but is willing to work with Modbus. Download the code. There is a manual that shows you how to setup the Omron PLC and fill in the DM areas to make an SCUxx function as a Modbus Master. It has 10,000 + downloads, so I believe that others are finiding it useful. http://forums.mrplc.com/index.php?app=downloads&showfile=867

Lots of questions. Specifically, what type of PLCs the PLCs? Both CS or CJ PLCs? Are they both sending to each other? Do any error lights turn on on the ETN21? Most importantly, what is happening in the ladder code? The FINS SEND instruction uses a Logic Port in the setup of the command. There are error codes associated with the logical ports. What does this show you? Can you post the code?

Managed Switches on EtherNet/IP provide several benefits, but are not necessary in most systems. The most useful function of a managed switch is something called IGMP Snooping, which stands for Internet Group Multicast Protocol Snooping. This function is used when a device is set to Multicast data, which is similar in concept to a broadcast. When using Multicasting on an Unmanaged Switch, all devices attached to the switch recieve all multicast packets, which increases the network traffic on each node. When using Multicasting on an Managed Swtich with IGMP Snooping, the switch has a subscriber table for each physical port on the switch, and which Multicast packets each device subscribes to. So, only the devices that request specific multicast data will recieve it. In most applications, multicasting is not necessary, so unmanaged switches will work just fine, as long as you remember to configure each connection as 'Point to Point', not multicast. The feature that I use most often on managed switches is Port Mirroring. Port Mirroring allows Wireshark running on my PC to monitor all traffic between a PLC and another device (IO Block for example). The Managed Swtich is configured to mirror all the traffic on one particular port (the PLC port for example) out another port to which my laptop is attached. The other key to understanding EtherNet/IP communications is the concept of RPI, which is Requested Packet Interval. Each connection to a device is made at a specified RPI, which the user can set. The RPI is set in ms, and is the interval that the data should be transmitted from the device. So, a Congnex camera can be set to transmit data every 50ms, which is a relatively low network load. IO blocks, which may need faster response, can be set to a 10 ms RPI for faster response. By setting the RPI for each connection at an appropriate value, it is easy to control the amount of network traffic on EtherNet/IP, and setup a very viable network, using an unmanaged switch.

What specifically is not working? Do the LEDs on then outputs of the CP1L appear to be turning on when you command by PLS2? If so, then it is most likely a wiring problem or setup of the stepper. If the outputs are not turning on, then it is a programming problem.

The latest version of the Modbus Master code at the link below supports 2 simultaneous modbus ports. http://forums.mrplc.com/index.php?app=downloads&showfile=867

Something else that I ran into while testing this. If you have a 'lab' PLC that you have used for other things in the past, clear out the DM area that configures the module. For you, that is D30,100 - D30,199. Set them all to 0000. Then download the configuration of the module through the IO table. I had some 'stale' data' in the DMs from something else I had done before, and it was causing me some problems.