Is there a SANE way to handle errors on ENET devices?

[CoastalMaineBird]

LabVIEW 2010, Windows Vista, NI-DAQ mx 9.2.2, ENET chassis, NI9211, NI9219

My large app has a piece of code I call a DAQ manager, with several basic commands: DAQ Config, DAQ Start Sampling, DAQ Start Recording, DAQ Sample, DAQ Stop Recording, DAQ Stop Sampling, DAQ Shut down.

This DAQ manager is "boss" to several lesser "managers": one for SCXI, one for a DO board, one for an AO board, one for COUNTERS, one for CAN engine data, one for a group of analyzers sending UDP data, one for a different group of analyzers on a UDP link, and newly into the mix, one for cDAQ/ENET devices. It works fine when all is normal.

For years, I have saved the user grief by calling the DAQ CONFIG and then DAQ SHUTDOWN commands soon after they ask to start the test.

I report the errors and refuse to go on, since there's a problem of some sort, and they don't waste time setting up configuration stuff and calibration stuff, if they cannot run the test.

Well, it seems that ENET devices don't want to play along.  They are happy doing the DAQ CONFIG (where I create tasks, and set sampling rates, and such), whether the device is plugged in or not.

GRIPE #1:  Why is it legal to configure a task on a device that isn't there? Why no error?

So, OK, I change the hardware check to do a CONFIG, and then a START SAMPLING if the config went well, then a STOP SAMPLING and a DAQ SHUTDOWN. The START SAMPLING reports an error if the ENET device isn't there. 

GRIPE #2: Why does it take 13-15 seconds for it to figure out that the device isn't there?  The wire is only three feet long ;-).  If there's a timeout setting for that, I cannot find it.

OK, having found out that it does indeed fail with an error message now (instead of blindly proceeding), I plug the cable back in.

It's still not there!  No amount of waiting will bring it back online!

GRIPE #3: Why do I have to go to MAX and hit REFRESH, or reboot the computer, to get the device back on line?

Is there another way?

[CoastalMaineBird]

OK, some good news:  Updating the firmware on the NI9163 ENET carrier resolved Gripe #3.  Now it comes back on line automatically.

small GRIPE #4: During the UPDATE FIRMWARE process, a progress bar proceeds from left to right, 0 to 100%, and then back to 0, up to 100%, back to 0, up to 100%, over and over and over again. That is a misuse of what progress bars are for, IMO.

[Drew_T]

Steve,

To be honest, relying on errors from the device may not be the best way to determine if it is present.  There are some property nodes (see VI snippet below) that allow you to see what devices are connected, and various information regarding each one, including:

-Whether the device is simulated

-Product Category

-Product Type

-Product Number

-Serial Number

-Modules in a chassis (which you could then retrieve the above information about as well)

-and much more!

I think that checking the product types returned against the name of your product, in this case "cDAQ-9188", will save you some headaches, and be more consistent.

Drew T.

[CoastalMaineBird]

There are some property nodes (see VI snippet below) that allow you to see what devices are connected, and various information regarding each one

But all that info comes from MAX, or the config file for MAX or for NI-DAQ or somewhere; it doesn't come from the real world.  It doesn't tell me whether the thing is actually working or not.

For example, I ran that snippet and it showed me this:

There are my two ENET devices, plain as day.  I should mention that the whole DAQ power strip was powered OFF. So the ENET, cDAQ, SCXI, and PXI devices were all off line.

If I turn ON that power, and run it again, I get this:

(I have two real cDAQ chassis, named "TCMxx", in addition to one simulated one)

So it tells me that the cDAQ chassis is online, but that's not a problem for me, because the CONFIG process already tells me if it's not.

It doesn't change ANYTHING about the ENET entries, and that's my problem.

[Drew_T]

Steve,

I have confirmed that this is a known issue and has been reported to R&D with Corrective Action Request #295701. 

Thanks for the feedback!