12-17-2008 05:32 PM
Hi - I'm trying to use FTDI drivers to simulate a COM port from an USB connection. Most WinXP SP2 or 3 machines have no problem, but I have one machine where having run MAX to ensure correct port operation, on quit and relaunch MAX shows a port conflict. This can be cleared with the available controls, but recurs the next time MAX is started. The settings do not stick. The subsystem (a TTi QL355TP power supply) does not see the communication either on this machine, and is OK on the others.
Environment: LV 8.2.1, MAX 4.1 or 4.2.1 . Would prefer not to upgrade LV to more recent version at this stage. LV 8.2.1 re-installed.
Any help or nudges much appreciated.
12-19-2008 07:49 AM
Hi,
I think we will need some more information before we can be of more assistance. What is the port conflict you are seeing, have you got a screenshot? Are there any significant differences between the systems that work and the systems that don't? There may be a corruption on the installation of MAX, in which case a reinstall of the MAX database may be advisable.
Best Wishes,
12-23-2008 05:35 AM
Thanks for reply. I can't obtain a screenshot at the moment, but the MAX display is a standard diagnostic I've seen on other occasions. Select a COM port in 'Configuration', and the "Port Settings' tab at the bottom has 'Conflict' added. The screen area above shows two columns of 'Settings', one from MS Windows, the other from MAX. These columns disagree in (for example) speed or flow control. Pressing 'Validate' aligns the two, 'conflict' disappears, 'Save' at top of screen appears to save correctly, and everything's fine. Except that the application this setting relies on still has a communication problem, and if you restart MAX the screen display resets to how I described above!
Re-install or repair of NI software does not fix it, nor does re-install of USB drivers. A corrupt data file on this machine would fit the observed evidence - are you able to point me to all the files that MAX may write? A corrupt MS Windows Registry entry might do it also, I guess. Do you know of any tools for checking or fixing such problems? The problem was triggered by a clumsy cleanup of installed NI software that was aborted partway through. The system is installed with a customer making a clean install of everything difficult and we are right at the point of having to write an unattractive workaround that uses a lower level serial interface to allow us to use NI Spy to eke out the required functionality.
Any help appreciated.
01-05-2009 03:05 AM - last edited on 01-30-2012 03:06 PM by JordanG
Hi,
The MSI Blast Utility is very useful for repairing and removing National Instruments software. It is attached below.
Best Wishes,
01-10-2009 11:11 AM
I eventually found the answer to this problem to be corruption of both the MAX database and the VISA configuration file.
The KnowledgeBase article: " How Do I Recover From MAX Database Corruption?" at http://digital.ni.com/public.nsf/allkb/86256F0E001DA9FF86256FFD005B827C details how to force a rebuild of the MAX database. For simple systems at least, just rename the two directories identified to force a complete rebuild, and tidy up manually afterwards if necessary.
The VISA information is in the file: C:\Documents and Settings\All Users\Application Data\National Instruments\NIvisa\visaconf.ini. This is the location in MS WinXP and is normally a hidden directory. Stopping MAX, renaming this file and restarting MAX will force a rebuild.
At this point everything magically started working again. Thanks to those who put time into thinking and replying on this issue.