03-13-2013 08:41 AM
Hi ThiCop
Yes correct, it was not included in the last file. What I did and that made the program work is. I completely copied all the files they sent me in the system32. Everything. Because in the help they supply they say that only one needs to be put in system32. After I copied them all it was working.
In attachment are is zip I received from Testo.
I will sent you 2 files. The first one is the one I received first and the second is the one I received later. I received 2 different files because my start/ stop pump was not working. They send me an updated toolbox but with this one noting was working anymore. So I just deleted that and continued with the first received one.
I realize that my program still needs a lot of cleaning up. I am trying to get it working first and later do the finishing. Everyday I learn more and more on how to work with LabView. I know for sure this will not be my only program I write. This is fun programming...
Greets
Vincent
03-13-2013 09:56 AM
Hello Vincent,
Just to be sure:
So it actually is working now without dropping connection?
03-13-2013 10:22 AM
03-14-2013 11:16 PM
I send the last replay with my phone. Now I see that this replay is not very clear.
So I received a Toolbox on October. This established the communication well but it dropped out after a few seconds. After plugging it in and out the communication was OK again. Only with this toolbox the start/stop pump was not working.
I received a new toolbox in January with this toolbox noting was working any more. We hade a error return straightaway.
So I deleted all the ddl's I put in the system32 from the last toolbox and put back the once from the first toolbox. But I have sent both toolboxes to you.
Hopefully this is more clear.
Greets
Vincent
03-15-2013 05:12 AM
Did you communicate this last issue to the people that sent the toolbox?
If yes, then what was their reply?
It could be that the issue you had in the first toolbox is resolved in the second one, but something else is going wrong.
Then it might be a better idea to debug/use their latest version.
03-15-2013 05:21 AM
did you change the windows power management options?
01-22-2012 02:20 PM
In this topic we will discuss some of the common problems that have been observed using USB devices with LabVIEW on Windows operating systems. Many of these points are also applicable to other environments but the examples will be use the Windows 7 OS.
FAQ 1 : My USB device stops working unexpectedly.
The first thing to look at is the OS power saving options. There is a global trend towards developing "Green" electronics and energy star ratings are getting fairly common. "If its not being used shut it off" is nothing new. Cavemen learned how to bank a fire to preserve energy that would otherwise be wasted. Likewise, the Windows OS has a power saving feature to shut down power to the USB hubs when no user activity is present. In Automated systems this feature can cause problems since removing USB hub power will shut down the USB device. Solution: Use the device manager to change the USB hub Power Options.
FAQ2: I set the power options and my device connection is still unreliable: Remember, those computer USB ports are often the cheapest that can be mounted on the chassis and share the PC system power supply to supply USB Power. Most uses of USB are temporary connections like a thumb drive or a camera. These connections do not require high reliability since the user is right there interacting with it. Power surges and fault tolerance at worst cause the operator to retry the data transfer. Automated systems require a bit more robustness. Solutions:
1) ALWAYS use an external self powered hub. Perform your engineering due diligence and inspect the devices specifications too- If you can't find them for that device that should clue you to seek an product from a vendor that WILL publish their specs.
2) High noise environments require the use of ferrites on the USB cable- and don't buy the cheapest cable either! The cheap ones are poorly shielded.
3) PROTECT the HUB connections- If you have a USB2.0 device and Joe User plugs in a 1.0 device in a open slot managed by the same hub- Bingo every port on the hub may back convert to USB1.0. WORSE there are a lot of damaged or marginally engineered USB devices out there. Joe User's device may cause power fluctuations when it is inserted or removed from the hub just don't let it happen!
FAQ3: I am testing USB devices and the OS can't find them anymore.
This is a Plug-n-Play feature that deserves some exposure. When you connect a P-n-P device the OS remembers its serial number in a HKEY (Hive-Key) registry entry. This is helpful when (for example) you want a specific instrument, Say an NI-USB-6008, to show up as a DAQmx Device with VISA Alias "MyDAQ1" every time it is plugged it. On the other hand, If you want to test a line of USB-Serial converters this can be problematic since the P-n-P driver will mount the first serial number as "COM3" and the next as "COM4" add infinitum until the enumerator controller in the registry and VISA recognized aliases get used up. Solution: Use the Windows registry API and the Hardware Configuration API in LabVIEW to clear unused VISA Aliases and HKEY entries. Speak with your staff IT professional about HKEY structure and possible side effects before developing a plan to edit registry entries.
03-15-2013 11:31 AM
Hello Jeff,
That could indeed be causing USB issues.
But shouldn't this then also cause a problem in Testo's applications?
As far as I have understood their own application works perfectly for a long period of time.
03-15-2013 11:49 AM
@ThiCop wrote:
Hello Jeff,
That could indeed be causing USB issues.
But shouldn't this then also cause a problem in Testo's applications?
As far as I have understood their own application works perfectly for a long period of time.
Maybe their app pings the USB port every so often to keep it from going to sleep?
03-15-2013 12:15 PM
Just wanted to get the OS out of our way first before digging a little deaper. There do seam to be some potential issues with the dll calls. Number one. the error handleing is non-existant and should be addressed.
Looking at this vi
Called in a timed loop set for exacly one second gives me a bit of pause. Especially since the return value is not inspected for any errors reported by the device.
Since we have the source dll and header we can import the exposed functions to LabVIEW with all those nice options set. I've attached the library and report. Errors did occur in my import but they should be solvable with the right dependancies on the machine.
03-15-2013 09:56 PM
Hey Everybody
Thanks for thinking with me and helping me on the right way. Just for the information. I have tried to change the power management options in Windows before. I found this topic also on the NI forum and gave it a try. But no success.....
Also I have tried to put the timed loop in 2 seconds but still the USB stopped communication.
Greets
Vincent