PMCR

The full implementation of 'Serial Gateway' involves 3 specific FINS commands. 2803 = CompoWay/F 2804 = Modbus/RTU 2805 = Mosbus ASCII Of these 3 FINS commands for Serial Gateway, only 2803 (CompoWay/F) is implemented on the built in port for CJ1, CS1, or CJ2. All 3 FINS commands are implemented in SCUxx modules, such as SCU21, 22, 31,32, 41,42. Basically a Serial Gateway FINS command is a FINS command, with another command wrapped up inside. So, for Modbus/RTU it is the Modbus/RTU command wrapped up in a FINS command. The SCU module then pulls the Modbus/RTU command out, calculates the CRC16, sends the command, waits for the response, wraps the response back up inside a FINS packet, and delivers it back to the original device.

As the DeviceNet network uses FINS routing, you cannot go online via EIP, and then switch to FINS. You can go online with CX Integrator via almost any other protocol and get to DeviceNet, but not EIP. I have posted a basic explaination of FINS Routing Tables on YouTube...

If I remember correctly, ~ June of 1996 was when the change from 2400 to 9600 for 'default' by DIP Switch 5 occurred.

W342 contains most of the documented FINS commands, but not all. Some specific commands are documented in the manuals relevant to the products, such as 2810 (EtherNet/IP Explicit Message). See here for a tool to help test FINS commands and CMND. The most commonly used commands are 0101, 0102 for reading and writing data. Other commands are application specific. http://forums.mrplc.com/index.php?app=downloads&showfile=948

File Name: FINS Color Coded Messaging Tool File Submitter: PMCR File Submitted: 09 Dec 2010 File Updated: 11 Apr 2013 File Category: Utilities The OMRON FINS Color Coded Messaging Tool was developed to assist users in understanding, testing, and debugging FINS messages. The Tool sends messages to devices such as PLCs via the FINS UDP protocol, and receives the responses for the user to interpret. Each Command or Response byte in the Tool can be color coded to identify unique sections of the FINS command. Each command, and optionally the response, can be saved for later use, and the color coding is saved with in the file. Once a command is successfully working in the Tool, the user can choose to build the corresponding CMND instruction to copy / paste into a PLC, if a PLC is the device that will send the FINS command in the users application. Version 2.1 updated 4/11/2013 to include auto generation of Structured Text code for the Sysmac NJ / Sysmac Studio. Click here to download this file

Pawel The RS232 cable from a V1000 will not work on a JX inverter. The JX series uses RS485, not RS232. You need to obtain the programming cable for the JX inverter.

Because you cannot add any more modules to the PLCs, I think that your original solution is the best choice.

From the NS / CS1 / CP1L on EtherNet, that will be OK. The CP1W-ETN01-US can handle comms to 2 devices. The CS1 will need to issue the SEND/ RECV instructions, as the CP1W-ETN01-US is only a comms slave. The only part that I am not familiar with is the config of the WE70 product. That is one that I have never used.

I agree with Sleepy Wombat. It will work in the configuration that you have drawn, with each converter appearing as a virtual com port. Another, and probably better solution would be to add an Ethernet card (CJ1W-ETN21) to each PLC. You will get better response from the PLC, faster setup, and a solution that can be maintained by more people in the long run.

I have not used the MS-4 Imager before. I have used the QX-Hawk and MS-830. The Service Code 52 is the UCMM Send Service code. This is sent the EIP module on the Omron PLC. The CPU is essentially sending a message to the EIP module with another message wrapped up inside. The service code sent to Microscan is the '45'. The .esp file is the Bar Code Reader setup from MicroScans Easy Setup Program (.esp). This was included as a reference of how I setup the bar code reader. In the image below, I show the message format on the left, and my data on the right. I have circled different parts of the message to show why I used certain data. The part circled in purple (starts '4503' and ends '2000') is what is sent to the MicroScan bar code reader.

Either the CS1W-ETN21 or the CS1W-EIP21 would be able to support what you are doing. To communicate between the CS1 and the CP1L, you would use SEND and RECV instructions in the CS1 to read / write data in the CP1L. You would also be able to program the CS1 and CP1L across Ethernet. The only area of concern is the communications with the NS screens. Are they communicating with the CS1 only, or are they also communicating with the CP1L? The CP1W-ETN01-US has a limited number of buffers, so the typical suggestion is to have no more than 2 devices communictating through the adapter.

FINS Gateway (now updated to include the CIP protocol for EtherNet/IP and called SYSMAC Gateway) is compatible with XP, Vista, and Windows 7 (32 bit). Any application that has API calls to FINS Gateway 2003 will also work with SYSMAC Gateway. SYSMAC Gateway is a software product that is sold by Omron, and is not something that can simply be downloaded.

Yes, the C200HS is completely compatible with the C200H. The C200H has a seperate memory cartridge, which the C200HS does not. All the memory is built into the C200HS. All the C200H I/O modules are compatible with the C200HS, and all the I/O modules map into the memory map of the C200HS identically to the C200H. When doing the conversion, be certain to transfer not only the program, but also the battery backed memory ares such as DM and HR.

Since you require a Null Modem between the PC and Printer, this means that both devices are wired as DTE equipment. So, the same cable that goes between the PC and PLC should also work between the PLC and Printer. The PLC will require that RTS / CTS (pins 4 and 5) be satisfied by 1 of 2 methods. 1. The printer supports RTS / CTS, and the cable correctly connects RTS and CTS on the PLC with CTS and RTS on the Printer. 2. Jumper pins 4 and 5 on the PLC to satisify RTS / CTS. In your ladder code, are you using the RS232 Port Ready to Transmit bit for port 2? This is A392.05 if I remember correctly. Monitor the Ready to Transmit bit while the PLC is connected to the printer. After you transmit, does the Ready to Transmit bit turn back on? If not, this is a good indication of RTS / CTS not being satisfied.

Morten Yes, Implicit is the way to go, when possible. In the case of the NS, Explicit Messaging is used, but the NS sends the Explicit Messages to read / write PLC memory, so no code is needed in the PLC to do this.

Morten There are 2 ways to transfer data on EtherNet/IP: Explicit Messaging and Implicit Messaging (Omron calls this Datalink). When possible, Implicit Messaging is best, as it requires no ladder code. The links between devices are setup using the Network Configurator for EtherNet/IP. The AB to Omron Implicit Messaging works just the same on a Cj2M as any other CS or CJ PLC with an EIP21 module. The interval of the data transmission is setup by the RPI (Requested Packet Interval). Here are some scenarios when I have used Explicit Messaging from an Omron PLC, just to give you an idea. 1. Bar Code reader that does not support Implicit Messaging (MicroScan) 2. AB PLC (SLC500, MicroLogix 1400) that does not support Implicit Messaging 3. AB PLC that is password protected by the OEM, but they expose data by Explicit Messaging 4. Vision system to access functions not accessible via Implicit Messaging (changing programs on a Cognex Insight system)

File Name: Modicon PC0085 Manual File Submitter: PMCR File Submitted: 30 Aug 2010 File Category: Manuals, Tutorials Older Modicon PC0085 manual. This manual was scanned by BlueByu, not by me. Giving credit where credit is due. Click here to download this file

Industrial Projects I understand what you have now. I would highly recommend adding an SCU module to the project if you are going to communicate Modbus RTU to the drives. You will save a great amount of time using the pre-written code to do the Modbus communications using the SCU module and the Protocol Macro that I have written for the SCU. PMCR

niko Sorry about that. I should have caught that. Simply multiply the BCD counter value by 2 and then convert this into HEX and use in the DR.

niko I think that you are on the correct path. One way to use your counter is by using DRx, IRx. Example: DR0,IR0 as an address. *F DR0,IR0 H40 H42. DR0 is an offset from IR0. If IR0 points to D100, and DR0 = 9, then DR0,IR0 would point to D109. Note: You do not need to use the DR and IR as numerical pairs. DR5,IR0 is OK. DR15, IR14 is OK. I normally use DRx, IRx but DRy,IRx is also OK.

I think that Bits and Bytes is giving sound advice as usual. This is a perfect PMCR application, and Bits and Bytes is a top notch PMCR programmer. The receive buffer when using a PMCR can be set as high as 1000 bytes, vs 255 when using No Protocol mode. New products: There are also some new SCU modules available (CJ1W-SCU22, 32, 42) that when used in conjunction with a CJ2M or CJ2H can achieve higher throughput in No Protocol mode. There are new DRXDU (Direct Receive Unit) and DTXDU (Direct Transmit Unit) instructions that execute immediately in scan when using a CJ2M or CJ2H.

elel65 We can debate what the best way to do this is, but until you can figure out if the Proface unit can send any command that you build (specifically the command to change PLC modes), it is pointless to debate. Is the Proface HMI communicating Ethernet or Serial? If it is serial, what driver are you using? There are 2 ways to do what you want. 1. Put the PLC in program mode and directly control the PLC output points with SET / RESET HMI buttons or momentary HMI buttons. 2. Use Task based programming as suggested by BITS N BYTES. This would be my recommendation, as it will work with any manufacturers HMI.

JCLR In the world of AB PLCs, you can do a 'Tag Datalink' (generically called Implicit Messaging) between an Omron PLC and a AB PLC only if the AB PLC is a CompactLogix or ControlLogix. MicroLogix PLCs are not capable of Implicit Messaging (even to other AB PLCs). MicroLogix PLC are only capable of Explicit Messaging. Even with CompactLogix and ControlLogix, it is sometimes necessary to use Explicit Messaging (such as across the Internet, OEM has password protected the AB PLC and you cannot setup the Implicit Messaging, etc). Below is a link to the post of my code. I have tested this on the ML1400 with built in EtherNet/IP, but I do not have a ML1100 to test with. I strongly suspect that the ML1100 will work just like the ML1400. As the code is very specific to what I setup, I would suggest not trying to change the code (other than the IP address) until you have it working. The PCCC protocol wrapped up in EtherNet/IP is rather complicated. If you do not need the Floating Point read / write, simply delete the 2 Floating Point sections from the code. Each section is intended to be able to run by itself. http://forums.mrplc.com/index.php?showtopic=19679