dg_dog Posted February 6, 2016 Report Share Posted February 6, 2016 Have a dll for a spectrometer that will not work with win7. Works with on a xp computer but not another xp. Very strange...The Stellarnet company supplied this sample labview program. Upon initial run the program tries to initialize the spectrometer and looks for a 1 but gets an different number. Quote Link to comment
ScottJordan Posted February 6, 2016 Report Share Posted February 6, 2016 It's a Microsoft problem. See http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ This is not just a LabVIEW problem. Bottom line: LabVIEW 64-bit requires 64-bit .dlls. Because Windows. The 64-bit transition in Windows was an unholy mess. Consider that iOS went 64-bit in 2013 ...and nobody noticed, even though the hardware is far less compute-capable than your average Windows machine. There's really no excuse for the gibbering chaos that is 32-bit .dlls in 64-bit Windows. Try 32-bit LabVIEW? Your license entitles you to both versions, IIRC. Quote Link to comment
dg_dog Posted February 7, 2016 Author Report Share Posted February 7, 2016 Thanks for your thoughts.... Why would 1 xp system work and not the other...... Quote Link to comment
ShaunR Posted February 7, 2016 Report Share Posted February 7, 2016 If it were a bitness problem then you would see this error. You can also run the software without a broken run arrow to get a result. There seems to be little wrong with the LabVIEW end of things - you should be asking the supplier whats wrong with their DLL or looking at configuration of their system/device. Quote Link to comment
ensegre Posted February 7, 2016 Report Share Posted February 7, 2016 (edited) Wouldn't be the first time I run into a camera/spectrometer/framegrabber/younameit SDK which comes with a more or less maintained driver/dll/sample cpp program set for both bitnesses, whereas the labview layer part of it was less tested , and ended up with some calling convention mistake (here one example). Small companies may not have enough resources to test extensively every possible software and hardware combination they cater for, you can't blame them too much, especially if at least their postsale support is friendly and helpful. The dreadful case is when SDK development is outsourced and arguing is limited to the two-week window the subcontracted programmer has the device on desk. First thing first: do you have a statement from Stellarnet about 64bit LV support? I don't know if that is what you're referring to, but at http://www.stellarnet.us/software/#SPECTRAWIZLABVIEW I read "The software was entirely coded in LabVIEW 8.2 and interacts with the spectrometers via swdll.dll". Besides xp64 being itself quite unstable as 64 bit OS as I recall, LV8.2 was around fall 2006 about 2009. Yes, the same time as xp64. Edited February 8, 2016 by ensegre Quote Link to comment
Rolf Kalbermatter Posted February 10, 2016 Report Share Posted February 10, 2016 Wouldn't be the first time I run into a camera/spectrometer/framegrabber/younameit SDK which comes with a more or less maintained driver/dll/sample cpp program set for both bitnesses, whereas the labview layer part of it was less tested , and ended up with some calling convention mistake (here one example). Small companies may not have enough resources to test extensively every possible software and hardware combination they cater for, you can't blame them too much, especially if at least their postsale support is friendly and helpful. The dreadful case is when SDK development is outsourced and arguing is limited to the two-week window the subcontracted programmer has the device on desk. First thing first: do you have a statement from Stellarnet about 64bit LV support? I don't know if that is what you're referring to, but at http://www.stellarnet.us/software/#SPECTRAWIZLABVIEW I read "The software was entirely coded in LabVIEW 8.2 and interacts with the spectrometers via swdll.dll". Besides xp64 being itself quite unstable as 64 bit OS as I recall, LV8.2 was around fall 2006 about 2009. Yes, the same time as xp64. The first LabVIEW to have a native 64 bit version was LabVIEW 2009 for Windows. So this software definitely never was tested with that and the DLL is most likely only a 32 bit DLL too. That all said the OP has provided very little information to allow anyone to say what the real problem may be. From the description it would seem that it is not a 64 bit version. 64 Bit Windows XP was never really used outside of specific use cases as there were indeed many problems with it. So it would seem unlikely that he is using such a system and even more unlikely that he decided to install LabVIEW 64 bit on it. Also if it was a bitness incompatibility the VI would be simply broken and couldn't be run, but what he describes is that the VI returns some number rather than 1 as he expects. So the DLL can be loaded and executed by LabVIEW. As to IOS going 64 bit, that is not exactly the same. You can't really install arbitrary applications on an IOS device. It's either from the Apple App Store or nowhere at all! The App Store will only provide you with apps that are known to be compatible with your particular device. If you want to do your own thing you are all on your own and actually have to jailbreak the device; whoever does that is not going to be bothered by strange errors and incompatibilities! He rather sees them as a welcome challenge to get it working anyhow. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.