FieldPoint Family
FieldPoint Write LabVIEW Error -33499
Okay, at long last I think I've figured it out. It turns out that the problem was with fpremote.ini, thought not in the manner we had originally thought.
The answer to my own question is:
Error -33499 is the error that is appears when a FieldPoint read or write times out.
The error explanation can be a bit misleading, but in the end it makes sense:
"FieldPoint: Cannot communicate with the specified remote module. Please make sure the correct I/O module is properly installed, then reboot the network module on which the VI is running."
Translation:
"Fieldpoint: A connection was attempted with the specified remote module but was unsuccessful within the specified timeout period."
There may be other causes for this error, but that's how I managed to see it. For the sake of keeping my timed loop from hanging up, I had cut down my connection timeouts to 1000 ms, thinking that 1 second should be plenty of time to connect on an isolated network where the modules are close together. Well, it's not, and don't ask me how I know. 
As soon as I set the timeout to 5000, I was able to connect from onboard the cFP-2200.
For future reference to others, the FieldPoint connection timeout is typically set in MAX by right-clicking the FieldPoint target under "Remote Systems" and selecting "Communication Timeout Settings." However, one can ensure that the settings have applied by observing the values in fpremote.ini. This is especially useful when working with multiple projects and IAK files. The default is 15 seconds, which to me seemed like an eternity, especially when you're on an RT or embedded system.
I hope this information helps someone out someday, and thanks to everyone that offered advice.
Jim
Does it take this long every time, or just the first time you access the I/O?
Good question. My initial tests (and my gut reaction) would seem to indicate that the first connection takes the longest, though I don't have any real concrete evidence. ...Although I've been watching my timed loops carefully, and if it took longer than a second every time it would have locked up the controller a long time ago. For that reason I strongly suspect that the initial connection takes the longest. I suppose I could set up some timing mechanism to figure out how long it takes to write a value. I'll let you know if that yields any useful information.
Jim
Ugh. I think I spoke too soon. Sorry if I got anyone's hopes up. While what I posted earlier about timeouts may be true, there's something else rather bizarre going on here:
Before I begin, let me first say that I've set timeouts on both of my 1601's to 15000 milliseconds, which is the default value. This should be plenty of time to connect.
Here are the exact steps I take that yield predictable results every time:
1. Reboot the cFP-2200 controller without any application.
2. Make a simple VI (on the cFP-2200) that writes one remote channel on an FP-1601; In this case I'll say "FieldPoint\FP Res\FP-AIO-610 @3\Output 2". I'm writing zero volts to that channel.
3. Save and run the VI. It returns error -33499 on that channel consistently.
4. Using the same VI, switch to a different channel. In this case I'll say "FieldPoint\FP Res\FP-AIO-610 @3\Output 3". I'm writing zero volts to that channel.
5. Save and run the VI. It works perfectly, or at least it returns no error.
6. Go back to the original channel. (in my example, "FieldPoint\FP Res\FP-AIO-610 @3\Output 2" ) It always returns error -33499
It doesn't appear to matter which channel I select first; the first channel always returns the error while the second one does not. This poses somewhat of a problem.
Once again, I'm using a cFP-2200 and two FP-1601s with various IO modules, and I'm using FieldPoint 6.0.4.
This sounds like a new one...
Jim
Hi Dirk,
Thanks for getting back to me. It's definitely interesting, no doubt about it!
Does this error appear with an Input/Output on a different module as well or only with an Output on yor AIO module?
The error only occurs on the first channel written to on a module that is partially or all outputs. Specifically, it occurs on the following modules we have on our 1601s:
FP-DO-403
FP-DIO-550
FP-AIO-610 (Three of these)
Without exception, it occurs on every output module we have on our two 1601 banks, including digital outputs. To my knowledge it is not occuring when reading inputs.
How is your 1601 connected to your 2220?
The two FP-1601s are on a single switch (Phoenix contact) with the cFP-2200
Is everything connected to a single private network?
It was on an isolated network until a couple of days ago when we moved the application onto the controller and I needed access to the network from my development machine. Not much traffic gets routed onto that subnet, though.
Or are you using the second ethernetport of your 2220?
No, we're not - we're just using one port. Actually, because it's a cFP-2200, it only has one port.
Does this error happen with both of your 1601 modules?
Yes, every time on both of them. Mine must be posessed or something!
are these up to date in firmware?
A very good question. In MAX (v 4.5.0f0), both of my 1601s have the "Firmware" tab grayed out. It also reads "Current Firmware Version v0.00".
However, under Distributed System Manager, I can see a variable under \FP\Control\Version. The value of the variable for both 1601s is "502".
If you're still unable to
repeat my results, I could FTP or email a full image of the 2200 and I
could give you our exact configuration. I know it probably doesn't
seem necessary to be that meticulous, but I'm telling you, I'm not
making this up!
Thanks for your help.
Jim
Hi Dirk,
Can the 1601s be locked? I was aware of the controllers themselves being lockable, but I wasn't too sure about the 1601 network modules. You might be onto something because the "lock" button is also grayed out in MAX for each of those controllers. The 1601 modules have been here a few years, so it may be the case that someone working here before me locked them down. If that's the case I'd be interested in learning how to undo the password.
I also may have figured something else out. I had already sent the AE I had been working with an email, which she may have forwarded to you by now. In any case, I let her know that I had reformatted at least twice before without any luck, but this morning I tried it again. This time I only configured the IO using Project Explorer, refraining from using MAX as I've been used to in the past. So far things look promising - the issue may be "cured," but I won't know for a little while. I kept a copy of all of the files on the 2200 in case that's useful in diagnosing what may have been the issue. (Assuming I'm past it)
In any case, I'm very grateful for the assistance thus far and I should know fairly soon whether I've gotten past this.
Regards,
Jim
Hi again, Dirk,
In the last couple of days I've done some substantial testing to be absolutely sure that the problem is gone, and I can "officially" confirm that everything is working now. While I can't say with absolute confidence what eliminated the strange connection issues, I can say with reasonable certainty that the following was a solution for me:
I completely reformatted the cFP-2200 controller as I had done a couple of times earlier
I reinstalled FieldPoint on the controller. (6.0.4)
I used only Project Explorer and not MAX to set up module configuration
I very carefully named the cFP-2200 and the two FP-1601s consistently with the tags in my LabVIEW code
After this, I never received error -33499 again. While my steps above may seem trivial, I think what may have happened during earlier attempts was that the configurations in MAX and Project Explorer were stepping on each other somehow. The setup in fpremote.ini appeared to be consistent with what I had configured, but I may have missed something.
Thanks for the assistance, both from Dirk and the other applications engineer that I won't name here.
Regards,
Jim
