# Omron FINS CV PLC CIO Memory Access possible?

**URL:** <https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938>\
**Category:** Ignition\
**Created:** [December 17, 2024, 4:11pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938 "2024-12-17T16:11:16Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![K\_Jackson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/k_jackson/32/49738_2.png) [@K\_Jackson](https://forum.inductiveautomation.com/u/K_Jackson)\
**Post date:** [December 17, 2024, 4:11pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/1 "2024-12-17T16:11:16Z")

</div>

We have a customer that has a lot of Omrons, and our next project involves an older CV2000. We are migrating a legacy SCADA app over into Ignition, and the goal is to be as hands-off on the PLC as possible.

**For some reason we are not able to read CIO memory from this CV PLC.**

I don't _think_ we've ever had a problem reading CIO with the CS or CJ PLCs here, and I'm pretty sure the legacy "FactoryLink" application that we're replacing with Ignition is accessing CIO ok. It's using an "OMRON CV-Series Ethernet" driver. The legacy system is mid-90's era,

**Before we get intrusive in the PLC and start mapping things to DM registers, we wanted to check and see if anybody here has successfully accessed Core I/O on Omron "CV" PLCs using the Ignition FINS/UDP driver.**

More Info:

We are using the Omron FINS/UDP driver to connect to the device. DM memory access is working as expected.

Example OPC Item Paths we've tried for a single bit are:

```python
ns=1;s=[CV2000_Lab_UDP]CIO1255.3
ns=1;s=[CV2000_Lab_UDP]CIO<UInt16>1255.3

```

Tag Diagnostic shows: `null, Uncertain_InitialValue` and usually ends up as `null, Bad`

The export from the legacy FactoryLink application shows it's configured as:

| TAG | STATION | DATAAREA | DATAADDR | BITOFFSET | DATA\_TYPE |
| --- | --- | --- | --- | --- | --- |
| ThisTagname | 0 | CIO | 1255 | 3 | UBIN16 |

Lastly, reading a value from a DM such as:  
`ns=1;s=[CV2000_Lab_UDP]D<String14>7101`  
... is working fine.

Thanks!

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 17, 2024, 4:33pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/2 "2024-12-17T16:33:46Z")

</div>

Can you switch to TCP and get Wireshark captures of both applications?

edit: nevermind, UDP should be fine too, thought the Wireshark dissector only supported TCP.

---

<div class="post-metadata">

**Author:** ![K\_Jackson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/k_jackson/32/49738_2.png) [@K\_Jackson](https://forum.inductiveautomation.com/u/K_Jackson)\
**Post date:** [December 17, 2024, 4:49pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/3 "2024-12-17T16:49:50Z")

</div>

Thanks for the quick response!

The TCP driver works for the CS's and CJ's here, but did not work for the CV, it gets stuck in the "ReconnectWait" state. We punted and used the UDP driver which went "bound" and let us communicate.

I'm not terribly fluent in Wireshark and it's currently not installed on this particular gateway. The customer is slowly bringing down the area over the next couple of days for year-end maintenance. I'd feel more comfortable installing and trying that while they are down, stay tuned!

---

<div class="post-metadata">

**Author:** ![K\_Jackson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/k_jackson/32/49738_2.png) [@K\_Jackson](https://forum.inductiveautomation.com/u/K_Jackson)\
**Post date:** [December 20, 2024, 7:50pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/4 "2024-12-20T19:50:21Z")

</div>

I installed wireshark and think I've got some packets to look at.

I tried reading from a DM area that I know works:  
`ns=1;s=[CV2000_Lab_UDP]D<String14>7101`  
... and get

```python
Response code: Unknown (0x0040)
Response data: 0000000000000000000000000000

```

which I think is correct, because it should be returning 14 "spaces" since the line is down (28 zeros should represent 14 characters?).

When I tried either of the CIO variations:  
`ns=1;s=[CV2000_Lab_UDP]CIO1255.03`  
`ns=1;s=[CV2000_Lab_UDP]CIO<UInt16>1255.3`  
... I get the following with no response data:  
`Response code: Unknown (0x1141)`  
... and no Response Data at all.

I saved the filtered packets to a file, let me know what else I might be able to provide.

[OmronFINSUDP\_CIO\_ReadAttempt.pcapng](https://forum.inductiveautomation.com/uploads/short-url/3zaqbrZ3TFsTf2TKl9yzetw13fz.pcapng) (1.8 KB)

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 20, 2024, 8:01pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/5 "2024-12-20T20:01:37Z")

</div>

Looks like the memory area codes for CV-series are different than the rest:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/1/b16e9feef2823528556bfc8d94b8215914ad11b2.png)

The FINS driver has no notion of being in a different mode for older models.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [December 20, 2024, 8:11pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/6 "2024-12-20T20:11:52Z")

</div>

If you continue using Ignition's driver then you'll have to map them into the DM area as you suggested in your original post. This happens to be the only area with a shared memory area code between the two models.

We can look at adding support for CV-series, or a separate driver, whatever it might be, but that won't be a quick solution. Everyone is busy now and for the foreseeable future working on Ignition 8.3 and I we'd need to acquire some CV-series hardware as well.

---

<div class="post-metadata">

**Author:** ![K\_Jackson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/k_jackson/32/49738_2.png) [@K\_Jackson](https://forum.inductiveautomation.com/u/K_Jackson)\
**Post date:** [December 20, 2024, 8:18pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/7 "2024-12-20T20:18:20Z")

</div>

Thanks for confirming what we sort of suspected. We'll map over the CIO addresses we need into the DM memory area. Thanks so much for the quick responses.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [February 2, 2025, 12:44am UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/8 "2025-02-02T00:44:04Z")

</div>

No meaningful progress on CV support in Ignition yet, but I did fix the error code lookup in Wireshark 🙂

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/2/621001c879b72a23be8a03824ed3c4ce48707b25.png)

I submitted a merge request upstream, should make its way into a release one day...

---

<div class="post-metadata">

**Author:** ![K\_Jackson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/k_jackson/32/49738_2.png) [@K\_Jackson](https://forum.inductiveautomation.com/u/K_Jackson)\
**Post date:** [April 23, 2025, 8:05pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/9 "2025-04-23T20:05:45Z")

</div>

As a follow up on other aspects of FINS compatibility for CV series PLCs, I am noticing that I can NOT write to the **bit level** of a DM memory register. However, I _can_ write an entire word down to a DM just fine.

According to the old CV series programming manual:  
**"The DM (Data Memory) Area is used for internal data storage and manipulation and is accessible only by word. Although composed of 16 bits just like any other word in memory, DM and EM words cannot be specified by bit for use in instructions with bit-size operands."**

However, the (only ever so slightly more modern) CS series manual says something very similar, but I know we're writing bit level all over the place in CS PLC DMs at this facility.  
_ **"The DM Area contains 32,768 words with addresses ranging from D00000 to D32767. This data area is used for general data storage and manipulation and is accessible only by word."** _

The current Ignition FINS driver allows us to specify CV tags at the bit level and they are reading fine with no errors. For example, here are a few bits that identify an accumulation lane type that are all from DM1027 in the CV PLC. In this case, bit 0 "Sweep" is selected as the lane type. It has good data quality and we're pulling from D1027.00 perfectly.

 ![ReadBit00](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/1/011ad089bee7e6fa377071be4d71e1ad31560967.png)

Flash forward to a couple hours ago, and I had my very first opportunity to toggle the "Sweep" bit from the Tag Browser as a test and got a dialog:

 ![WriteErrorA](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/9/49a1f254259fc7297d930f616f226c0cc6672391.png)

As well as an entry in the Log:  
_FinsWriteRequest &nbsp; &nbsp;23Apr2025 15:26:49_  
_write to FinsScalarAddress(area=DM, address=1027, dataType=Bit(index=0, underlying=Int16)) failed: parameter error: area classification missing_

Is there _any_ chance I'm missing something elemental that will allow me to write to DM bits? Or is there a decent probability that there's just enough difference in the old CV's (as compared to the CS's and CJ's) that I'll need to develop a method to handle complete word writes in my UDTs going forward?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [April 23, 2025, 8:15pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/10 "2025-04-23T20:15:02Z")

</div>

Can you upload a Wireshark capture of the write?

Am I understanding right that this works with CS/CJ but not with the older CV?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [April 23, 2025, 8:19pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/11 "2025-04-23T20:19:58Z")

</div>

Oh yeah, this doesn't look like good news:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/a/1a4ffe506d9233f551cff81a7a195a2538c4aaa6.png)

No DM Bit in the "CV mode" column.

---

<div class="post-metadata">

**Author:** ![K\_Jackson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/k_jackson/32/49738_2.png) [@K\_Jackson](https://forum.inductiveautomation.com/u/K_Jackson)\
**Post date:** [April 23, 2025, 9:02pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/12 "2025-04-23T21:02:47Z")

</div>

I had a feeling ...

Attaching a pcapng file, I think the packet we're interested in is #2843 (address 0x0403 == D1027).

[D1027-00\_CS\_Bit\_Write\_Attempt.pcapng](https://forum.inductiveautomation.com/uploads/short-url/9A3OfUgntsja6AGtTshDYdhGleF.pcapng) (473.6 KB)

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [April 23, 2025, 9:16pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/13 "2025-04-23T21:16:24Z")

</div>

Yeah, sorry, you'll have to figure something else out.

Reading bits works because we just read the whole underlying word, which uses the 0x82 memory area supported by both.

I think all of our drivers implement bit reads by reading the host value and extracting the bit in the driver, regardless of whether the underlying protocol supports bit level access as a separate command/area.

---

<div class="post-metadata">

**Author:** ![K\_Jackson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/k_jackson/32/49738_2.png) [@K\_Jackson](https://forum.inductiveautomation.com/u/K_Jackson)\
**Post date:** [April 23, 2025, 9:23pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/14 "2025-04-23T21:23:43Z")

</div>

Thanks for verifying this for me! It helps tremendously to "know" a certain path is not going to work for us.

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [April 23, 2025, 9:34pm UTC](https://forum.inductiveautomation.com/t/omron-fins-cv-plc-cio-memory-access-possible/99938/15 "2025-04-23T21:34:32Z")

</div>

You might be able to define all your bit tags as derived tags pointing at a single host OPC tag for that word.

This setup would require the tag group these tags are in to have "Optimized Writes" enabled, and there's an ever present race condition you must be aware of if the bits of the host word change on the PLC side at the same time you're initiating a mask-and-write from the Ignition side.
