08-12-2008 10:36 AM
08-12-2008 02:09 PM
I would verify that there are no bent or missing pins in the second chassis.
08-12-2008 07:16 PM
08-12-2008 08:34 PM
08-13-2008 11:46 AM
I was just thinking yesterday that the config EEPROM might have been frazzled. I will be back onsite tomorrow and will try your suggestion. Unfortunately, we have exactly one system (thus, zero known-good boards). We have ordered a second set so maybe we can recover and make the original one work again. There is a way in MAX to read/write the configuration settings? Thanks for the help.
-felben
08-13-2008 02:46 PM
Acutally, that reminded me of a simpler, preliminary test. The version of Max I was using was pretty old (around LV version 6 & 7), so I am hoping the driver for the card are still similar. Anyway, run RESMAN so that MAX will load the configuration of the board. If the board does not show up in slot zero (or not at all) the board is definietly messed up.
This also reminds me that you can have to board boot up in "factory" safe EEPROM settings. If you look in the manual, there is a jumper setting that will force the card to boot from the factory default.
Once MAX has reconized the board, you can right click on the device to get to the ?board configuration? menu. This will then let you upload or download a configuration file. Sorry I could not provide any more detail, this was over a year ago that I did this stuff...
08-14-2008 10:03 AM
Joe... thanks again for the help. Unfortunately, I tried all of this and it isn't making a difference. The PCI and VME cards are recognized by MAX just fine, so I think that is working. I first was able to download the configuration information (to a file) which I am now attempting to interpret as best as I can (it is simply a list of addresses and data values - not sure how to make sense of them... do you know where the definitions exist?). I then set both the VME and the PCI cards to their "default" settings and dumped configuration again just to see if anything changed. The behaviour of the card has not been affected. Finally, I set the DIP switch to force factory load with protection and again, no change in behaviour.
Tomorrow or Monday we should have a new card set... I sincerely hope that takes care of the problem because I am coming up with nothing here. Let me know if you think of anything else to try. Thanks.
-felben
08-14-2008 11:03 AM
No I don't know the definitions of the config file.
It seems that the MXI portion of the system is working. Can you write and read memory locations on the local board? In the card manual, there should be some basic registers you can read and write to. I would see if I could write to those values.
I am also assuming you have some type of breakout board and logic analyzer to look at signals? I would want to make sure writes are not corrupt for the address and data matches what you are sending to your memory device.
Hope this helps...
08-19-2008 11:01 AM
Joe... I had checked the VMEbus signals with an extender card and found them pretty messed up. Sometimes it kind of made sense, other times DTACK was not where it should have been.
We have now received the replacement card set and swapped out the VME-MXI-2 board... works perfectly. We also tried to write a "known good" configuration from the new board to the failed board, but it continued to fail in exactly the same manner. The failed board has been sent back to NI for repair/replacement (luckily it was under warranty). I hope they can tell us what happened to the board as it is a rather critical piece of our developmental test platform. I find it odd that nobody from NI every posted on this thread.... I suppose nobody is really using these old VME cards anymore?
Thanks for your suggestions.
-felben
08-19-2008 12:00 PM
Felben,
No problem on the suggestions. Good luck in all of your VME endevours!
🙂
Joe