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:
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!
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.
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!
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
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 (1.8 KB)
Looks like the memory area codes for CV-series are different than the rest:
The FINS driver has no notion of being in a different mode for older models.
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.
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.
No meaningful progress on CV support in Ignition yet, but I did fix the error code lookup in Wireshark 
I submitted a merge request upstream, should make its way into a release one day...
2 Likes
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.
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:
As well as an entry in the Log:
FinsWriteRequest 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?
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?
Oh yeah, this doesn't look like good news:
No DM Bit in the "CV mode" column.
1 Like
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 (473.6 KB)
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.
Thanks for verifying this for me! It helps tremendously to "know" a certain path is not going to work for us.
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.
1 Like
