cFP error 33443

[Space Man Spiff]

Hello-

I'm getting the following message from my cFP2020 running a RT VI:

33443
bad channel status reported by several channels. At least one channel is in one of the following states:
unconfigured,
bad status "A",
bad status "B":
FP Read.VI

In looking on the forum, I found a message suggesting wiring to RLY modules could be the cause, specifically voltage spikes when switching DC power into inductive loads. We removed all power from our RLY421 moudules, but we get the same error.

I'd appreciate any help you can offer.

Dave

[Aaron_G]

Dave,

On which module or modules are you seeing this error? The 33443 error code is returned when you read multiple channels and one or more channels are simulataneously reporting an error. If you were reading a single channel item, the error would be more specific.

If the channels are always reporting a bad status, it can be caused by several things. For example, if a [c]FP-TC-120 module had one or more channels that were not hooked up, you would see this error whenever you read the 'All' channel. Alternatively, this can also be caused by a bent pint on the IO module.

Please provide additional detail on what channel/modules you are reading when the error occurs.

Regards,
Aaron

[Space Man Spiff]

Hi Aaron-

I've got the following modules on the cFP backplane:
AI-111
AI-100
DI-301
DI-330
RLY-421

I've been using the "all" path in input to the FP Read.VI

I have unconnected inputs on the AI-100, DI-301, DI-330 and the RLY-421 modules.


Regards-

Dave

p.s. - The watchdog you helped me with seems to be working. thanks

[Aaron_G]

Dave,

If you are seeing the 33443 error when reading from the cFP-DI-301, cFP-DI-330, or cFP-RLY-421, then the cause is most likely a bent pin or hardware failure.

If you are seeing the error from the [c]FP-AI-100 or [c]FP-AI-111, the most likely cause is an 'Out of Range' reading on one or more of the channels on the module. Since you have unconnected inputs on the [c]FP-AI-100, I would set them to a bipolar range (e.g. +/-24 mA). An unused input that is configured for a unipolar range may be slightly negative when left unwired (depends upon the calibration) and will return an error in that case.

For the [c]FP-AI-100 and [c]FP-AI-111 modules, you may wish to check them via NI-FieldPoint (in MAX) to see what values are being seen. The FieldPoint-MAX interface can be run at the same time as your LabVIEW code (for enet interfaces). You should look at the status column for the various channels to determine which one(s) are reporting the bad channel status. Once you have identified which channels are reporting the bad channel status, check the wiring and the sensors. If the wiring/sensors looks okay, you may wish to check the input channel itself as the [c]FP-AI-100/111 current inputs are only rated for over-current protection of 30 mA. It is not unknown for the current input resistor to be damaged by over-current conditions.

Regards,
Aaron

[Space Man Spiff]

Aaron-

You were right.... we found that the error was originating from the AI-111 module for inputs which were connected to other instruments that were powered off. My assumption was the powered off instruments would be sourcing 0 mA, so that shouldn't be a problem.... guess I was wrong. We powered up those instruments and the errors were eliminated.


While I'm bothering you... do you mind if I ask you another question?

I've got a section of code that seems like it should work, but doesn't. Here's the situation... I have a boolean switch on my front panel that is used to either enable or disable outputs to the RLY-421 modules. In a sub-VI (the attachment), the boolean switch drives a case structure so that either the acutal outputs are written to the output modules or default values are written to the output modules. When the code is started, the boolean switch is set to false and everything looks fine.... modules 7 and 8 have the appropriate states. If I then set the front panel boolean switch to true, the RLY modules transition to their default states... and everything is still good. When the boolean switch is set back to false, Mod7 and Mod8 indicators on the VI show the correct states, but the RLY modules are still in their default states. By triggering other events, I can get RLY module 8 to go to the correct conditions, but module 7 doesn't budge. We've tried swapping the physical RLY 421 modules, but the problem stays with a module 7 (i.e. problem doesn't move with the module).

Thanks again for your help.

Dave

[Aaron_G]

Dave,

Try setting the On Change Inputs to the FP Write VIs to False. The FP Write.vi is re-entrant and remembers the previous values to compare the new value against to determine whether the write command is sent to the module. However, this feature is done based upon LabVIEW's re-entrancy of the VI. In your case, there will be 4 sets of the VI in memory, two per module, the one from the false case and the one from the true case. This means that the on-change in the default case will compare against the last value written in the default case value and not against the current value, thus it will not write the values. Likewise, the Write in the non-default case compares to the last value written which may not be the current state of the outputs, possibily causing the write to be ignored. By turning off the On-Change option, you will always write to the module.

Regards,
Aaron

[Space Man Spiff]

Aaron... you are da' man!

Your suggestion worked great! Setting the value to false made the modules behave as expected. It also seemed to clear up another issue, which was that I had to reload the VI on the target if I stopped the VI (using the normal while loop controls)and then tried to run it again. Without reloading, the Vi just seemed to stop...??

One last quick question..... On the watchdog timer config VI, I was assuming that the units for the "timeout (1sec)" input were seconds. Is that true? I've gotten some restarts of the cFP on start-up of the VI when that value was 2 to 4, but it seems to be fine at 10.

Aaron, I can't tell you how helpful you have been. I and my colleagues at NASA really appreciate your help.

Regards-

Dave

[Aaron_G]

Dave,

The input is in seconds. One reason that you may be having unexpected re-starts at start-up is the load and start-up times of the VIs. If you have a 2 second timeout, but your code takes 3 seconds between when you initialize the watchdog and whack it, then you will reset quickly.

Out of curiosity, which NASA facility are you at?

Regards,
Aaron

[Space Man Spiff]

Aaron-

thanks for the clarification on the timeout issue. I'm at NASA Glenn Research Center in Cleveland. My group develops advanced solar cell technologies.

Regards-

Dave