Where to appeal to support delphi

[Jenda]

I see that there is continuous interest in using NIDAQ in Delphi, I want to ask for restitution of the Delphi support!!

[Tiptop]

Hello,

There are two good methods for letting us know what you would like to see done.

1.) Use NI�s feedback page. If you go to ni.com and click on �Contact NI�, you can choose �Product Feedback� in the bottom left hand corner. Please do not discount this process; every piece of feedback is reviewed by NI.
2.) Contact you local sales representative. It is always a good idea to let these folks know what you would like to do, or why you can not do it with our current product line.

Best regards,

Justin T.
National Instruments

[Jenda]

Justin, thank you, I sent the feedback - ask for Delphi support in the NIDAQ today, let's see.
Jan K.

[ulrich_VII]

Is there any progress in this question

Would buy some M-cards with Delphi support

I think it isn't that difficult, to write a unit for the access to the DLL on the base of the old traditional unit.

[odissey1]

I found better Delphi solution. Starting from 2004, we no longer use any NI products. Since this DAQmx hassle started I found that tere are many companies making similar or even better DAQ cards than NI, which are actually supports Delphi. Plus, they are usually less expensive for same features NI cards have.  Another important thing for us is a drivers size (I do embedded design and software+OS must fit a flash card space) and for NI driver we are typically looking into extra 1GB of space (.NET+full set of NI-DAQms drivers for 100+ devices), while the driver size for single DAQ card from 'normal' company is less then 20MB typically. I think that NI targets mainly factory production environment where desktop PC or PXI chassy fits well and all data flows are slow (<1kHz). What surprises me most is that small companies able to provide support for Delphi, while NI tries to save cost here. Seems like MBA's mentality is taking over NI. Shame on NI. The other thing is that NI is actually predominantly a software company with primary goal of selling LabView with hardware production is on the second place at best (my guess NI outsources it mostly). So I am not surprised why they are not interested in support for other programming languages - who is going to buy LV then?

Regards,
Bob

[Aloika]

The absence of official support of interaction between NiDAQmx driver and RAD Borland (Embarcadero) Delphi is the actual problem. Many application developers want to support existing projects and develop new ones using the familiar programming environment. However, we suppose that new-created Delphi projects must support various DAQ cards and operation systems of the Windows family including 64-bit versions. Existing Delphi applications written with the legacy Traditional NiDAQ driver must be easy converted to work with a new NiDAQmx driver.



There are two methods to solve this problem partially.



1. Using TDAQ7.4 for Windows Vista. This method allows to use existing Delphi applications for Windows Vista x86 and Windows 7 x86. But this driver doesn’t support a lot of modern DAQ cards and doesn’t work in 64-bit operations systems. Using TDAQ7.4 driver for Windows Vista can be only a temporary solution.



2. Using wrappers for the nidaqmx.dll library. The limitations of this method are dependence between NiDAQmx version and wrapper version (changing of driver’s version involves changing wrapper); nidaqmx.dll functions are not well documented; there are strange bugs and memory leaks; 64-bit operation systems are not supported yet; working of this method is not guaranteed at all.



I want to propose a new solution of interaction of the NiDAQmx driver and Borland Delphi. The essence of the approach is described below.



1. Create .NET-assembly using Microsoft Visual C# 2008 Express Edition (for example), in which describe one or several objects contained necessary DAQ-functionality.

2. Select names of methods, properties and events corresponding with name of old driver’s members. This creates an opportunity to simplify the process of remaking existing Delphi applications.

3. Register the assembly for Com Interop.

4. Import the .NET-assembly in Borland Delphi. Now we have an object the same as, for example, ActiveX object with an encapsulated necessary DAQ-functionality.



Advantages of described approach are:
Working with all DAQ-cards in all operation systems including 64-bit ones.
Independence from NiDAQmx versions.
You need only free Microsoft Visual C# 2008 Express Edition (for example), you don’t need any expensive software.
An opportunity to use Delphi as basic software for DAQ application development.



Using described method I have already created .NET assembly with realization several functions for one-shot digital reading and writing, continuous analog reading, one-shot analog writing (I need only this functionality for my own applications).


If this topic is interesting for you please write me karpesh@mail.ru or soft@electrolab.ru (English and Russian available).

[Aloika]

The absence of official support of interaction between NiDAQmx driver and RAD Borland (Embarcadero) Delphi is the actual problem. Many application developers want to support existing projects and develop new ones using the familiar programming environment. However, we suppose that new-created Delphi projects must support various DAQ cards and operation systems of the Windows family including 64-bit versions. Existing Delphi applications written with the legacy Traditional NiDAQ driver must be easy converted to work with a new NiDAQmx driver.



There are two methods to solve this problem partially.



1. Using TDAQ7.4 for Windows Vista. This method allows to use existing Delphi applications for Windows Vista x86 and Windows 7 x86. But this driver doesn’t support a lot of modern DAQ cards and doesn’t work in 64-bit operations systems. Using TDAQ7.4 driver for Windows Vista can be only a temporary solution.



2. Using wrappers for the nidaqmx.dll library. The limitations of this method are dependence between NiDAQmx version and wrapper version (changing of driver’s version involves changing wrapper); nidaqmx.dll functions are not well documented; there are strange bugs and memory leaks; 64-bit operation systems are not supported yet; working of this method is not guaranteed at all.



I want to propose a new solution of interaction of the NiDAQmx driver and Borland Delphi. The essence of the approach is described below.



1. Create .NET-assembly using Microsoft Visual C# 2008 Express Edition (for example), in which describe one or several objects contained necessary DAQ-functionality.

2. Select names of methods, properties and events corresponding with name of old driver’s members. This creates an opportunity to simplify the process of remaking existing Delphi applications.

3. Register the assembly for Com Interop.

4. Import the .NET-assembly in Borland Delphi. Now we have an object the same as, for example, ActiveX object with an encapsulated necessary DAQ-functionality.



Advantages of described approach are:
Working with all DAQ-cards in all operation systems including 64-bit ones.
Independence from NiDAQmx versions.
You need only free Microsoft Visual C# 2008 Express Edition (for example), you don’t need any expensive software.
An opportunity to use Delphi as basic software for DAQ application development.



Using described method I have already created .NET assembly with realization several functions for one-shot digital reading and writing, continuous analog reading, one-shot analog writing (I need only this functionality for my own applications).


If this topic is interesting for you please write me karpesh@mail.ru or soft@electrolab.ru (English and Russian available).

[Dennis_Knutson]

duplicate and duplicate and duplicate

One posting is enough. It's started to seem like spam. If this is advertising to sell a product, you are in violation of the Terms of Use.

Message Edited by Dennis Knutson on 01-28-2010 10:36 PM