Using a DigiIap to pull modbus registers into Ignition

[SiriusMark]

I'm having a strange issue that I just cannot solve.

We have a series of flow analyzers that are connected to the network via Digi-Iaps. I can poll the Digi via Ignition by creating tags that are linked to the Digi's internal diagnostics. I can also create tags that poll the registers inside the flow analyzers. However, the data I get back is garbage. Once the tag starts polling the register, it starts at zero, counts up to 32767, suddenly changes to -32767 and counts back down to zero. Then it starts the procedure again. I know that the range it is counting up and down with is the full range of a modbus register, but I don't know why it's scanning like that.

This happens with every relevant register address. The really strange thing is, we have a sister platform that uses Wonderware, and when a friend pulled the data into Wonderware, it came in perfectly clear. So the issue is not the meter or the Digi, it is something in Ignition.

However, when he sets it up in Wonderware, he uses the F suffix (because that is how they have their own meters addressed). As I understand it, if you use the F suffix on a Modbus Register in Wonderware, you're identifying it as a 32-bit floating point number. So, I tried that option in Ignition and ended up getting wildly ridiculous numbers (in the millions or billions). These new numbers immediately started the same upwards tracking/counting. I didn't leave it in place long enough to watch it go up and down.

I've tried everything I can think of. Does anyone recognize this symptom and have a good direction to point me in?

 

[OkiePC]

That problem sounds like the original values are unsigned, meaning that the bits represent 0-65535 as opposed to -32768 to 32767. You are viewing them as signed integers so the last bit is used as a sign bit. The raw data is doing what it should, and you appear to have the bytes in the right order, it is just how they are interpreted by Ignition that makes them appear incorrect.

I think you just need to figure out a way to represent them correctly in Ignition. I have not gotten into that software yet, so it may be as simple as a setting change.

http://en.wikipedia.org/wiki/Signed_number_representations

 

[Ken Roach]

What's the data quality value for each tag ? Usually you'll get the red overlay box when there's bad Quality, but that doesn't sound like what's going on.

It sounds to me like your display objects are tied to a default Ignition internal tag that just increments through a 16-bit register value.

I thought that Ignition had demo applications that tied all the analog displays to this system "simulator" variable.

Can you run Wireshark on the Ignition Gateway machine to see if it's really polling these Digi One IAPs ?

What happens to the data value and Tag Quality when you disconnect a Digi One IAP from the network ?

 

[SiriusMark]

Ken-Tag diagnostics show good quality and if I disconnect or reboot the digi, I lose tags. I agree that it sounds like it is incrementing through a 16 bit register, but I don't understand why. I can try wireshark tomorrow, I'm actually sitting in my rack right now trying to convince myself to stop worrying about it. I have, at this point, tried every outlandish combination of settings I can think of.

The meter that I'm connecting to through the Digi is a NuFlo MCIII, and it has both 16 and 32 bit modes, so I've changed my addressing to try to match both. I've addressed them as 16 bit signed, 16 bit unsigned, floating, BCD, double, etc. Lol...I can get some really awesome numbers, but I can't get the right ones.

What's the data quality value for each tag ? Usually you'll get the red overlay box when there's bad Quality, but that doesn't sound like what's going on.

It sounds to me like your display objects are tied to a default Ignition internal tag that just increments through a 16-bit register value.

I thought that Ignition had demo applications that tied all the analog displays to this system "simulator" variable.

Can you run Wireshark on the Ignition Gateway machine to see if it's really polling these Digi One IAPs ?

What happens to the data value and Tag Quality when you disconnect a Digi One IAP from the network ?

 

[diat150]

have you tried a software like modbus poll to verify your data?

scratch out using the 32 bit registers, you wont be able to use those, as ignition doesnt support enron modbus.

I havent used ignitions modbus driver for anything, but it looks like you should use this:

>>
HRF for 2 consecutive Holding Register with Float conversion.


>>
example

[DL240]HRF1024


would read registers 41024 and 41025 as a 32 bit floating point number(equivalent to using the 'f' in wonderware.




but like I said, I would start out by using something like modbus poll to make sure I am pulling the right info, then move on to ignition.


I usually try and poll the date and time registers (16 bit integers) first







41200

41201

41202

41203

41204

41205


and then move on to something else like



battery voltage 48044 and 48055


using modbus poll makes it easy to move up or down a register for the offset or if you need to do any reverse bytes or words.

 

[curlyandshemp]

I'm having a strange issue that I just cannot solve.

We have a series of flow analyzers that are connected to the network via Digi-Iaps. I can poll the Digi via Ignition by creating tags that are linked to the Digi's internal diagnostics. I can also create tags that poll the registers inside the flow analyzers. However, the data I get back is garbage. Once the tag starts polling the register, it starts at zero, counts up to 32767, suddenly changes to -32767 and counts back down to zero. Then it starts the procedure again. I know that the range it is counting up and down with is the full range of a modbus register, but I don't know why it's scanning like that.

This happens with every relevant register address. The really strange thing is, we have a sister platform that uses Wonderware, and when a friend pulled the data into Wonderware, it came in perfectly clear. So the issue is not the meter or the Digi, it is something in Ignition.

However, when he sets it up in Wonderware, he uses the F suffix (because that is how they have their own meters addressed). As I understand it, if you use the F suffix on a Modbus Register in Wonderware, you're identifying it as a 32-bit floating point number. So, I tried that option in Ignition and ended up getting wildly ridiculous numbers (in the millions or billions). These new numbers immediately started the same upwards tracking/counting. I didn't leave it in place long enough to watch it go up and down.

I've tried everything I can think of. Does anyone recognize this symptom and have a good direction to point me in?

Your best bet would be to call Inductive Automation tech support so they can see what is going on. They will not ask for a support contract # before helping you with the issue. They will probably initiate a GoTo Meeting session and look at your configuration.

 

[danw]

There are four 32 bit IEEE 754 floating point (FP) formats, of which two are in wide use in Modbus comm.

The formats vary in which byte/word order:
Big Endian 4,3,2,1 (Motorola) or
Little Endian Byte Swapped 2,1,3,4 (Intel)

When the wrong FP format is seleced, the interpretation of the values (in the Modbus master) creates really bizarre values, like 3.2987^-16

Every Modbus master should have a selection choice (buried somewhere) for FP format a or b.
- Modscan32 uses FP/Swapped FP,
- Honeywell uses FP B/FPLB,
- Kepware has 'Data Encoding' check boxes

"First word low in 32 bit data types" is their alternative to Use default Modbus byte order.

Actually, Modbus does NOT define the word order, Modicon, the author/inventor of Modbus used the 4,3,2,1 order, but the standard does not define that as a formal word order for FP.

I think you need to try the alternative floating point format to see if that doesn't resolve the interpretation issue.

 

[SiriusMark]

danw- It's a Nuflow MCIII flow analyzer. Sorry, I thought I'd put that information in there, but I realize now I did that in an email to someone else and not here in the forum.

I'm actually looking through the documentation for the meter right now, trying to see if I missed something.

 

[danw]

It has a choice of standard (Big Endian) format or a few registers are made available as little endian byte swapped:

You want to use the first listed one Floating Point (FP) with two registers [conventional Modbus], do not use single register Floating Point (FP32).

This is the page D-11; these (below) are the Little Endian byte swapped registers.

 

[SiriusMark]

I don't mean to sound ungrateful, because I definitely appreciate the confirmation, but I've read all of that. Read it first yesterday, and then some more last night, and then again this morning. It all makes more sense to me on each reading. I noticed, specifically, the part about "The standard word ordring for multiple register data types...is for the most significant word to appear first in the message."

Then, in Ignitions documentation, you get this: "When reading and writing 32bit values from/to a Modbus device, the low word comes before the high word. By checking this option, the high word will come before the low word. The Modbus specification does not include a section for reading and writing 32bit values and as a result device manufacturers have implemented both methods."

So I tried selecting reverse word order and I'm getting the same symptom.

I did try Modbus Poll, but the documentation for that program specifically states that the modbus devices need to be pulled off of any other network in order to test them. Due to a variety of factors, I can't actually do that. The data in the NuFlos is being accessed across the Digi's via the network for use in ILink on a realtime basis and they don't want me to upset that link. What that does tell me is that everything else is working, it is definitely some part of the interface with Ignition.

I'm going to try to put the word order back to normal in ignition and then use the registers on Page D-11.

 

[SiriusMark]

Lol...I notice you saw the same thing, sorry man, I'm a little bent out of shape.

 

[danw]

In the on-line manual under
Modbus Drivers > Modbus Ethernet > Device Configuration
Ignition offers the choice of FP Little Endian:

Another way to screw up is to read one register from one floating point and the other register from the succeeding floating point, which can happen with multiple FP values in successive registers when your addressing is off by one.

There's also the zero based addressing option:

All the tools are available, you need to pick a format and make the format common on both ends.

If it were me, I'd do like Diat150 says and read battery voltage at decimal register (4)17045 (using function code 03 Read Holding Register) because it's a number that is not wildly changing, it will be a recognizable, intelligible value.

 

[SiriusMark]

Got it. Thank you, everyone.

I did have to select the reverse word order, to start with. For some reason, I also had to disable Ignition's address mapping function and manually enter in the addresses for each tag. Initially, even after I selected reverse word order, I was using the address mapping function and still getting bogus data. So I made a few new tags and manually entered in my addresses and addressing format and finally started getting something that made sense. I still don't know why the address mapping function wouldn't give it to me, you have the option to choose all of the same addressing formats as you do when entering it manually. Either way...its stabilized now. I should be able to finish this project now. Thank you again, especially for all the technical help on the nitty gritty of Modbus.