Hi, I am looking to communicate to Texas Instruments LMP91300 and am looking to use the TI created LabVIEW VI for their SWIF communication protocol given in the below link. I am currently in the process of purchasing LabVIEW Professional 2019 and want to ensure compatibility with that VI. Currently, I am using TI designed GUI to communicate to the chip through an evaluation board, but this is very tedious and manual process and I want to automate it in LabVIEW.
I initially sent this in to NI as a support ticket, however NI technical support said they cannot make the VI work due to some errors and they closed the ticket.
I contacted TI and they said they do not support the device anymore so they cannot give me any help on making their VI work.
I know this VI works because I know of an organization that is currently using it.
Can someone here help me?
The problem is going to not be the LabVIEW version (except that it will only work in 32-bit LabVIEW due to the use of several DLLs) if there is a problem, but more likely issues with Wndows version.. It does seem to use some version of WinUSB (likely an old one) that may have trouble to work on Windows 10.
Hi thanks for the reply. NI did try it on windows 7 because of this potential issue but it did not work still. I am attaching the error screen they sent me when they did debugging. It seems to be related to the locked DLL file.
The first error looks like something goes wrong when building an executable. It's impossible to say anything more from this screenshot.
The second is the famous 1097 error and usually means one of two things:
1) There is an error in how the DLL interface in one or more of the Call Library Nodes is configured. That's the most common problem as this part is VERY critical. This can be things like the wrong data type for one or more of the parameters being used then what the DLL expects, and a very often happening error is that the programmer who created the VI is not very familiar with memory management in C programming and assumes the same lazyness as in LabVIEW is possible, which is a VERU wrong assumption. Every buffer passed to the DLL needs to be preallocated properly, there is no way the DLL can resize the buffer itself if it decides it needs to do so, it can't even know how big the buffer actually is that is passed in from the caller.
2) There is a bug in one of the DLLs that get called.
In all my experience on these forums over more than 20 years I would guess that error 1097 was almost always caused by reason 1). In my own work it was caused equally by reason 2) but that was mostly with DLLs I had written myself.
NI also tried to open this VI directly, not through the executable. So, this would default to your option number 2, suggesting that there is an issue with the DLL. I would be surprised if this is the issue because this zip file publically came from TI, and if there was something wrong with it I would imagine that someone would have stated so.
NI also tried to open this VI directly, not through the executable.
That's completely irrelevant. One error is happening during build of the executable and could indicate that one of the DLLs does some rather hairy stuff during load and/or unload of the DLL, that might have worked on the old Windows version on which this was developed but doesn't on a modern Windows 10 version.
So, this would default to your option number 2, suggesting that there is an issue with the DLL. I would be surprised if this is the issue because this zip file publically came from TI, and if there was something wrong with it I would imagine that someone would have stated so.
That's not how this works. There is in most cases option 1 the culprit. Many of these errors do not always trigger the trampoline that LabVIEW generates around Call Library Node calls to detect memory or stack corruptions, or other errors that can be caused by a wrong calling configuration, or buffer preallocation. It may SEEM to work flawlessly for a long time until you change some seemingly unrelated code that alters the memory locations of objects in such a way that the actual corruption suddenly affects vital parts of the LabVIEW environment. Also different LabVIEW versions can suddenly make such errors more apparent because the memory layout is different or LabVIEW learned an additional way to detect some corruption. Independent if LabVIEW detected the corruption or not, the code was misbehaving all the time already and corrupted something but that may not have triggered a crash back then.
Of course seeing that it uses WinUSB there is a very good change that the WinUSB dll and friends that are used just doesn't work well with a modern Windows version. In any case debugging of this issue is a major feat and you can of course go and try to randomly replace some of the DLLs with never versions, but the chances that you fix the error in that way rather than introduce new ones is however very small.
1097's are horrible, as that error basically only tells you "this data doesn't fit with my assumptions!".
So the only thing you can read out of it is: You've made something wrong.
Well unless you have a solid understanding about DLLs, C headers and how a C compiler aligns data elements in memory and all that stuff, or know someone who does and is willing to do it for you, then I''m afraid that yes this is going to be a dead end.