Omron PLC Dummy I/O

Using dummy IO modules on an Omron PLC with a 'virtual backplane' (i.e. a CJ1M for example) is a good way to keep addresses used for varying projects the same, and adding extra I/O when needed for extra functions, without upsetting the existing addressing structure.

For example, suppose you have a machine process that requires three 16 way input cards, and three 16 way output cards. These could of course occupy address space 000, 001, 002, 003, 004 and 005 without problem. But then suppose their is a need for a similar process with some limited functionality that only required two input and output modules. Once again, these could occupy addresses 000, 001, 002 and 003, but these now conflict with the earlier allocation and could cause confusion when wiring and producing documentation, because where 'Solenoid 1' connected to output 003.00 previously, it now connects to output 002.00.

A solution to this is to insert some 'dummy' I/O modules into the I/O table to act as placeholders and to allow the addressing to remain consistent between the two processes. ('Dummy' I/O modules are not actual physical modules, but rather they are virtual.)

The picture below show an I/O table with some dummy modules inserted:



Dummy I/O modules of varying sizes can be added by selecting them from the Basic IO menu of the 'Add unit' dropdown menu.

Omron CJ2 PLC

Omron have announced the release of a new PLC, namely the CJ2. See this link for more info.



SYSMAC CJ2 CPU Units

1. Greatly increased program capacity and data memory capacity. The largest-capacity CPU unit, the CJ2H-CPU68-EIP, has a program capacity of 400K steps (1.6 times the capacity) and a data memory capacity of 832K words (twice the capacity of previous OMRON products).Higher system throughput speed for I/O and faster immediate refreshing for basic I/O in addition to faster basic and special instructions. (Execution time is 20 times faster than previous OMRON models, e.g., reduced from 20 µs to 1 µs for the LD instruction.)

2. A multifunctional Ethernet port compatible with EtherNet/IP is built in and can be used simultaneously for FTP communications, data links, and Support Software connections.

3. Errors reduced when modifying designs because tags are used for actual I/O and internal I/O, eliminating the need for address allocation. Also, PLC programming and PT display screens can be developed in parallel.



Of the points listed above, I find no.3 to be interesting. It sounds to me that it will make programming a PLC similar to writing a C# or Visual Basic program for example, where variables are named and used without the underlying address being important. Very interesting, and I hope that I may have the chance to give it a try.

Omron CX-Programmer SFC Editor

While using the CX-Programmer V7.2 package from Omron, I wanted to have a play around with the SFC style of programming with a CJ1M PLC. Well, not so easy as it didn't work!

When adding a program section of the SFC type, CX-Programmer completely hung up.

After much digging, it appears that CX-Programmer (or the SFC editor alone, I'm not sure) is built upon the .NET framwork V1.1. Somehow, when the program was run, it was targetting version 2.0 of the framework, and consequently crashing.

The fix I came up with was to force the CX-P.exe program to target the correct framework version.

I should point out that the following was in no way suggested by Omron, or anyone else, and so should be taken at your own risk. OK, that's the disclaimer stuff out of the way...

Using info from this MSDN link...

...I created a file called 'CX-P.exe.config' and placed it into the CX-Programmer directory, ie. "C:\Program Files\Omron\CX-One\CX-Programmer".

Running CX-Programmer now, adding a SFC task to a CJ1M PLC for example, results in the SFC editor springing into life.

The file in question is nothing more than an XML file, the contents being:

   1:  <configuration>

   2:      <startup>

   3:          <supportedRuntime version="v1.1.4322"/>

   4:          <requiredRuntime version="v1.1.4322"/>

   5:      </startup>

   6:  </configuration>

This file forces CX-Programmer to use V1.1 of the .Net framework, and not the one it is (wrongly) using for reasons unknown. So far it appears to be working ok. Like I say, try at your own risk!

It may be that future update fixes this issue, so this is nothing more than a bit of interesting info.



I originally posted this a a thread on the MrPLC forum here.