Modbus TCP Drier

After several days of testing the Modbus TCP Driver against GE PLC’s (9030 and RX3i), I think it would be very beneficial to have much more controls over the item name in the Modbus TCP driver(server).

Currently, the address tool in the driver appears to be limited to only 5 characters(Prefix) and a number. Granted the address tool allows for rapid creation of a series of OPC items with an indexing numerical suffix and indexing physical address. It does allow for rapid creation of tags but is very limiting in naming conventions that can be used.

We would like to be able to input item names (say something like 32 characters) or import a CSV file defining item names and thier corresponding address in the PLC (with underscores permitted).

Would something like this be easy to to incorporate?

The Modbus address tool in the driver is meant to replicate the normal address space in the PLC. You don’t want to give address specific names there. That is what SQLTags was designed for, to associate any string name to an address in the PLC. SQLTags does have a CSV import/export tool that you can use to quickly give names to each address. Hopefully this helps.

We changed the Modbus driver Beta to allow a 12 characters prefix instead of 5 and allow A-Z, a-z, 0-9 and _ characters.

It is not completely what you described but it may help.

Okay, How about this one, then…

– Say I’m using a PLC from EZAutomation-- which I am. :wink:
– I have an array of five UINT32 starting at PLC address R200. The “R” area of the memory map are all 16-bit registers so each UINT32 element in the array would be located at R200, R202, R204, etc.

When I set up the driver, I like to be able to “step” the increment of the beginning and ending pointers, so that if I use a prefix of “R” a start of “200”, an end of “208” and a “step” of “2”, I would get OPC adresses that match up to my PLC addresses.

Am I making sense, or do I need another Mountain Dew-- no matter, I’m getting another Dew anyway, but am I making sense? :slight_smile:

This is a good question and yes the Ignition Modbus driver accommodates this.

If you select Int32, UInt32 or Float for the DataType in the device address configuration, the driver will adjust the Modbus addresses to skip by 2.

Yep! Already figured that out. :thumb_right:

But I was talking about the address name mapping ([prefix]nnn). It only increments in steps of one.

See? I knew I wasn’t making sense! :laughing:

Ah, I see what you want to accomplish now!

We may change the driver to step both the Ignition address and the Modbus address by two if the DataType is Int32, UInt32 or float. We are thinking through it here to make sure this is the correct way to add this feature.

What is you take on it? Can anyone think of cases where stepping by two is not desired?



Well, yes I can. Here’s an example for each:

*** Example 1: Step by one ***
An array of UINT32 that holds the number of parts coming off a screw machine. If I use a prefix of “Product” I can have Product1, Product2, Product3

*** Example 2: Step by two ***
Same array, but this time I want to organize things by PLC Memory Location (because that’s how my maintenance guys think, and eventually I’d like to be able to hand some of this stuff off to them. :mrgreen: ). Now I can can have something like R100, R102, R104

I was envisioning maybe something like a ckeckbox to toggle whether the increments were by one or two. That way it’s not a numeric entry like radix.

So… how’s that for playing my own devil’s advocate?

Just thought of something else…

Also along the line of PLC addresses

Some PLCs can set up an array of 32-bit elements and the addreses increment by one (ie CLogix), others use 2 16-bit elements to do the same thing (ie Omron, EZ, et al) and so their addressing increments by two.

The next development release includes the following improvements:

  1. Address mapping has a step check box to allow skipping by 2.

  2. Added more Modbus types that specify the data encoding to use. They include Holding Register (Float), Holding Register (Int32), Holding Register (UInt32), Holding Register (Int16), Holding Register (Uint16) and Holding Register (BCD) . There are Modbus specific address designator that can be entered into the OPC path of a SQLTag for each. The cooresponding designators are HRF, HRI, HRUI, HR, HRUS, HRBCD. The previous C, DI, IR and IRBCD still apply. Please keep in mind that as a result of this change the export/import file format is different.

  3. Because of item 2, the DataType has been removed and is determined automatically by the Modbus type.

1 Like

Finally got a chance to take a look at this again. Works great! :mrgreen: