Changing the Timeout on a FieldPoint Read in LabVIEW

[Mr._Jim]

Hi Folks,


I thought about posting this on the FieldPoint board, but it seems more related to the FieldPoint API in LabVIEW.  I'm trying to read from FieldPoint in a Windows environment using "FP Read (Polymorphic).vi" straight off of the palette.  Some of the FieldPoint hardware may or may not be turned on, so I'm watching for error 33162 to determine whether the hardware is connected.  (Not my primary method of determining this, but I need to ignore this error nonetheless) 

Here's what I'm noticing:

1. In Windows, when the FieldPoint hardware is off, the first execution of FP Read.vi takes exactly fifteen seconds on the mark.  Each subsequent read takes almost no time.

2. In a Windows executable, every time the executable is launched, the same thing happens.

3. If several FieldPoint reads for various channels on several controllers are placed in parallel within the same VI, that VI can end up sitting for minutes while waiting for all of the read operations to time out.

In any of these cases, whenever the VI or VIs get past the initial read operations everything is fine and life is good.  I've included an example.  In the "debugging" directory, "Timeout Test.vi" demonstrates the concept.  In the project file there is also a build specification for an executable version.


My question is this: Is there any way to set a timeout period that's less that 15 seconds?  When we're starting up the application, the FieldPoint hardware is frequently turned off.  (It eventually is powered, at which point we begin monitoring it)  This lag is making our application unresponsive for several minutes and I'm hoping that there's a way...  I'm using LabVIEW 8.6 and FieldPoint 6.0.3.  I just upgraded to 6.0.3 because I observed the same issue in 6.0.2.

Thanks in advance,

Jim

[G-Money]

Mr. Jim-

                  Unfortunately I don't know of a way to do this easily. The FP Reads have to wait until they are timedout by the system to continue. If you used a Real Time system, you could make use of the deadline input which tells the code to continue if an event doesn't happen in a certain amount of time or a Watchdog that watches the network to make sure that the FP is connected and throws an error if it is not (you can then turn that error into an event that would bypass the Reads). Hopefully someone else will post something spectacular but as of right now, I don't know of a way. Keep us posted if you do find something. Thanks!!

[Mr._Jim]

What's up G-Money?

Thanks for getting back to me on this one.  You're right about the RT usage, because I used to call the same code within a timed loop on an RT platform before.  It always worked beautifully in that context, but now the timeout lag has shown up once I used it in Windows code.  It's too bad that there isn't any native way to set a smaller timeout.

After some tinkering around, I did manage to find a workaround.  Lately my favorite tool has been the Distributed System Manager, and I've found yet another use for it.  I can use it to determine what the IO tag names are on the FieldPoint target.  Now that I know what the URLs look like, (e.g.\\10.0.0.2\FP\1DIO\15) I can either read from or write to the FieldPoint channels using Datasockets/LOGOS.  (Illustration below) That way, I can set my own timeouts, and it's incredibly responsive using this method.  For example, I can pound the digital outputs on the FieldPoint at 10 ms intervals and still get a precise response.  One caveat:  it still takes about two seconds to connect initially, but that's much better than fifteen!

I realize that this probably isn't orthodox usage of FieldPoint, but it works too well to pass up.

Thanks again,

Jim

Message Edited by Mr. Jim on 11-25-2008 12:35 PM

[8bitbanger]

Hi Jim, You may find the this KB useful (as well as a few linked at the bottom of this page): http://digital.ni.com/public.nsf/allkb/C4E77D7E9BECBAFE86256C6200544289 In general there are two timeout settings under MAX: "Timeout" and "Connect Timeout". I played with these for all of about 10minutes and didn't get far. I suspect the solution to (our!) problem lies here, as both are coincidentally default to 15000mS.  My hack was to implement a ping routine and only begin FP Reads/Writes after successful communication is established. 

HTH,

Jamie

Message Edited by 8bitbanger on 11-25-2008 01:52 PM

[Mr._Jim]

Thanks a lot, Jamie.  That KB seems to address the issue directly.  It seems like there should be a way to accomplish the same thing programatically, though.

Regarding the ping routine, though, in the past I did the same thing.  We actually got pretty elaborate with it here, figuring out how MAX locates FP modules via a UDP broadcast.  (Maybe I shouldn't be posting this on NI's forum)    I would have resorted to a true ICMP ping if I could have figured out how to implement it in an RT environment.  Regardless of the method, if the FP target was offline, we didn't try to read.  I guess I was hoping not to have to resort to that this time around, though.  The setting in MAX sure looks promising, considering it's exactly 15 seconds.  I'm defintiely going to try that.

In the meantime, I'm sticking to the datasockets method.  

[8bitbanger]

Hi Jim,

'Glad to help. BTW I'm not sure what happened with that message - the formatting went straight to crud!

Anyway, I say that I didn't get far with those settings because the lag still existed. I read somewhere that the data reads are cached, so if a connection is lost, it will still read data just fine until timing out.

When I changed the timeout values in MAX, it still seemed to take a long while to return an error. There are two distinct error codes for fieldpoint connections which may be worth looking into. One is connection lost and the other for no connection established (IIRC). I believe these correlates to those two timeouts.

The ping is certainly just to keep the front panel responsive on startup- otherwise our end users are clicking 'Stop' and nothing is happened (and subsequently CTRL-ALT-DEL'ing it). It is a third-party subVI I found on the net that simply parses a CMD.exe response. Not the best approach, but it works for the time being.

I am experimenting now with dynamically loading the IAK file and extracting the LOGOs names for direct use. I like importing the IAK file into the Project (as a target) because I know that all of my VI references are correct. However I've also found that if you *update* that IAK file, I have to *remove* the target and re-add for the changes to populate the project. <shrug>

But anyway, to keep things on topic: have you experimented with timeout values?

[Mr._Jim]

Hey Jamie,

We're really turning up the technical jargon factor on this thread.  

Well, to be perfectly honest, I really haven't experimented with the timeouts much more.  I've had much better luck with my own FieldPoint driver.  Of course, it's not really my own because I didn't implement Datasockets.  I spent yesterday rewriting the architecture that I was using for FieldPoint calls so that all the FieldPoint communication uses Datasockets instead.  Now, instead of fifteen seconds, the control loop only hangs up for two seconds in the worst case scenario.  The interface is in a separate loop, so when the problem showed up users really didn't notice the symptoms unless they tried to stop the top level VI.  With either implementation, all of the calls are in parallel and I used reentrancy to increase parallelism.  I'm a little nervous putting it on the cFP controller, though, because this method seems a little heavy on resouces, since you have to open a new Datasocket reference for each IO tag on FieldPoint.

I have heard of dynamically loading IAK files, and I think I did that at some point back on 7.1.  I didn't extract the LOGOS names, though.  I ran into the same complications that you did, though - when you update the IAK file you can get into trouble.

Hopefully this information will be of use to someone at some point.  

Jim

[8bitbanger]

Hi - I'm wondering if we can get some input from NI here. I have changed both the Timeout and Connection Timeout in MAX and see no difference in the timeout behavior. Are these values specefic to the IAK and/or MIS file?

To test I am leaving the ethernet disconnected - not so much worried about connection loss for now, but lack of initial connection. The IAK referenced is the last loaded in MAX. The initial read from a FPref (constant) times out at 15seconds. Each subsequent read from that same FPref returns immediately.

Thoughts?

Jamie

Message Edited by 8bitbanger on 12-01-2008 07:33 AM

Message Edited by 8bitbanger on 12-01-2008 07:34 AM

[Mr._Jim]

I wish I could revoke the "solution" flag... I thought we had a definative answer, but it looks like I was wrong.

[JeffOverton]

You can. It's under the Options bar for the post you Solution'd.