Digital input behavior question

[walter-donovan]

PCI-6143 with rotary encoder wired to PFI0 & PFI1. Labview pgm written in 8.5 full. Source code runs fine (on other development

computer with USB-6211 board) but hangs like it's eating 100% cpu time in the destination computer. This machine that it must run on has LV 7.1 installed and some 7.1 executables. I installed DAQmx 8.8 on this machine with LV 8.5 support. I am trying to run the executable on this machine as LV 8.5 is not installed.

If I enter MAX, select the board and run test panels I get conflicting results. If I choose digital I/O on either channels 0 or 1 I get all 8 lights constantly on. There is no signal. But if I go to counting, use either channel for the trigger and count edges I get activity. Am I missing something? I need to rule out these problems before I start trashing my souce code to find a bug that doesn't exist.

[walter-donovan]

A thought....

This machine ran an earlier version of the compiled program. It was a very trimmed down version compared to what it is now. When I installed the new executable I first uninstalled the old. Along with that, it looked like it uninstalled a bunch of National Instruments drivers, whatever. Is it possible that the uninstall is lame enough that it robs some things the software or devices need to run? After installing the new executable, I tried to reinstall the whole NI driver disk (DAQmx 8.8) but it went too fast to do anything other than to install LV 8.5 support which I switched on. 

Is this telling me that every time I install a new version or build, I'm going to have to waste an hour uninstalling and reinstalling all the NI drivers? Did they get trashed by the executable install routine?

[Jason_D]

Walter,

You say that you uninstalled the old executable what do you mean?  You can uninstall the Run-Time engine which is needed to run whatever specific version of LabVIEW you are using.  The Uninstall for Add/Remove Programs is very specific and allows you to target exactly what you want to remove.  I assume when you are talking about the exe install you are using an "Installer." 

Do you have the same hardware on the client computer?  Does this 100% utilization only happen when you run the executable?  To you see an error or anything?  Have you tried making a Debuggable Application?  Can you also verify the proper drivers and runtime are being used?  Are the machines similar in specs?

[walter-donovan]

You say that you uninstalled the old executable what do you mean? 

  My old executable was installed on the client computer and ran well.The app is still under development so when I needed to install the next build, I uninstalled the old

executable using Windows "Add/Remove Programs". My app is all that I uninstalled, not any  NI drivers, apps, overhead, etc.

You can uninstall the Run-Time engine which is needed to run whatever specific version of LabVIEW you are using.  The Uninstall for Add/Remove Programs is very specific and allows you to target exactly what you want to remove.  I assume when you are talking about the exe install you are using an "Installer." 

 I believe you're referring to NI files. I didn't touch them at this time but here's the history of when I did modify them. When I first installed the old exec (using Add/Remove programs

and a LV generated installer) it did not communicate with the hardware correctly. Hardware (client) is a machine with PCI-6143 and PCI-6071e, interboard cable (can't remember spec), Labview 7.1 complete program (not just runtime). My fix was that I took the 2 CD set of DAQmx (v8.8), drivers, etc, etc and loaded them onto the client. I did not install every option on the setup, i.e. for LV support I only chose 7.1 and opted against C++ and all languages not relevant. After that install, my exec worked correctly as did MAX. 

Next time I modified any NI files was after the uninstall of the old exec and install of the new app. When my exec didi not work, I entered MAX in an efort to verify board and sensor communications. This is where I discovered this anomaly: In test panels I could use PFI1 as a trigger for a counter and read output but as plain digital I/O all lights lit and there was no reading of the PFI1 signal. I speculated that my uninstall may have removed some NI overhead that was needed to communicate. My attempted fix for this was to try to reinstall theDAQmx, et al. The only option I changed at that time was to check he box for LV 8.5 support (since my exec was written in it). The install was very short compared to the normal half hour required. My belief is that it only installe the LV suport and didn't touch anything else.  After this my exec still did not workbut I didn't even have to try it to know. I had already run test panels and got identical misbehavior.

Do you have the same hardware on the client computer? 

 No. Completely different. Development computer has one USB-6211, MAX 8.8, LV 8.5. Client has PCI-6143, PCI-6071e, MAX 8.8 (originally a much older version, LV 7.1.

Does this 100% utilization only happen when you run the executable?  To you see an error or anything? 

 Yes, only when I run the exec and only when I run it on the client. No error but I haven't written much error handling into the app yet. Requires a very hard reboot (power disconnected and battery out).

Have you tried making a Debuggable Application? 

I haven't made a debuggable app. I can't see the need until I can get hardware to work using MAX. 

Can you also verify the proper drivers and runtime are being used? 

 Ah hah! No I can't. This is the basis for my questions. When I installed my version 1 app, the NI installer obviously installed much more than just my .exe. There are hundreds

of files in my build directory. I suspect that the installer added the NI runtime files so they should be correct for the app. My fix of installing all the NI overhead files (MAX, DAQmx,

etc) should have brought all drivers up to date I think? Is it possible that my uninstall removed runtime files (seems feasible)? My install of the version 2 exec should have put back the RT files but could it have messed up the drivers?

Are the machines similar in specs?

No. Outlined above.

 Am I correct in thinking the anomaly I had in MAX shows incorrect behavior? PFI1 is PFI1 and should not function in one test panel routine and refuse to function in another?

Do I need to completely remove all NI drivers and erload the 2 disk set of NI files? If that is the case I have an important consideration.

This system was purchased as a custom package along with a program to do a specific data acq and analysis. We took delivery of the hardware loaded with LV7.1 and a custom executable. We were not given source code as the author wanted to market this system as a product. The author has retired and there is no possibility of getting source code. The author also reserved our copy of LV7.1 for his own use so we didn't even get the disks to reinstall it if necessary (even though we paid for it). When the system was delivered there were numerous bugs including some that rendered the app incorrect as an exec while it ran in the LV environment. If I uninstall the NI overhead files to reinstall, isn't there a possibility that I will remove some original drivers that could disable a very expensive program? Same goes for LV7.1. I could replace it with 8.5 but suppose there is overhead from 7.1 that is necessary torun the 7.1 exec. I am confident that my new app will work on anything with 8.5 installed but can't afford to cripple the original 7.1 app. I have the disks to reinstall the 7.1 app but no way to reinstall 7.1 if the program refuses to run without it.

Sorry for the length of this reply but I really wanted to give every bit of info that could be relevant.

[walter-donovan]

Anyone?

I'm really dead in the water here.

[walter-donovan]

Am I in the wrong board? Wasn't sure where to post but it looks like this is the wrong place. Digital question on multifunction board using MAX. Question is really about software but none of the board categories.

[Jason_D]

walter,

I don't understand exactly what you mean by no reading of the PFI1 signal related to Digital IO?  Either way can we verify if the digital lines work elsewhere?  If you switch hardware do they work (eliminating software).  So you cannot change them at all you click the buttons there and they do nothing?  You are absolutely correct that if we cannot get the hardware to work through MAX it is almost surely not going to work in LabVIEW. 

[walter-donovan]

If you enter test panels you have a few choices. Analog, Digital, Counters.

If I enter digital and select port 0 (the only one there), hit "Start", all 8 lights go on and stay on. This is presumable telling me that lines PFI0 through PFI7 have a high signal that doesnt change no matter what the input lines are actually receiving.

If however I select (in test panels) "Counters" I set up to poll counter 0, select "edge counting, and trigger as "PFI0" or PFI1" (both are input from optical encoder), the lights for bits 0 and 1 blink merrily away, exactly what (I think) they should do.

One way, it works. One way it does not.

Have I stated this clearly this time? Please let me know if I am still being unclear.

[Jason_D]

Walter,

Test panels for the Counter is edge counting and will always work.  At the same time depending on the speed of the signal coming from your encoder it may not be fast enough to update for you encoder.  What speed is the encoder going at?  Can you slow it down or tie individual lines high or low?

[walter-donovan]

Encoder is plugged into the board but sitting on the computer console. It is not rotated by any machinery. I turn it very slowly by hand.

What do you mean  "Test panels for the Counter is edge counting and will always work."? Counting is set up to count every time the PFI0 signal changes so doesn't that prove that PFI0 is taking input? If I turn the encoder, the counter updates. If I stop turning it, the counting stops. I have set it so PFI0 is the trigger.