Labview interface with multiple module Festo block

[TennesseePaul]

I am attempting to communicate with a Festo block but I am unable to. Here are the details:

I am running Labview 2012 SP1 with IndComm-DeviceNet 2.2 driver on a Windows 64bit OS. I have installed a NI 8532 PCI card. I see the card in MAX.

The Festo block is constructed with the following Modules: CPX_FB11 (communications module), 4 Analog Input Modules, 1 Digital In Module, 2 Digital Out Modules followed by 32 Festo Valves. (Image Below)

Utilizing DeviceNet PXIPCI Basics.lvproj I have done the following:

In the project, right clicked on My Computer>New>Targets and Devices>Existing Target or Device, Discover an existing Target or Device...

Expaned the DeviceNet Master Interface node, Selected DeviceNet1 and added it to the project.

Right Clicked on the newly added DeviceNet Target/Device>New>Targets and Devices...

Expanded the DeviceNet Slave Device selected the Festo Block "CPX_FB11" and added it to the project.

Initially I received a DataSheet Error "EDS File Unassigned" I resolved this by following the direction listed here.

However, I am unable to "see" anything in LabView other than the CPX_FB11. The Device tree does not list the Analog, Digital IO's or Valves. I cannot operate the Valves or Analog and Digital IOs. When I run any of the project VI's they time out.

Any help would be appreciated.

Thank you,

Tennessee Paul

[Jesse_D]

Hi Paul, 

It sounds like you are using the legacy API and also that you are having trouble discovering the device correctly. The EDS file should have the features necessary for inputs and outputs, so I would double check the EDS file you inported is correct for the device. 

The new API actually doesn't have EDS support yet. I recommend using the new API also. 

The Festo user manual should have more information on the expected inputs and outputs. Do you have that manual? 

I recommend using the manual and the new api (do a search for devicenet in the example finder to find them) to communicate with the device. If you post the user manual I can help you figure out how to set it up. 

[TennesseePaul]

Hi Jesse,

Thank you for the reply. I discovered how to make this work late on Friday. Made for a nice weekend. : )

Thank you,

Tennessee Paul

[Jesse_D]

Hi Paul, 

Glad to hear it. 

For other people that might have the same problem reading this thread, what was the issue? 

[TennesseePaul · Accepted solution]

Hi Jesse,

I'm not entirely certain what the specific problem was. I kept getting strange behavior. Errors in LabView and on my Festo Device. EDS files would change. So, I did as any natural born IT worker would do, I rebooted.

Below are the steps I utilized to get this project going. In so doing I found that to configure a DeviceNet device in LV2012SP1, I do not need to manually type in the EDS file data. There is a tool for loading EDS files. This addressed questions I had in previous Forum posts: here concering loading EDS files in LabView and here concerning configuration of a DeviceNet network.

Environement: Windows 7, 64bit processor. IndComm 2.2 Driver. Labview 2012 SP1

Beginning with LabView Example Project: "Devicenet PXIPCI Basic.lvproj"

Add a DeviceNet Master to a LabView Project

1. Within the Project: Right click on My Computer
1. Select New
2. Select Target(s) and Device(s)
2. Select "Discover Existing Devices" option
3. Select the discovered device.
4. Click "OK" (Note: In this case my Master is a NI-8532 PCI card)

Add a DeviceNet Slave Device to a LabView Project

1. Right click on the newly added Master Device in the Project Tree
1. Select New
2. Select Target(s) and Device(s)
2. Select "Discover Existing Devices"
3. Select the discovered device.
4. Click OK. (Note: In this case my Slave is a Festo CPX-FB11 block.)

Load an EDS file for the slave device

1. Right Click on the Slave Device
2. Select "datasheet..."
3. Click Add Files...
4. Navigate to the location of the EDS file.
5. Select the file.
6. Click OK.
7. In the left pane, expand the newly added Datasheet until you reach the node displaying the version.
8. Select the version.
9. Click OK.

Verify the EDS file and Device

1. Right Click on the Slave Device
1. Select Utilities
2. Select Online Test Panel
2. Select the "Device State" option in Category field on the left.
3. On the right Select the Slave Device you wish to verify.
4. Click "Verify the Device"
5. Read the errors/warnings or lack thereof.

In my case I had errors in my EDS file. Basically the slave device was not set to the correct number of Input/Output Bytes in the EDS file, i.e. improper configuration. To correct these I had to edit the EDS file.

Edit EDS File

To Edit the EDS file I utilized EZ-EDS which is a freeware, devicenet specific EDS editor from ODVA.

I made my corrections and saved my EDS file. (After backing up my original, of course).

Remove Installed EDS file from Labview

1. Navigated to the following Location: C:\ProgramData\National Instruments\NI-IndComm for DeviceNet\Datasheet
2. Delete the Datasheet (Note: There are more than just the one manually added datasheet. The additional EDS files come with the IndComm driver. Find the EDS File for the specific device you wish to replace and delete it).

I restarted LabView.

I went through the above steps again and loaded my new EDS file.

I saved the project and exited LabView.

I rebooted the computer and the slave device.

I restarted the project and launched a VI.

I was able to communicate with the device. Which is something I had not been able to previously accomplish. And, in so doing I discovered how the device is talking and why each module did not display. (I have a standard EDS file for my block of devices as it appears LabView is not capable of a Modular system which requires an EDS file for each module. I could be incorrect on that last part though as it might be a setting on my actual device. But it is unecssary in my project. So I did not look into it further.) Because I was using a standard EDS file, only the one single slave device showed, and thus the data for each module is in the stream of bytes returned over the DeviceNet network. Addressing each module is a matter of parsing the bits and bytes appropriately.

Thank you,

Tennessee Paul