PMCR

I don't often answer posts where I don't know the answer, but I wanted to put in my 2 cents. My understanding of the current embedded Windows OS offerings (as opposed to the older CE offering) is that most standard Windows applications will run on the embedded OS, as long as the OS build has all the necessary dependencies configured during the build. CX One would fall into this category, but I don't know the specific dependencies that would be required.

There are 2 things that you need to do 1. As gtsuport pointed out, you need to enable the output conversion in the IO Table setup. This is only read on powerup or restart of the module, so cycle power after downloading the Unit Settings. That controls bit D21000.00. 2. You also need to turn on 2100.00 in the CIO area in your program. This is the bit that you can enable / disable while the PLC is running to turn on / off the analog output conversion.

File Name: CSCJCPSerialActiveXControl File Submitter: PMCR File Submitted: 15 Sep 2009 File Category: Utilities Free ActiveX Control for Omron CS1, CJ1, CJ2, CP1H, CP1L, CP1E PLCs using Serial (CV Mode Hostlink). Click here to download this file

Great questions. I would not say that either or is better. The ETN21 was redesigned recently (from a hardware perspective) and shares most of the internal design of the EIP21. They really just have 2 different purposes. For pure FINS applications, either one would do very well, with an ETN21 having a very slight advantage. If you think that you may venture into the world of EtherNet/IP, I would choose the EIP21, even if you never end up using EtherNet/IP. EtherNet/IP in a nutshell: Omron EtherNet/IP master modules (EIP21) can make what Omron calls Tag Datalinks (generically called Implicit Messaging) connections to Omron and 3rd party devices that use EtherNet/IP as a protocol. You set up Tag Datalinks through the Network Configurator for EtherNet/IP, which is part of CX One. You map the IO from the remote device into PLC memory, and the data exchange is automatic, and requires no ladder code beyond massaging the data to do what you want. Here is the only catch: you need a well written .eds file for your device. I say 'well written', because there are many devices out there with .eds files that are incomplete, inaccurate, or simply nonexistent. The biggest manufacturer of EtherNet/IP Scanners (Rockwell Automation) does not typically use the .eds files to establish communications to a device, so many vendors have created .eds files because they are required to by ODVA specification, but in reality, they have never been tested by a device such as an Omron EIP21 card that uses the information in the .eds file to make the connection. Most of the time we can massage the .eds file to overcome any problems, and once this is done, you will not have any problems. In the rare case that a vendor does not have an .eds file for their device, or the .eds file does not contain any connection information, communications to the device by EtherNet/IP will not work.

From a FINS perspective, the ETN21 and EIP21 are very similar. Both can send and receive FINS commands. The ETN21 was designed many years before the EIP21, and supports FINS, Email, Socket Services, and a few other IT type functions. The EIP21 was designed to support the EtherNet/IP protocol in addition to FINS. So the EIP21 can act as an Originator (master) to other EtherNet/IP Target (slave) devices such as inverters, IO modules, bar code readers, vision systems, and other EtherNet/IP protocol devices. The support for the EtherNet/IP protocol is the main differentiating factor between the 2 modules.

I have faced the exact same situation as you describe. The CIF41 provides great throughput when used on a somewhat isolated network, specifically a network without a lot of extra IT protocols and features like Rapid Tree Spanning and others that broadcast a lot of non PLC related packets.I have also solved those situations by using either an EIP21 or ETN21. For your application, either one would work, but as the ETN21 has more buffers for the FINS protocol, this may give it a slight edge over the EIP21.

Attached is an example of using the AT column to assign addresses. Omron will not be able to guarantee than a Red Lion screen will work with all data types, unless Red Lion has specifically modified their driver to support the NJ. The Omron NB HMI was modified to support the NJ, to handle FINS protocol differences like String data types. Having said that, as long as you stick to fairly basic data types, your should be fine.

The NJ does support FINS. To access variables, you do need to assign fixed PLC memory addresses under the 'AT' column in the Global Variables. The format for making Data Memory 0 (D0) would be %D0 in the AT column for a Global Tag. String data types are byte swapped by the NJ by FINS, so they will be a little bit of extra work. The FINS Routing Table information is Controller Setup / Operation Setting.

Until you can get a PING response, you will not be able to communicate.Check the Cable, upload the settings back into CX Programmer to make certain they are correct.Also, the table that you created only contains the node number and IP address of the PLC. Normally you list all IP addresses and node numbers of devices need to talk to the PLC including PCs and HMIs.

Are you running Wireshark on the same PC as the data collection application?If so, make certain that the correct port is being monitored.If Wireshark is on a different computer, you need either a managed switch with Port Mirroring or a true old 10 Meg hub. A standard Ethernet switch will not allow data packet snooping unless Wireshark is on the same PC as the application communicating with the PLC.

Here are some other things to consider: 1. The PLC is given a finite amount of time per Scan to service communications. By default, this is 4% of the previous scan time. That can be a small time slice. In the PLC Settings, on the Peripheral Services tab, you can allocate more time per PLC scan for comms. Uncheck Default, and put 50 in 'set time to all events'. This will allow up to 5.0 ms per scan for comms. But will also extend the PLC scan time by up to 5 ms. I would also consider using Wireshark to determine the actual response time of the PLC.

I can explain what is happening. Omron HMIs and PLC CPUs (excluding the Sysmac NJ) don't support Ethernet on the CPU. Ethernet is another module or an architecturally different part of the device, such as on the NS. When the command is delivered to the CPU, it is delivered by FINS addressing only, and the IP information has been stripped off at the Ethernet card of the HMI or PLC. So, when the NS or PLC goes to respond to an Ethernet command, it relies on the Ethernet module (or Ethernet portion of the NS) to construct the IP to send the response back to. In the PLC Ethernet cards, such as ETN21 or EIP21, the card has 'Auto Dynamic' FINS to IP conversion, which allows the Ethernet module to maintain a dynamic list of IP Addresses, and the FINS Node numbers associated with those IP Addresses. So, when your PC sends a command to an ETN21 card on a CJ, the ETN21 captures the FINS Node Number that your PC reports itself to be, and the IP Address of your PC. ETN01, ETN11, and NS Ethernet cards do not support the 'Dynamic' part of the FINS to IP conversion, they only support 'Auto Static' FINS to IP conversion. That means that the NS will respond only to devices on it's own subnet. What actually happens is the NS responds to an IP Address constructed of its own first 3 octets, and then creates the last octet from the FINS Node Number that your PC reported itself as. An example: Your PC is 1.2.3.4, and the NS is 192.168.1.100. If your PC sends a command to the NS (routed across the Internet), the NS will send the response to 192.168.1.4, because your PC will have reported its own last octet as its node number. Here is the only solution: If you are always programming from a location with a static WAN IP Address (your home, office, etc), you can program the NS with a list of FINS Node Numbers and IP Addresses. You would list all the devices (PLCs, PCs, etc) that the NS needs to communicate with. This is done in the Conversion Table in CX Designer. so, for example. NS: 192.168.250.2 PLC: 192.168.250.1 WAN IP Address of the router in your office: 68.84.215.203 (I just make that up) You would program in the NS: Node 1, 192.168.250.1 Node 100, 68.84.215.203 Then when you connect to the NS, you specify the IP Address of the router at the remove facility, and you uncheck the 'auto detect' box for the source node number of the PC, and specify 100. That way, when the NS goes to respond, it sends the response back to your local router, and since this is a proper response to a command, it is sent back to your PC without Port Forwarding needed in your router.

Sounds like you have it now.SSET is really just a pointer set.SSET does not clear data from the stack.Even a FIFO does not clear data from the stack (above the pointer),Let us know if you have questions.

Bits and Bytes You could run the stack entirely in DM or EM, and only do a SSET on startup if the first 2 words of the stack are 00000000. This would indicate a stack that has never been initialized (new machine). You can also use long binary compare instructions to check stack pointer (first 2 words of the stack). The pointer follows IR style addressing (DM0 = 0x00010000). Jay will remember a customer who we worked with who let an IR pointer get out of range a few times a day during debug. He ran amuck through the entire PLC memory map, changing high speed counter setup, motion card setup, etc. I often bypass the SSET instruction all together, and just do a MOVL to load the pointer (first 2 words are current pointer, next 2 are top of stack). I think Jay did this years ago to get a stack that spanned contiguous EM banks. The SSET instruction limits the size of the stack to 32,767 (if I remember correctly).

1) Are these the same EDS files that are found in Omron's Network Configurator Version 3.56? I suspect they probably are and my issue is with the Keyence software. The files will not register. Yes, those are the files from the Omron Network Configurator. I don't have the Keyence software, but those files will load in Rockwells RSNetworx for EIP. 2. Does the NE1A have a default Assembly or must it be defined using the Network Configurator? I have used the Network Configurator to set a custom amount of Inputs/Outputs and successfully connected to a CJ2M. I'm trying to use the CJ configuration to help me with the Keyence. Try this information. Thank you.

Agreed. Welcome back to the good side! Hope you are doing well.

Yes. CP1L-E does support a FINS Routing Table. Unit 250 is the built in port. CP1L / CP1H supports a FINS Routing Table using CP1W-CIF41. Unit 253 is the one of the left, Unit 252 is the one on the right. CP1E does not support a FINS Routing Table.

PDL You can keep your setup as is.I use Network Number of 0 for people not familiar with the ins and outs of FINS Routing Tables. you an keep your setup as is.If you don't already have a routing table in the CP1L-E, set Unit 250 to Network 1. 250 is the unit number of the built in Ethernet port.Then in the CJ2, use a destination network of 1, wth the destination node of the CP1L-E, and all will work.Make certain the FINS Node Number of the CP1L-E (in PLC settings) matches the last octet of the IP Address. Let me know if you have any issues. PMCR

The thread that you posted in is more than 8 years old. Current generation SCU cards have a Mode that you can select that directly supports Modbus RTU as a slave with no code or PMCR needed.Assuming your PLC and SCU hardware is new within the last few years, this is a much easier way to do Modbus RTU slave.

You are using a battery backed memory area (DM) for the background data manipulation for the PID instruction (C+7 - C+38). You should clear this area (D7907 - D7938) prior to starting the PID instruction. 'Stale' data in this memory area can cause the instruction to not function correctly. The other thing to check is the P_ER bit immediately after the PID instruction (before the SCL instruction). Put a normally open contact of P_ER and an output that you are not using (W511.15?). Monitoring this will tell you if the PID instruction is causing an error. If it is, the help for the PID instruction will tell you what might be causing the error.

Yes, Cognex SJ02 Works.smn is the correct file. The 02 is program 2. Program 255 would be FF in the same byte position. Beyond the single byte (programs 00 - 255) I don't know the correct byte / date layout.

See the same question here. http://forums.mrplc....p&fromsearch=1 http://forums.mrplc.com/index.php?showtopic=14494&st=0&p=70885&hl=c28p&fromsearch=1entry70885

Yes. If your PLC program looks like this, bit x will turn on at the DIFU instruction, remain on for Ladder 5,6, END, Ladder 1,2,3,4, and then turn back off when it reaches the DIFU again. <LADDER> 1 <LADDER> 2 <LADDER> 3 <LADDER> 4 <DIFU> bit x <LADDER> 5 <LADDER> 6 <END>

Try the attached. Recv.cxp

From your ladder code, it appears as though you are trying to execute 3 PMCRs at the same time. A port on an SCU module can only execute 1 PMCR at a time. You will need to create code to sequence through your PMCR instructions in the order that you want to use them. Another alternative is to use the code found here. http://forums.mrplc.com/index.php?app=downloads&showfile=867 It was created to allow comms to many devices, without the user worrying about the sequencing. Assuming your inverters support Modbus RTU, this should make your life a lot easier.