Loss of Fieldpoint control

[iainhp]

I'm using LabView 6.1 and a Fieldpoint 1600 Ethernet network module (connected to module are 16 channel discrete output module, plus two 10 channel analog modules) in a lab environment. The lab is very noisy so have installed network to fiber and fiber to network for the network run to the Fieldpoint box.

The system functions well until some event (probably a
high voltage arc) stops any further updates to the Fieldpoint modules. LabView is still running without problem collecting data from a high speed digital board in the computer. If we stop the LabView program and restart it, the FieldPoint modules start working again.

Any ideas what causes this problem (ie how can it be prevented from occurring). We're controlling a 5,000 A supply
and the guys get a little nervous when we lose control of it (yes we have an emergency override switch)!

Thanks.

[Aaron_G]

Question for you. You say that you can stop and re-start the LabVIEW program and the problem goes away? Or do you have to physically cycle power to the module.
If you are stopping and re-starting LabVIEW, then in all likelihood, the event that is occuring is a temporary network communication failure. FieldPoint error handling is a little bit different than DAQ error handling and if you are using shift registers to pass the error from one iteration to the next, it can prevent the LabVIEW program from attempting to re-connect to the ethernet network module. (Side note: this was changed in FieldPoint Explorer 3.0.1 so the lost ethernet links were considered recoverable errors, previously they were considered un-recoverable).

If on the other hand, you need to cy
cle power to the network module to get it responding again, then you really need to shield the FieldPoint modules from the offending EMC event (e.g. mount in a shielded metal enclosure that is ground and have ferrite noise suppressors on the power and ethernet lines (not needed on ethernet if it is fiber optic at the point it enters the enclosure)).

Regards,
Aaron

[iainhp]

Interesting point. I'm still using Fieldpoint Explorer 2.0.4. When we first started having problems about 6 months ago we had to cycle power to the Fieldpoint modules to recover. I have since taken over the code and had to recode much of the LabView to make it cleaner (and incorporate everyone's change requests). We are in the process of building aa cage around the Fieldpoint modules. Have found that running it on a UPS that is disconnected from wall receptacle helps. Are the Fieldpoint modules overly sensitive to noise?

Currently only have to restart LabView. Will modify code to close and reopen connection on the fly if error detected. Also will try and upgrade to FE 3.0.1

Thanks for you input.

[Aaron_G]

The fact that stopping and re-starting LabVIEW makes the problem go away, tells me that if you watch the error cluster, you will in all likelihood see error code 33163 or 33162 (connection to the module has been lost). This may come about from electrical noise that caused a communication failure (dropped packets), or possibly electrical noise that caused the FP-1600 to reboot itself. The problem as I mentioned earlier, is that the FieldPoint LabVIEW VI's, prior to the current revision of FieldPoint Explorer, would consider it a fatal error and not attempt to read anymore, even though communications can be recovered. If the FP-1600 is re-booting, then ferrite noise suppressors on the power supply cables should be added. Assuming the FP-1600 is re
-booting, I would expect that LabVIEW will report the disconnect 10 seconds after the module started to reboot itself (ethernet timeout is 10 seconds for the NI protocol), and for communications to be resumed within 25 seconds. An easy way to test if the LabVIEW code is at fault is to have FieldPoint Explorer open at the same time. If LabVIEW is disconnected, but FieldPoint Explorer is connected, than it is the problem with the error handling.

The FP-1600 D.O.C. specifically states that the FieldPoint bank should be mounted in a shielded metal enclosure.
Regards,
Aaron

[iainhp]

Thanks for the further info. Have upgraded FieldPoint Explorer to latest version - will be running again this afternoon - will see what happens. As a side note, the FP stuff is mounted inside the grey metal (NEMA?) enclosure that NI supplies. It is GND'ed, as is the door (the paint doesn't conduct very well). We have not found these type of boxes to be the greatest EMI shields and are in the process of building a copper cage around the FP structure which will include shielding on power, etc... After your note we will pay a little more attention to the shielding issues.

One last question - does it make any difference whether I use the FP vi's or use DataSocket to communicate with the FieldPoint system? ie is one method more tolerant of n
etwork errors than the other?

[Aaron_G]

The FieldPoint VI's are more versatile in that they can be used with both ethernet and serial FieldPoint controllers with no changes. DataSocket VI's can only speak to FieldPoint Ethernet controllers. Generally speaking, the FieldPoint VI's offer better performance and more advanced (FieldPoint specific) error handling. However, the FieldPoint VI's, at the present time, will only work to talk to attached I/O when running embedded in an FP-20XX controller. They can not be used to talk to other FP-20XX/1600 modules from code that is embedded in an FP-20XX. Using DataSockets also gives the advantage of being able to dynamically change the range of a channel.

Regards,
Aaron