Overwrite corrupt cal constants?

[Kaitlin-N]

Hi CalLab_Mark,

Please see page A-80 of the document below for the block diagram of the 6052E. This should help demonstrate the internal hardware used for calibration.

http://www.ni.com/pdf/manuals/370503k.pdf 

However, it does appear that something inside your device is damaged and needs to be repaired. However, if you would like to try clearing the EEPROM, here is an article that you might find useful.

Clearing the User-Accessible EEPROM on an NI-DAQmx Supported Device

http://digital.ni.com/public.nsf/allkb/E6719B82A2C0C2EC862573B600165510?OpenDocument

I also noticed that you are working with another engineer on a formal service request. For the sake of not repeating ourselves, we will consolidate further progress on this issue to the formal SR. We will work together to determine if this is in fact an RMA and if there is anyway you can fix this error using calibration executive.

Best regards,

[CalLab_Mark]

From the Declassify document:

"Many NI-DAQmx supported devices store calibration constants on the EEPROM, but this area of the EEPROM is not user accessible (can only be written to by the driver). This is written every time the device is calibrated.  There is no factory default for these values."

Game over for me.  If the EEPROM isn't accessible & has no factory defaults then there's nothing for me to restore.  The constants may be corrupt and can't be changed since the calibration process that overwrites them won't run.

[billko]

---

@CalLab_Mark wrote:

From the Declassify document:

"Many NI-DAQmx supported devices store calibration constants on the EEPROM, but this area of the EEPROM is not user accessible (can only be written to by the driver). This is written every time the device is calibrated.  There is no factory default for these values."

Game over for me.  If the EEPROM isn't accessible & has no factory defaults then there's nothing for me to restore.  The constants may be corrupt and can't be changed since the calibration process that overwrites them won't run.

---

IMHO something that is so obviously out of whack shouldn't be calibrated anyway.  Bite the bullet and get it fixed instead of trying circumvent the calibration limits.

[CalLab_Mark]

Nothing in the forgoing has been about circumventing anything.  It's about finding the cause of .1V offset on the aignd channel and bogus stored temperature data.  I'm pursuing a possible common cause (corrupt data).

[billko]

---

@CalLab_Mark wrote:

Nothing in the forgoing has been about circumventing anything.  It's about finding the cause of .1V offset on the aignd channel and bogus stored temperature data.  I'm pursuing a possible common cause (corrupt data).

---

The what does:

Are you telling me I can't manually adjust the cal constants or overwrite corrupt temperature values on this card?  There are no physical adjustments on these cards and I don't believe there are any damaged components.  These are software adjustments and should be possible with proper support.  Just tell me how...

mean?

[CalLab_Mark]

It means I want to try resetting the stored data to factory defaults (which I find there are none), or manually entering something close so the card will CONTINUE the cal program without halting on an error.  IF the program will continue and IF the card has no hardware defects, the cal constants will be overwritten and errors minimized to within specs.  That is the outcome I want.

I'm a metrologist running an ISO 17025 cal lab--I don't circumvent limits and tolerances.  I also don't send in a card for a $600 repair that may be a data problem correctable for $0.

[billko]

---

@CalLab_Mark wrote:

It means I want to try resetting the stored data to factory defaults (which I find there are none), or manually entering something close so the card will CONTINUE the cal program without halting on an error.  IF the program will continue and IF the card has no hardware defects, the cal constants will be overwritten and errors minimized to within specs.  That is the outcome I want.

I'm a metrologist running an ISO 17025 cal lab--I don't circumvent limits and tolerances.  I also don't send in a card for a $600 repair that may be a data problem correctable for $0.

---

I have worked in a metrology lab, myself.  I'm glad you have the same reservations as myself.  I grow suspicious when I see things like that because I've also worked in places where their cal lab wasn't so scrupulous.  I understand where you are coming from now.  Sometimes some goofy glitch writes such bad data to memory that the calibration routines cannot cope.  You wanted to be able to write "reasonable" data to memory so you could give the cal another chance.  Then you could make a better judgement on whether you have to send it out for repairs or not.  (My totally subjective observations have led me to believe that sometimes relatively unknown hardware companies will make it impossible to do this so you have to send it in and they can make some money.)  Sorry for the doubts. 

[CalLab_Mark]

Well at least there are 2 of us on this board who know a metrologist isn't a weatherman 🙂

I'm not clear what you mean by "relatively unknown companies" but NI sure seems to have deliberately created hurdles that make it impossible to maintain their hardware.

[Henrik_Volkers]

I assume you have documented the actual offset/gain/linearity of the inputs.

Would a false internal reference value (either due to corrupted eeprom or a drifted ref) explain the charts?

If you run an external calibration 'by hand' (well, call the driver routines in your control rather than in the comercial 'do it for me' package 😉 )

and assuming that it is the software that stalls if the drift is higher that 100mV (80mV, whatever)

you can provide any DC voltage to run the calibration/adjustment. 🙂

That card is off anyway, so why not try a adjustment that is off 10mV (for the card)  and do that 10 times?

[CalLab_Mark]

Henrik,

Thank you for your thoughtful reply.  I have tried what you suggest:  Since all inputs are off the same -.104V I adjusted the cal standard so the displayed value was exactly 7.500V (input 7.604) but I still got the same error.  I've tried other ways to "fool" the program to no avail.

I'm not a programmer and have no experience creating Labview routines so I don't know if the External Calibration programs I've been provided (by everyone except NI) are "by hand" or pre-packaged.  I have another parallel topic on here where I ask if the External Calibration program can be modified to ignore the error and proceed to the adjustment phase.  Do you have any insight if this is possible?