PMCR

BobB The FGW side of Sysmac Gateway is mostly unchanged, with a few exceptions, mostly in the Ethernet unit. You can specify a different UDP port for the PLCs than for Sysmac Gateway (only supported by more recent ETN21 (1.3 and up??) and EIP21. In Combined or Table FINS to IP conversion, you can also individually specify the UDP port number for each PLC. This is useful if you are using port forwarding in a router to forward to multiple PLCs with different UDP port numbers. I have also been working with CX Complet through the CIP side of Sysmac Gateway, and reading/writing data from VB by Tag Name, not address. This is a nice feature if you are using CJ2. Let me know if you have any questions about the setup / operation of the CIP side of Sysmac Gateway. PMCR

I am not running Vista, but we have many customers who are running Vista with CX One version 3.0x. Vista 32 bit was not officially supported until CX One version 3.0x. For CX One version 3.0 On your CX One CDs or DVD, you should be able to find /drivers/USB/Vista/PLC_NS This is not in the CX Server directory on the CDs / DVD, but in a folder called drivers on the root of one of the CDs or DVD. I have also included the files below... I don't know how they will work with CX Programmer 7.xx. Vista32bitPLCDriver.zip

GregaG Sorry about the mistakes. I did not get a chance to test, and I made some copy / paste errors. 1. You are correct about the first word of the Send table. This is the size, in words, of the table, including the first word (which is the size). So, where I have 4, this is 1 word (size), 1 word (node number), 1 word (register) and 1 word (data). If the table started at D1000, then you would simply do a MOV(021) #0004 D1000 in ladder. 2. Logical ports. There are 8 logical ports on the CJ1 / CS1 (64 more on CJ2). These are really buffers between the CPU and a communications module (DeviceNet, SCU, ETN21, EIP21 etc). They are only used when you want to send something from ladder out a module (Explicit message for DeviceNet, PMCR or TXDU / RXDU for SCU, FINS Send for ETN21, etc). Your understanding is correct, in that the #0110 goes with A202.00, #1110 goes with A202.01, etc. Nothing more. I typically use 1 logical port per physical port, unless I have more than 8 ports. So, I would use SCU 0, Port 1 -> Logical Port 0 SCU 0, Port 2 ->Logical Port 1 SCU 1, Port 1 -> Logical Port 2 SCU 1, Port 2 -> Logical Port 3 SCU 2, Port 1 -> Logical Port 4 SCU 2, Port 2 -> Logical Port 5 SCU 3, Port 1 -> Logical Port 6 SCU 3, Port 2 -> Logical Port 7 You can share logical ports across multiple physical ports, but only 1 physical port can use the logical port at a time, so you could not start 2 PMCRs (on different physical ports) at the same time if they share the same logical port. 3. Annotations. I assume that you mean the annotations in ladder. Simply right click on a any ladder element (contact, coil, instruction, timer, counter, etc) and select Properties. Enter the annotations there. Also, make certain that 'Show rung annotation lists' is enabled in the Options of CX Programmer.

Please upload this tool. I will test with several CF cards to see how it works with NS terminals.

GregaG Great job on starting out with PMCR. This is not an easy topic to try on your own, but it is very powerful. Attached is a modified PMCR that will allow you to execute function codes 03,06, and 10 in Modbus. There is an Excel sheet included that shows how to setup the data. I have not tested this on an actual Modbus device, but I do believe that it is correct. There is a tool that you will find very useful in troubleshooting Protocol Macros. Each port has a buffer to record the data send and received on the port. CX Protocol can trace this data. While online, select the SCU that you are using in the tree view of CX Protocol. Then click on Trace 1 (this is for Port 1) exactly where I circled in red, and then right click and select Start Trace, Continuious Trace. Run the PMCR, then on the toolbar, click the Upload Trace icon, and click Yes or OK to stop the trace and upload the data. modbus_JCH.rar

Sysmac Gateway is the correct name. FINS Gateway was the 'Gateway' into the world of 'FINS' (from Windows), when version 1.0 was released in Japan. Now that CIP, Toolbus, Sysway (Hostlink), Sysway CV (CV Mode Hostlink), and FINS (on Ethernet, Controller Link, Sysmac Link) are all supported, the name has been changed to 'Sysmac' Gateway. The 'Gateway' into the world of 'Sysmac'. Just my 2 cents.

Sounds like RXDU would work just fine for your application. The 'Unit Number' in C+1 refers to the SCU41 unit number, not a unit number in the serial string.

You have 2 choices for ASCII comms on an SCU41. TXDU / RXDU instruction: Requires CJ1x-CPUx version 3 or later ,and an SCU41 of version 1.2 or later. You would set the port for No-Protocol Mode. All strings would be built in memory (DM, CIO, etc). You would use the TXDU instruction to send and the RXDU instruction to receive. This is easy for simple comms protocols, but gets cumbersome with complicated communications, checksums, etc. PMCR instruction: Can be used on any CJ and any SCU. You would set the port for Protocol Macro Mode. You would use CX Protocol to construct messages, steps, and sequences in a tabular setup. There are some advantages to PMCR (built in checksum calculation, timeout and retry settings, less ladder code), but also more complication. PMCR is not something that is easy to pick up on your own, but once you do, you will never go back to TXD/RXD or TXDU/RXDU. How complicated is the protocol, and what types of strings are required for the application?

The CS1D is made by Omron, but not in the USA. It is either Japan or China. Last I knew it was Japan.

Sysmac Gateway is released. It includes both the CIP and FINS drivers. It does support CJ2 via FINS Ethernet, EIP, USB. USB also supported for CP1H / CP1L. It works on XP and Vista (both 32 bit), but not 64 bit editions. It also works on Server 2003. There is a new Active X Control for Sysmac Gateway called CX Compolet (.net only) that allows reading by tag name. Currently no OPC server to read by tag name. I can post more info, as well as screenshots, if requested. The biggest thing that Sysmac Gateway brings to the table in the EIP world is the ability to have the the PC (using Sysmac Gateway Event Memory) participate in the PLC Tag Datalink. This brings the data directly to the PC, and the applications can read directly from event memory using a FINS Gateway driver pointed at Net 0, Node 0, Unit 0.

What you are seeing is the difference between the ETN21 and the NS in terms of Ethernet. The ETN21 has the ability to 'remember' the IP address of each remote FINS node, when using the 'AUTO:DYNAMIC' FINS to IP conversion. The NS does not have this capability. That is why it is necessary to program the IP address of the remote router (ie home, hotel, etc) in the NS to allow remote programming. The NS behaves like an ETN11, as opposed to an ETN21. The ETN11 had the same limitation. Another way that I have handled this issue when many NS and PLCs are in 1 facility is to have 1 PLC with 2 ETN21 cards. One ETN is connected to the router, and all Internet traffic (for programming the PLC or the NS) goes through this ETN card. The other ETN card is on an Ethernet network with all the other PLCs/ NSs. This is one reason that Omron supports loading new screens through a CF card. This is easy for someone in the plant to do.

The NT30 and NT31 handled this differently. On the NT30, the screen could be controlled by writing to the first word of the PT Control area, and the current screen number could be monitored in the first word of the PT Notify area. On the NT31, the screen can still be controlled by writing to the first word of the PT Control area, but the current screen number is also now shown in the same word. So, the first word of the PT Control area can be written to if you want to change screens, but it also changes when the screen changes to a different screen. It performs both tasks that were previously seperate in the NT30. See this topic as well. http://forums.mrplc.com/index.php?showtopi...amp;#entry81601

You should be able to access the CV just like a CS or CJ. The CV has almost all the same FINS Routing capabilities that the CS / CJ PLCs have. The full FINS implementation originated on the CV processors. The CV must have a relay routing table to know how to gateway back to Ethernet, just like any CS or CJ would.

You cannot directly add a CV to the network diagram in CX Integrator, but when you use the Datalink tool to create your datalinks, you can add a node as a CS, CJ, CV, CQM1H, C200HX, etc. If you upload the network, you will get an icon for the device, but you cannot edit any parametes. See the CQM1H on CLK below.

The NS does not have the ability to determine a path back to the remote computer. To program over the web (using Ethernet), the NS must be programmed with the IP address of the remote router (ie your home router). In many cases, this is not practical, as the programmer may be moving from site to site (or hotel to hotel), or the IP address of the remote router may not be static. The only other way to program the NS over the web (without using VPN, which is the best way), is to add a serial cable from the PLC to the NS, and program the NS through the serial connection to the PLC. The downside to this is that it is VERY SLOW. It can take 1 hour to download a medium sized application.

I would check the communications port setup again. The only way I have ever seen this error is when the port is not setup correctly. A timeout would be shown in the Abort Complete bit (1509.10 for SCU0 port 1).

I remember the same thing when I first installed CX-One Version 3.?? It appeared to be a CX Server issue. PdL's solution (online update) quickly cured the problem.

René I have also used this method for customers to access their equipment remotely. When the IT department at the site can set it up properly, it works very well. On the PC side, do you use built in Windows VPN connections or a seperate VPN client? We have several customers who have VPN access to remote customer sites, but many times the IP address that they get assigned via VPN is on a different segment than the PLC or NS. Last week customer had 192.168.1.x for PLC / NS at the site, but VPN gave him 192.168.5.x. Still need 'default gateway' in PLC to hop through the router.

The Danfoss drive would not be able to work on the same network as the PC link. You would need to write a 'driver' using the non-procedural port setup ('RS232"), and issue both Host Link and Danfoss commands. I do not have any code for a Danfoss protocol.

martol The PLC should be fairly straight forward to setup for internet access. Lets assume you are using UDP 9600. 1. Forward UDP port 9600 to the PLCs IP address in the router. For my Linksys router, this looks as follows: 2. In the PLC setup, specify the LAN port of the router as the 'default gateway'. For me, this is 192.168.1.100 3. When you connect from outside the LAN, specify the WAN IP address in CX Programmer. The address below is a ficticious address, so it will not connect to a PLC. Lets get the PLC connected first. This is the easier of the 2 setups. The NS is much trickier, and in some cases cannot be accessed remotely.

In the NT31/631 family, starting with hardware version 2, there is a 'compatibility mode' that greatly reduced the differences between an NT30 and an NT31, especially in the area of Notify and Control areas. Were you able to use this feature? This is documented in Appendix C of V064 http://forums.mrplc.com/index.php?autocom=downloads&showfile=853

File Name: NT21 NT31 NT631 Reference Manual File Submitter: PMCR File Submitted: 28 Apr 2009 File Category: Manuals Omron NT21 31 631 Reference Manual Click here to download this file

I have a few suggestions. 1. The port ready bit in your sample code is incorrect. You have A329.05. The correct bit is A392.05. 2. Verify that the transmission out the serial port is correct. Unplug the scanner from the PLC port, and connect the Omron programming cable instead. The use Hyperterminal or Supermon (http://forums.mrplc.com/index.php?autocom=downloads&showfile=575) to recieve the data and verify that it is correct. 3. Change the location of the differentiation of the TXD command. The way it is written in your code, it will send (which will turn the port ready flag off), complete the send (which will turn the port ready flag on again), then send again (because this is a new rising edge of the @TXD instruction). 4. How many bytes of data are you trying to send? You have #0010 as the number of bytes. This is 10 (HEX), which is 16(DEC). So, D0 - D7 would be sent. Also, the CR + LF will be automatically added (because of the port setup), so you don't need to include these in the DM area that you are sending. 5. Make the control word of the TXD #0000. Setting it to #0010 lets you control the RS signal, but no data is sent. Unless you are trying to manually manipulate the RS or CS lines, always use #0000 for the control word. 6. Can you post the DM area that you are using for the source of the send string? This would be helpful.

This is an NT20M. This will require the old DOS software for upload / download. I don't believe that even the original NTWin could upload / download from an NT**M, although it could import files in the old DOS format for certain types of ROMs for NT**M. If you contact your local Omron supplier, I would suspect that they can provide you a copy of this software. As this post is from January, this may have already been solved.