02-20-2012 10:27 PM
I have a test fixture PC with the following configuration:
Here is a screen shot of the Windows Device Manager and MAX:
I cannot install the NI-Industrial Communication for DeviceNet 2.0.2 on this computer because I am getting the following error:
Well, I have two questions
Solved! Go to Solution.
02-21-2012 11:29 AM
I see your pain about using these two different DNET approaches. The fastest way to get it to work is to create an installer build in your 2011 Pro LV environment. There you can add both the NI Indcom Dnet and the NI-Dnet driver as additional installers. The package then installs all necessary drivers to your target system.
02-21-2012 03:33 PM
Thanks. I am trying to configure the installer build, but I don't see the 'NI-Industrial Communications for DeviceNet 2.0.2' in the 'Additional Installers' list.
Do I need to install the 'NI-Industrial Communications for DeviceNet 2.0.2' on my development computer?
How this will actually work at all? The DeviceNet 2.0.2 software, if installed on the target computer will provide the driver for PCI-8532 and this will make it visible for the NI-DNET 1.6.6 also?
Are there any code changes required? My program was working until now fine with all NI-DNET 1.6.x drivers, at least 1.6.3 and higher.
Thanks for your help,
02-22-2012 08:48 AM - edited 02-22-2012 08:53 AM
Well, YES you need to install all drivers to your Host that you would like to include into your Installer Build.
And No there is still a difference between your DNET 1.6.x driver and the new NI IndCOM for Devicenet 2.0.x driver. You will need the 1.6.x driver to support your old DNET boards and you need the 2.0.x driver to run the code for your 8532 board. There is unfortunately no compatibility between them yet and the variable approach for the 8532 board is much different to the APi approach for the 8532 board. You have hopefully seen the difference by now?
The good news is we are working to release an API for the 8532 boards pretty soon that would be compatible with your 1.6.x code. That means you could modify your existing code pretty easily to run on 8532 boards as well. However the new API will only allow 8532 boards for now.
For now both drivers work on the same machine so you can install 1.6.x and 2.0.x side by side and use both drivers in one code base.
But you should prepare yourself for the future to have systems with either old boards or new boards but not both. Would that be possible?
02-22-2012 01:08 PM
We were told that the new PCI-8532 (part# 781062-01) is a drop-in replacement for the NI PCI-DNET (part# 777358-01). We are not trying to use both types of cards in the same computer.
I understand that 'NI-Industrial Communications for DeviceNet' is part of LabVIEW's development environment, e.g. similar to the Modbus functionality for DSC and LabVIEW Real Time. This is probably the reason it cannot be installed on a system without LabVIEW development environment. But this is not that important now.
What I am trying to accomplish is actually to use our program, based on the 1.6.x API, in a new test fixture with only one PCI-8532 card. Reading your latest reply I am afraid that this is not possible and I have two options:
Is my assumption above correct?
Do you have information when the 8532 API will be released? If the release is expected to be very soon, it probably doesn't make sense to work on a new code right now. Or maybe NI has a beta version for test purposes?
02-23-2012 08:49 AM
No, it is defenitely not a replacement yet and I will work with our Web Department to make that more clear on our web page.
The development for the new API is pretty much done but based on your feedback we are thinking of improving the compatibility so you could for example use the old 1.6.x APi and the new 8532 APi on the same machine, so you could use old and new hardware on that same machine. Would that be important for you?
For now we are planning to allow only one hardware type at the same machine to save some development time. Let me know what you think.
To clarify the today situation: The InCOM for Devicenet component is not a part of LabVIEW. It is just a very simple way of communication with IO variables and function blocks for EM. The driver should install just fine even without LV installed. The error message is pretty much a Bug on our side and the workaround would be to use the LV Installer builder to create a new Installer that can install the Incom Dnet 2.0.x driver without having Lv installed.
And today you should be able to have both the 1.6.x and the 2.0.x driver installed in parallel and use the 1.6.x API with ypour old boards and the 2.0.x IO variable approach with your new board.
I keep this post updated as soon as we have a stable Beta available I will post something.
02-23-2012 05:18 PM
I guess now everything is clear. To answer your question::
For now we don't need to use a mix of the old and new DeviceNet cards on the same system, but this will happen definitely in the feature
I have also a comment about the InCOM communication with I/O variables. Many times we have different set of devices on the DeviceNet network or we need to change the current input/output instance of a device during program execution. This causes also that the the actual input/output byte size of the 'polled' connection instances changes during program execution. We can take care of this by using explicit messages in order to determine the actual input/output instances and byte sizes and adapt the process data size on the fly. I am not sure if this will be very easy with I/O variables. I didn't install the InCOM driver yet, and probably this is not a problem at all, but I like to just to point it out.
Thanks for your help,
03-16-2012 01:34 PM
Our official NI-IndCom for Devicenet 2.1 Beta is now available from here: ftp://ftp.ni.com/support/ind_comm/devicenet/2.1/
We added a NI-Dnet 1.x.x compatible API for Master/Scanner Support.
here are some known issues and things to keep in mind.
1. Support for LabVIEW 2009 or later only/ no C support.
2. Can not be installed with older NI-DNET 1.x drivers in parallel. That means you can only have 8532 boards in one system not both older Dnet cards and new 8532 boards !!
3. It will upgrade existing 2.x installations automatically.
4. Existing NI-DNET 1.x VIs should be loaded and function just fine without replacing anything manually.
5. Existing NI IndCom for Devicenet 2.x VIs should be loaded and function just fine without replacing anything manually.
6. There is currently no slave/device support available for the 8532 hardware, but we will add support in the near future.
7. As soon as we release the driver we will offer a C-Series cRIO module as well.
Please post your feedback to the official thread that announces the Beta in the same IndCom forum.