FieldPoint Write LabVIEW Error -33499

[Mr._Jim]

Hi all,

I'm going to try to explain this as coherently as possible:  

I've got an application running on a cFP-2200 that uses LabVIEW 8.6.1 and FieldPoint 6.0.4.  This application is communicating with some IO modules on a FP-1601 over Ethernet.  I've set up my devices in Project Explorer, and they match the hardware configuration exactly.  (I double checked all of the IPs and everything.)  I compile the RT executable and place it on the controller when it's connected to my development machine.  Then I disconnect the controller (physically) pick it up off of my desk, and connect it outside in our equipment.  (This equipment is on an isolated network - I can't connect to it from my development PC)

Oddly, I'm getting error -33499 on my FieldPoint writes to the FP-1601 bank of modules.  The description for -33499 is "Cannot communicate with the specified remote module."  I've troubleshot lots of FP errors before, but I've never seen this one.

There's a PC on this isolated network that runs my client application that communicates with the controller. On that PC, I can see the modules in MAX and on the distributed system manager.  I even checked the aliases file on the RT controller, too,and those IPs match up.  I know the modules are communicating -- just not with my RT application, and I can't find any instance of this error code anywhere on the NI site. .

Can someone shed some light on why this would be occurring?  Has anyone ever gotten this error code?  Hopefully I've provided enough information.

Thanks,

Jim

P.S.  Due to the proprietary nature of the code, I can't post it.  I could probably take screenshots of portions of it, though.

[DirkW]

 Did you put the project IAK file next to your EXE file, so it finds the correct remote target information? See the LINK forall the IAKL options you have.

KB Link

DirkW

[Mr._Jim]

Hi Dirk,

Thanks for the tip.  It's funny because I thought of the IAK file right away, but in my RT build hierarchy I couldn't find an IAK file.  Do executables on RT require this file as well?  Is it possible that I didn't include it in the build specification somehow?

Thanks very much,

Jim

[Mr._Jim]

Just an update - I added the IAK file beside the EXE on the RT target and had the same results.  (The errors still show up)

Jim

[Mr._Jim]

Continuing my monologue, for what it's worth, this slightly dated KB indicates that the IAK file is not used by the RT executable on a FieldPoint target.  Rather, the startup.aliases file appears to be in use.  I'm going to venture that that's what's being referred to by the following statement in the KB:  "When the VI is run embedded on a FP-20xx a ini configuration file is used instead."

Even so, that KB refers to error 32810, not error -33499.  I'm mostly adding this information here in case someone else runs across the issue someday.

[Will_S.]

Jim,

When connected to your development machine does everything work properly? You may want to see if you can first get everything talking properly while connected to your development machine, then disconnect the controller and confirm a successful connection, and then finally move the system. If this would require the equipment in the isolated network, try a simple version that just reads a battery voltage.

Also, have you tried reformatting your cFP-2200, reloading the application, and testing connectivity from there?

[Mr._Jim]

Hi Will,

Thanks for your response - you've brought up some great suggestions.   Actually, on Friday before you posted your message I brought the controller back to my desk (the development machine) and completely reformatted it.  I also built the Fieldpoint hierarchy over again in Project Explorer, and placed all new tags in my FieldPoint IO VIs.  Lastly, I checked fpremote.ini on the cFP-2200 to verify that the IPs match the textual aliases that appear in the FP tags.

After all of that I thought for sure that everything would connect properly, but as of this morning I'm still getting some instances of error -33499.

Another detail that may be useful is the following:

We've got sort of an unusual setup.  The cFP-2200 controller resides outside of a hazardous area, while two FP-1601s reside inside the hazardous area.  The cFP-2200 checks to ensure that it's safe to power up the 1601s and their associated equipment, and then turns them on after the check completes.  I would expect a few errors to be thrown when initially trying to connect to the 1601s right after they power up, but the -33499 errors persist indefinitely and they seem atypical among the errors I've seen in the past.

I'm sure by now that this is as clear as mud.  If you have any insight, though, I'd be very appreciative.  Do you know, specifically, in which instances -33499 shows up?  There are several errors that result from bad connections and it can seem a little ambiguous at times.

Thanks very much,

Jim

[Mr._Jim]

More interesting information:

When I write a test VI to set a single IO point on either 1601s (powered up manually), the following are true:

1. When selecting a tag and clicking the "browse" option, the controller view and the project view match in configuration.

2. I can write to one of the LEDs on either 1601 without a problem. (No error is thrown)

3. I can't write to IO modules on either 1601 without getting error -33499.

4. I can see the IO modules and set values in Distributed System Manager.

5. I can see the IO modules and set them from the PC using LabVIEW.

In short, I can set values on the 1601s themselves, but not their IO modules, and this is only a problem on the controller itself.

Should I try reformatting the controller again?  I don't know what else to try.

[Wayne.C]

Mr. Jim,

Suggest you look at the fpremote.ini file that is created when you deploy to the cFP-2200.  Make sure that the I/O on the FP-1601 are being properly called out.

ni-rt/system/fpremote.ini

[Mr._Jim]

Hi Wayne,

Yep, I checked that already and it matches up upon an initial glance...  I suppose I could scrutinize it line by line, but I'm pretty sure it looks OK.  I'm getting desperate enough that I may just do that, though!  It's either that or reformat again.

Thanks for the suggestion, though.

Jim