I am having a very strange issue using the PI data historian to send data to a Windows application via MODBUS TCP. PI's technical support has been unable to figure out what is happening and I'm hopeful someone here may have an idea.

The issue is that PI is sending data from hours ago. The data it is sending appears to be correct it is just being received late. For instance, there is a temperature value in PI that reads 100 at 10:00 (for the entire hour) and 110 at 11:00 (for the entire hour). The Windows application (MODBUS slave) receives a value of 100 at 11:00 and then 110 at 12:00. The application is getting data an hour later than it should. Note that PI source tags are updating and sending data every 10-15 seconds.

Also note that we are using PI tags configured the same way to send MODBUS data to a SCO UNIX application and we do not see the lag on that system.

I'm reasonably sure that the issue is with PI as I don't seem to have similar issues using MODSCAN. Does anyone have any experience with PI-MODBUS and a data lag? I've pretty much exhausted everything I can think to try.

Thanks.

 

I suspect that PI is only storing the data once an hour and that is the data being sent. See if there is some way to change how often the data is stored and if that fixes your problem.

Usually these type of products can be configured to store data on either a timed basis or when the data has changed by a certain amount.

--
Bob

 

When you say "Pi Is sending" do you mean the PI Interface sending data to the PI server?

Some things to check (though I'm guessing OSI already asked you this) ....

1. First - Check the TimeZone Settings and especially check the Daylight saving settings. Ensure that your data collection node and you PI server nodes are using the same time source

2. Who provides the timestamps for the data? (Presumably it is the PI interface software, not the MODBUS TCP Interface). If the PI Interface computer is 1 hour out then the timestamps will be 1 hour out.

3. Have you checked for compression & deadband settings in the PI tag. Make sure the deadband is set to zero.

4. Is the queue emptying properly?

Rob
www[.]lymac.co.nz

 

Bob and Rob,

Thanks for the input. I struggled with trying to describe the problem I was having and I think this caused some confusion. The values for the temperature are actually changing very frequently (every 10-15 seconds) and PI is sending MODBUS data as soon as the tag changes.

We have verified compression and deadband settings and they appear to be OK. The points are for an electric generating unit. The unit came online at 10:30 this morning and the source tag for the temp jumped 900 degrees immediately. The output tag that is used to send MODBUS data is still showoing and sending a value of 100 degrees.

In regard to the time settings I don't think this should be an issue. We're not interested nor are we sending time stamped data. We simply want to send the current value through MODBUS.

As far as the queue emptying goes, OSI doesn't seem to think this is an issue but I'm not sure. It really seems like something in PI just can't keep up with the data coming in.

Scott

 

Hi Scott, Sorry more questions ...

So, we are talking about 2 separate PI Server tags here? (a) The PI Server input tag which gets a temperature measurement from the generator and is updating correctly every few seconds (b) The PI Server Output Tag which is updated by the PI server and sent to another windows app but is not updating correctly - its 1 hour behind. Is that correct?

So, when you say the output tag didn't "update" at 10:30 am, where did you observe this? ie, did you check the value of the PI Output tag in the PI Server archive using the piadmin tools ? Is it only the receiving application that has the wrong value?

How does the data get from the PI Input Tag to the PI Output Tag? Are you using Performance Equations?

Where is the Interface that writes to your windows app running? Is it on the PI Server node or another node elsewhere?

You and I may not care about timestamps much, but trust me, PI does. Everything in PI is timestamped and PI makes extensive use of the timestamp. Again, please ensure you have checked the timezone settings and daylight savings time on EVERY computer. Exactly 1 hour is a very suspicious number.

Rob
www[.]lymac.co.nz

 

Rob,

Yes we are talking about separate PI tags and you are correct in your assessment. I have a PI input tag for the temperature. I then use that input tag as a source tag for a PI output tag. The output tag is supposed to take the current value and send it to my application via MODBUS. The interface that writes to my application is on a PI node.

Believe it or not the lag between the input and output tag changes. The unit ran yesterday and the time difference was about 1 1/2 hours. When the PI interface is restart on the PI node everything is sync'd up for a little while. Then you can watch it slowly start to lag. I have seen lags of as much as 12 hours.

My application is for environmental reporting and is required to be on standard time. I know that PI is on daylight savings time but this did not seem to matter when the data was being sent to the UNIX system.

If you'd like I can send you a PDF graph of the data from yesterday's run. It shows exactly what happens. Doesn't look like I can post a file here but feel free to e-mail me [email protected].

Thanks.

-Scott-

 

Thanks Scott. I have no real answers for you but perhaps the following can help...

PI <b>always</b> timestamps your data using UTC. - i.e. Greenwich Mean Time without daylight savings. However, your client time zone settings affect how the time is displayed when you look at the data. Anyway, from your answers, that doesn't seem to be your problem.

Have you checked the Disk IO rates and queue length on both the server and your environment monitoring application PC. The PI Interfaces are quite IO intensive and I have seen some instances of seemingly slow running systems that were caused because the DISK IO can't keep up.

Was this exact same interface writing to your UNIX system properly. If so, what did you change to make it write to a new Windows application?

So, the interface is running on your PI Server node? Have OSI suggested moving the interface to a different computer? Have you tried this?

Rob
www[.]lymac.co.nz

 

Rob,

Sorry for the delay in responding. I've been out of the office for a few days.

I think I'm going to look at the timestamp issue a little closer. Not sure it matters but who can tell. The PI server is on EDT and my other application is on EST. Since we are in test mode I think I'll change the time on my app server.

We have been in touch with OSI and have been looking queue lengths and such. It was originally thought that this was an issue and OSI gave us things to try. Not really sure yet if it helped. And we have tried other PI servers to send the data as well.

As far as the UNIX server goes, we pretty much just changed the IP address on the PI tags that we were using to send data to the UNIX box to that of the Windows one. Nothing else really changed. Maybe SCO uses UTC time and that is why we haven't seen the issue there.

I'll let you know if any of this works.

Thanks,

-Scott-

 

FYI. It appears as if the problem is with one particular interface. I have 5 other interfaces running now and none of them are experiencing any sort of lag.

Once I talk to OSI and determine the differences between the interfaces I will update this post.

-Scott-

 

Rob,

Don't know if you're still checking this or not but wanted to give you an update. It appears as if we have the problem fixed. It took OSI a couple of weeks and several tweaks to the interface to get it working. Don't have all the details on what they did but we are looking good.

-Scott-