PMCR

Tom Jay Anthony is correct. The key is setting up the C200H Alpha port to Hostlink, 8 data bits (8, None, 1 for example). For the sake of example, use 19,200. The Promi device only supports 8 data bits. Then in CX Programmer, configure CX Programmer for Hostlink, 8, None, 1, and 19,200 as shown above. Also make certain that DIP switch 5 is off. This is the override switch to force both peripheral and hostlink ports to Hostlink, 9600, 7, Even, 2. The error that you are seeing about the port being in use by another application is the mismatch in framing between CX Server and the virtual port that PromiWin creates. PMCR

Ben You could leave both the UDP and TCP ports at 9600. Even thought they are numerically the same, UDP and TCP have their own ports, so UDP 9600 does not conflict with TCP 9600. Unless Cimquest has updated their driver to work with TCP, you will have to use UDP for OPC, and TCP for CX Programmer, but you can use TCP 9600.

Ben The conflict that you are observing is actually on the PC side, not the PLC. Both your applications are trying to use UDP port 9600. Here is a suggestion. If you are using a CX Server based application (CX Programmer, CX Server OPC, etc), configure this application to use FINS TCP, not UDP. The Ethernet module will communicate via TCP and UDP at the same time, and you will not have a socket conflict on the PC. Because FINS TCP is relatively new, not many (if any) software vendors other than Omron have FINS TCP drivers. You are correct that the Ingear OPC server uses UDP 9600. In the world of Omron Ethernet, the module and the application must have the same UDP port number.

File Name: SuperMon 5.65 File Submitter: PMCR File Submitted: 31 May 2006 File Updated: 09 Oct 2011 File Category: Utilities Serial Communications tool. Includes a Modbus RTU Master with a Modbus Command Wizard to help build commands and understand responses. Click here to download this file

It sounds like you are well on your way. Even if DR is 0 DR0,IR0 will still return the value that is in the memory location that is being pointed to, not the value of the pointer itself. If you use an IR with a comma before it (,IR0) this is indirect addressing. MOV ,IR0 D200 Most of the time when I am using IR, I don't even use a DR, and just manipulate the IR. You don't need to include a DR in front of the comma. The 2 examples below are functionally the same. MOV ,IR0 D200 or MOV 0,IR0 D200

I don't know why it seems as though it is jumping by 2. The offset works directly as I described. Are you manipulating the value of the IR at the same time that you are manipulating the value of the DR? When you use DR, leave the value of the IR constant. One thing that you can do facilitate the monitoring of the DR is... If you are adding 1 to both the IR and DR, then the combination of DR0,IR0 would be an offset of 2. I assume that you are doing all the manipulation and data movement in the same PLC task. P_On----------MOV DR0 D200 This will allow you to directly monitor the value in DR0. Just monitor DM200 and it will always have the same value as DR0. You can also monitor the IR in the same fashion. P_On----------MOVL IR0 D200 In this case the value of IR0 will show up as a 2 word wide HEX value, stored in DM200 and DM201. You can then use the IR / DR monitor that I posted in the Download Code section (Omron / Utilites/ IR DR monitor) to show the actual address that the IR is pointing to. And the correct format for using IR and DR together is definitely DR0,IR0. The DR can be replaced by a constant, such as 5,IR0 or -12,IR0. Using the DR allows the offset to be a variable. This holds true for CV, CS1, CJ1, and CP1H processors.

[This one is relatively easy (no offense intended). Lets say that your lamp bits on the NS are addressed to DM0000.00 - DM0000.15 (and DMs will work just fine). Perform the following ladder... The MOVR loads IR0 with a pointer to CIO2000 The MOV DR0,IR0 D00000 will move from a location of IR0 (which points to CIO2000) offset by a value of DR0. Your job is to manipulate the value in DR0 from a value of 0000 to 002F HEX. This will represent an offset of 0 to 47 channels. I tried this on an NS8 / CJ1M and it works as shown. P_ON ---------------- MOVR 2000 IR0 | | |--------MOV DR0,IR0 D00000 To manipulate the DR (which is only a single register, just like DM, CIO, etc) use single word signed binary math, or + and - Binary Increment Decrement Instructions.

You can use DRs as the offsets from the IRs, and that is how they are intended to be used. Here is an alternative that directly manipulates the IR itself. To calculate and use the address of CIO3200, do the following: Perform your calculation to determine 3200. The result of this must be in HEX or converted to HEX. ie if you are storing the result in DM20000, then DM20000 = 0C80. Also, DM20001 must be 0 because you are going to perform Long Binary math. Now ... MOVR 000 IR0 This loads IR0 with the pointer value to point to CIO 0000. The Value in IR0 is now 0000C000 (HEX). +L IR0 DM20000 IR0 This adds the value in DM20000 and DM20001 (00000C80) to IR0 and stores it back in IR0. After the +L is performed, the value of the pointer itself (IR0) is 0000CC80 (HEX). This points to CIO 3200. This works if you are going to use ,IR in place of a Channel location (ie a DM, CIO, etc.). =============================================================================== If you want to use ,IR0 in place of a bit, and you want to point to 3200.00, then perform the following. MOVR 000.00 IR0 This loads IR0 with the pointer value to point to CIO 0000.00. The Value in IR0 is now 000C0000 (HEX). Note that this is shifted 1 digit to the left of the value in the channel version. Now, since you calculated 3200 as the number of channels to offset from the start of the CIO area, but you are using bits, you must multiply 3200 by 16. Again, all this needs to be in HEX, not BCD. *L #10 D20000 D20002 Multiply your original 3200 (0C80) by 10 Hex (16 bcd) and store in D20002. The result will be 0000C800. +L IR0 DM20002 IR0 This adds the value in DM20002 and DM20003 (000C800) to IR0 and stores it back in IR0. After the +L is performed, the value of the pointer itself (IR0) is 000CC800 (HEX). This points to CIO 3200.00. You can directly manipulate the IRs once they are loaded with MOVR. Use Long Binary math to add and subtract. If you are using the IR as a pointer to channels, then add and subtract the number of CHANNELS that you want to shift. If you are using the IR as a pointer to bits, then add and subtract the number of BITS that you want to shift. Happy IRing.

I have just posted a utility in Downloads / Omron / Utilities to convert from Raw PLC addresses to IRs and back the other way. It has an online monitoring tool, but it requires FINSGateway to use online. I still find it quite handy for the conversion aspect.

File Name: IR DR Monitor File Submitter: PMCR File Submitted: 19 May 2006 File Category: Utilities This is a utility that can monitor IR and DR values and show what addresses they point to not just the raw value. FinsGateway is necessary for online use. There is also a conversion tool to convert from PLC addressing to IR addressing and back again. <img src=style_emoticons/#EMO_DIR#/nana.gif style=vertical-align:middle emoid= border=0 alt=nana.gif /> Click here to download this file

Currently the NS does not support programming across the Internet directly. Using a VPN connection and obtaining an IP address on the same subnet as the NS will work. Here is a method that can be used for programming a CS / CJ PLC and NS touchscreen across the internet. CS / CJ PLC (firmware 3 or higher) with a CS / CJ ETN21 (firmware 1.3 or higher). Connet the PLC ethernet card to the web via a router. Connect the NS to the PLC via NT Link 1:N on the built in serial port of the PLC. Tips. 1. You must use Port Forwarding on the router to forward UDP port 9600 to the PLC. 2. The PLC must have a router table entry in the Ethernet card setup to forward all traffic back through the router. Example: IP address provided by service provider of 65.13.44.12. Router has WAN IP of 65.13.44.12, LAN IP of 192.168.1.100 PLC has IP address of 192.168.1.5. The Node Number of the PLCs Ethernet card must be set to 05 as well, or whatever the last octet of the PLCs IP address is. PLC Ethernet Card has IP Router Table set for IP Address: 0.0.0.0, Routers IP Address 192.168.1.100. PLCs Ethernet Card must be set for Conversion : Auto(Dynamic) PLC has a Routing table that identifies the Ethernet card as network 7 (as an example) Port Forwarding in the router (also called Gaming in some routers) forwards UDP port 9600 to 192.168.1.5 (PLC's IP Address). To Connect to the PLC in CX Programmer, Connect using the Ethernet Network. Under settings for the network, connect using FINS Source Network: 7, FINS Destination Network 7, FINS Node 5. Node 5 matches the last Octet of the PLCs IP Address. Under the Driver tab, set the IP Address of the Router (65.13.44.12). If the Workstation Node number as shown is above 126, then uncheck Auto-Detect and set a node number for the PC that is below 126, and is not the same as the PLCs Node Number. You should then be able to access PLCs across the web. To access the NS, you will also need to add an entry in the Routing Table of the PLC to configure the built in RS232 port to be network 111 or 112 (111 if port A of the NS is used, 112 if port B of the NS is used). In the Settings for the PLC serial port, configure the port for NT Link 1:N, and set the MAX NT Link Unit Number to 2. This allows for a longer timeout between the NS and the PLC when remote programming being used.

You are correct, the matched case 'next' column goes to a step in the sequence that called the matrix. When the last case has the 'next' column set for 'end', then the entire sequence ends, not just the matrix. I see exactly what you are trying to do in your example. Here is the wrinkle. Because the matrix identified that you had data that matched the model of <STX> ..... <ETX>, it flushed the first message when the first matrix got to the 'Other' case. If this did not happen, most applications would end up with junk data in the beginning of the buffer forever. In my experience, any time you have more than 15 cases, you have to pass it to the PLC and let it formulate the response.

The Matrix Cases will remove the strings from the buffer in the order that they arrived into the buffer, not the order listed in the matrix. The order of the matrix only matters when processing the first string in the buffer. For example: Case 0: <h>+"ABCD" + w(D0,*) + <t> Case 1: <h>+"FGHI" + w(D0,*) + <t> Case 2: <h>+"ABC" + w(D0,*) + <t> Case 0 would receive a string <h>ABCD1234<t> Case 2 would receive a string <h>ABC1234<t> If the cases were written as Case 0: <h>+"ABC" + w(D0,*) + <t> Case 1: <h>+"FGHI" + w(D0,*) + <t> Case 2: <h>+"ABCD" + w(D0,*) + <t> then Case 0 would receive both <h>ABCD1234<t> and <h>ABC1234<t>. Granted, this is usually only the case when the '*' is used for the length. As far as a terminal emulator, I use one that I wrote. It is available from the download section of this forum, under the More Misc Downloads, Tutorials, and Guides section.

I must admit that I have not pushed the new option for flushing the buffer as hard as you currently are doing, but I can give you my understanding. The Receive Buffer will receive data regardless of what the SCU is doing, ie sending, receiving, not running a PMCR, etc. It will not be flushed unless you flush it manually. If 3 consecutive messages are stored in the buffer, the first will be processed by the matrix the first time the matrix step is called. The second message will be serviced the second time the matrix is called, etc. Please see the attached file for a solution. To answer your question about handling the responses to matched matrix cases directly on the SCU, yes you can. Each matched matrix case can have a unique 'Next' target. ie if case 0 is matched, go to step 3, if case 1 is matched, go to step 4, if case 2 is matched, go to step 5. Steps 3, 4, and 5 would be the send steps to respond to the device. In the attached example, notice that if case 0,1, or 2 is matched, and that triggers steps 3,4 or 5, I go back to step 0 to see if there is another unsolicited message waiting. This idea of using the matrix to trigger different steps in the sequence works up until you have more than ~ 14 different recieve cases. If you have many different cases, then you will have to use PLC logic to answer the unsolicited messages. To answer your example: .........<h>A:fghdse<t>..................<h>B:klsewq<t>.............. If a receive matrix is set up to look for instances of A:[*.*], B:[*.*] or C:[*.*] it will find the first match A:[*.*]. During this event the host sends data for C. Providing a flush command has NOT been issued am I correct in assuming that the buffer now contains the original data PLUS the NEW data? .........<h>A:fghdse<t>..................<h>B:klsewq<t>.............<h>C:123456<t>..... As soon as the matrix has processed case A, the <h>A:fghdse<t> is removed from the buffer by the SCU. You are left with messages B and C. You do not have to do this manually. Flush is only used to completely clear the receive buffer.

I will try to address your questions in the order you posted. 1. Getting data into the Buffer. The answer to this question partly depends on which version of CJ1W-SCUxx you are using. Prior to SCUxx-V1 the receive buffer was always flushed when a PMCR was executed from ladder. SCUxx_V1 hardware allows you to select whether or not the buffer is cleared upon execution. This selection is made in the setup of the module (the same place that you select Protocol Macro Mode) for the port. If you configure the port to not flush the buffer, and on a particular PMCR you do want to flush the buffer, you can use a Flush step as the first step of the PMCR. 2. Recieve Maxtrices. A receive matrix is a collection of receive messages called at one time, only one of which will match the string in the receive buffer. EX> RECMSG_A <h>"+"ABCD"+W(DM0,4)+<t> RECMSG_B <h>"+"EFG"+W(DM4,8)+<t> RECMSG_C <h>"+"KYL"+W(DM12,10)+<t> The SCU will compare the data in the receive buffer with each Receive Message in the matrix in order from top to bottom until the first match is found. When a match is found, the SCU exits the Matrix. The comment made by Nibroc regarding the use of a wait step is an excellent point. This can be used if your PLC needs to respond to the unsolicited message from your serial device. There is a wait release bit (N+0.00 for port 1, N+0.08 for port 2) that you turn on in the PLC to release the wait step. There is also a bit (N+9.09 for port 1, N+19.09 for port 2) that indicates that the SCU is on a wait step that needs to be released. See the attached file for an example of how this could be implemented. PMCR_Example.psw

Attached is a document that I started last year, and have not quite finished. Although it is not complete, it should help you with the mechanics of configuring an Omron PLC for Internet Communications. The most important thing that you can do to establish Internet Comms with Omron products is obtain static IP addresses for the routers on both ends of the 'network'. ie the job site and your office. Accessing_Omron_PLCs_via_the_Internet.pdf

Good News! Your interpretation of the manual is correct. You can use inputs 2 and 3 in Quick Response or Interrupt mode as long as Software Reset is being used for HSC0 and HSC1. If Z-Phase + Software Reset method is used, then inputs 2 and 3 cannot be used.

The APR instruction can also be used to perform a 2 word wide scaling function. This instruction has 3 functions, Sine, Cosine, multisegment scaling. The Multisegment scaling can either use 16 or 32 bits of data. Reference the CS1 Instruction Reference Manual (W340) for details on this instruction. Use a Signed Integer type of conversion, and specify 32 bits of data.