imaq example in x64 environment of visual studio 2019

[rwe]

I can imagine your English is super fantastic as perfect as Shakespeare's and your logic training must be very critical, leaving you only left opinion without supporting facts. Oh, poor Karen.

[rolfk · Accepted solution]

---

@rwe wrote:

I can imagine your English is super fantastic as perfect as Shakespeare's and your logic training must be very critical, leaving you only left opinion without supporting facts. Oh, poor Karen.

---

That was uncalled for! He did not have any exchange with you in this thread other than this remark and your snide remark was way over the top to a pretty neutral question!

Yes I missed the fact that you had mentioned the software versions in message #5, sorry! And your response talking about 5th floor left me pretty flabbergasted and in fact wondering what you were talking about. Only after writing my responses did I go through the entire thread again to realize my mistake. So please calm down.

About your refusal to debug the example to see which call fails and causes the program to terminate prematurely, that’s your business. I was under the impression that you had a problem that you wanted to solve but if not, that’s totally fine with me. 

As you have noted, active development on Ni-IMAQ has long stopped. It’s a legacy driver kept mainly alive for LabVIEW users who still use old (and discontinued) NI frame grabbers. The C interface is a side product and the according examples were most likely never tested by NI on x64 since by the time x64 got a reality for Windows, IMAQdx had already been released and was supposed to completely replace NI-IMAQ.

The Visual Studio solution file in some of those examples is VS2005 so it's pretty safe to assume that nobody from NI ever looked at them for over 12 years.

Only the fact that NI repositioned its priorities and didn’t consider Vision and Motion hardware anymore as a core product, did prevent the further development of IMQdx to completely replace NI-IMAQ and allow NI to completely obsolete NI-IMAQ.

Another thing that could have helped early in this thread would have been to mention the path where these examples are installed. I had never seen them before despite being installed on all machines where I have LabVIEW and Ni Vision Acquisition installed, since it never had occurred to me to try to use the C API when I have LabVIEW installed on my machine.And it’s unlikely I will ever use it but if I do, then definitely the IMAQdx interface and not the NI-IMAQ one. Not sure when I last used  NI-IMAQ in LabVIEW but it must be more than 10 years.

[rwe]

Thank you for your patient, peaceful and constructive response.

I knew my previous remark is not friendly, but the question is who made this? He can guess I was using bad translator to write these posts, how can I not imagine he was not a language master? Repaying virtue with virtue. If his comments were facts, that's all fine like pointing out my typo, grammar error, then concluded that I am not a native speaker. However, how can he judge someone by guessing and humiliate to say using a bad translator? If google translator can match with me even my English is not good, I believe google CEO will still be super excited. In US, judging someone's accent or language or color, of course is definitely discrimination or racism. I moderately call him/her Karen which presents the racist, so do I have any problem? He/she has been this forum for long time, should know that what is respective and friendly. You ignored his/her racism remark and thought I was snide. I know this is far from the topic, but I still want to clarify.

Why do I refuse to debug NI official IMAQ ANSI C examples? Because it is beyond my ability and responsibility. (1) The ability. In fact, I tried to debug so that's why you can see the loaded missing files in previous posts, but I am an expert in C. I can make functions work, but fully understanding is still challenging.(2) The responsibility. if it is my personal projects, it is totally OK for me to debug for tens or hundreds of hours, but it is NI official ANSI C imaq examples.  NI company should make sure these examples can work in x64 mode. I searched a lot of questions online and their experience told me that if it is possible to be the manufacture's problem, just contact the manufacture instead of putting useless effort.

Our group has the total asset of NI products more than 50k$. Currently, my project involved 2 PCIe 1437 frame grabbers and 1 USB 6363. The daqmx ansi C official examples for USB 6363 can fully work in both x86 and x64 modes. I also successfully integrate the daqmx ansi C function in my x64 C++ program, so I am very confusing why the imaq ansi C can not.

I am not sure whether PCIe 1437 frame grabber is old. After I saw you mentioned about the IMAQdx, I immediately tried to find them with all of header, lib and C++ examples. They can be successfully complied and run in x64. Thank you very much for your constructive help. I appreciate your time and effort since it is a long time to finally partially settle it down. The result is at least perfect for me which is owing to you. I will integrate these IMAQdx C++ functions into my project with IDAQmx to see if it can work.

Thank you again. Hope you have a great one. All the all the best to you.

[rwe]

Thank you thank you again.

[rwe]

Let me end this topic. It's a pity that the NI official did not respond this optic directly, but clarified in the post below updated Jun 1, 2021 which behind this topic. They clearly mentioned that "The NI-IMAQ driver is not fully supported at this time but basic 64-bit C support for IMAQ is installed publicly at the next location". For my understanding and experience, for imaq x64 C functions, some may work and some may not, which is only a basic support, and they are not willing to maintenance 64 bit imaq.

Just leave comment here so that no one any more will spend unavailing time on 64 bit imaq C programming. 

https://www.ni.com/en-us/support/documentation/compatibility/17/ni-vision-development-module-and-vis...

[rolfk]

You're using all the time the term IMAQ as meaning a specific software package, but there are in fact three different packages from NI that traditionally were associated with IMAQ. 

- IMAQ Visions development library, nowadays sold as Vision Development Module

- IMAQdx driver, which is part of the Vision Acquisition Software

- NI-IMAQ driver, legacy driver for old and generally long ago obsoleted hardware, also part of the Vision Acquisition Software

And yes the only thing NI is ever going to do about NI-IMAQ if anything at all, is to simply remove it entirely from the VAS installer. It's old, legacy and for hardware (analog frame grabbers) they don't sell anymore for a long time. All the devices currently sold, which aren't that many anymore, are also supported by the DAQmx driver API. The main reason it is still in there is likely that it requires extra work to remove it from the install build scripts.

Your claim in your message #13 to be an expert in C, doesn't really go well with the fact that you find even the most simple single step debugging a challenge. And your interpretation of the Visual Studio messages about loaded modules missing is entirely wrong. There is nowhere a single message that indicates that the Windows program loader could not find a specific module. The fact that it loads not the same (amount) of modules in x64 mode simply has to do with the fact that the Windows interface for x64 was streamlined and unnecessary modules were simply entirely removed or are only loaded when they are really needed. The difference in loaded modules between x64 and x86 signifies absolutely nothing in terms of your problem, but only that indeed Windows 64-bit is not the same as Windows 32-bit. And I would not consider comparing Windows loader messages in the debug console as debugging at all, especially if the interpretation of those messages is flawed. They tell you nothing about what is really going on.

The problem is that the examples are written in a way that they simply exit as soon as a Windows API call returns an error. That is the nature of examples, you don't want to clutter an example with tons of nice error handling code that typically takes up a lot more effort and code than the actual functionality it tries to show. Apparently one of these functions early on returns an unexpected value which makes the executable simply terminate. If it is to much asked to single step through an example to see where that happens and why, then you obviously don't really have any interest in getting a solution, which of course is your right if you choose so. But it is neither expert behaviour nor will it bring you very far in software development in general.