Modbus/TCP read of counts for E2 channel

Hi.

I need to read the ‘Count’ value for Opto22 E2 AD6 analog channels. I have used Modbus/TCP in the past to access high density digital points and analog counts on a B3000, however I have been unable to work out the correct addressing for analog counts on the E2.

Can anyone provide any guidance. Using the PAC Manager Modbus calculator, I obtain an address (Unit ID 50 or 82 Register Address 0) that provides the floating point scaled unit values for each of the channels … but I have been unable to locate the underlying counts … which is what I really need. When I try an address that looks like it should provide the counts (Unit ID 50 Register Address 128) … I just see 0’s.

Any advice will be appreciated.

Regards,
Greg Shearer

It sounds like you have the correct address - not sure why that doesn’t work - have you tried Unit Id 58, address 128? That is the read/write area.

Unfortunately, using that Unit ID shows the same as 50 … so no luck.

I think I have convinced myself through a more detailed review of the documentation … plus playing around with Modbus tools for hours :confused: … that the channel counts aren’t available through the E2 Modbus interface. Whenever I look at an address that indicates it should provide the raw counts … all I see are the Scaled Units for each channel or nothing at all.

It appears to me that the Modbus interface on the E2 might only support reading channels in engineering units … which surprises me … as counts are available through Modbus on the B3000.

I know this is a bit a subtle technical issue … but if someone can confirm or deny it would be appreciated.

I need a hot minute (ie, a day or so) to get out of the ‘old-but-gold’ storage at the office, set it up and take a peek.

Once I do, if I can confirm what you are seeing, I can point some of the engineers that wrote the firmware for this thing and get a… well… not sure what I would get… doubt we are going to do a firmware change for it, but eh, they might have an idea for something we are just not seeing.

Hope you can hang on said hot minute…

Thanks for the offer, Beno … but really not worth the effort on my account :slight_smile:

Mainly as I do have what is almost certainly a better alternative plan for the project, which is (pretty obviously) an upgrade from old installations with B2 serial interfaces. We have purchased and installed a single E2 replacement which has worked well as a drop-in replacement for the B2, but I have only just got around to implementing the Modbus interface … which has proved disappointing. Unfortunately, the HMI software I’m hoping to use does not include an OPTO-MMP driver … although it does have just about everything else you could ever need!

However, as an alternative I could replace our B2/E2 installations with EB1 Brains which we use extensively in other applications. I was investigating the use of the E2 primarily to reduce overall cost but would actually prefer to use the EB1 … and I think we have some effective spares available within decommissioned machines.

Thanks again, but please don’t spend any time on this question. I will move on to the EB1 option :slight_smile:

Got a Linux or Windows PC on the network that could run Node-RED?
It might help keep your hardware and keep Modbus alive?

Modbus is fine … but this is the hardware end of a project that started with the need to change the HMI system. The current HMI is thirty-year-old terminal/server-based software tied to a specific database vendor development environment.

So, the project begins with a plan to replace the terminal-based HMI with a modern HMI/SCADA client interface, with hardware interfaces direct to the client rather than via a remote server. This has many advantages for HMI capabilities and removes the database vendor dependency … which has to happen.

As mentioned earlier, the currently preferred HMI software provides a Modbus driver, but not Optomux or Opto-MMP, so using an EB1/2 looks like the best option at the moment. Serial Modbus isn’t really an option for the new development as multiple HMIs (testing stations) currently have their I/O on a single B2 board. Using EB1/2 would also allow replacement of existing discrete signal conditioning hardware with Opto22 SNAP modules, which would further simplify the overall installation structure and reduce the component count.

I could consider implementing Optomux as a serially encapsulated TCP/IP interface … but I’m not keen on that approach given the EB1/2 alternative.

Using Node-RED … effectively as a stand-in for our current Linux server interface … could certainly be done … although it does introduce complexity into the overall system design.

Does your SCADA support OPC UA?

The planned HMI does … but not our site SCADA system. The E2 doesn’t support OPC UA does it?

Or are you suggesting groov/EPIC?

If you have an EPIC with the latest firmware, you can add the E2 as IO. This should allow the EPICs built-in OPC UA server to serve it up.

Definitely an option which I will continue to consider. I’m moderately happy to continue with EB1/2 at the moment given that we have many on site. Also, there is a load cell (AILC) SNAP module I might like to use … which is not yet provided by groov/EPIC.

There are certainly a few ways to build our system with Opto22 gear … which is great!