Kuka communication failure with Cognex In-Sight smart camera over Profinet

where are the robot network settings?

where are the settings at the robot (login as Expert, on smartPad menu Start-up>Network; virtual5 MUST be configured by hand for Profinet, then add new interface virtual6 and set it as Windows Interface)

how..?

which version is that? can you be more specific?

thanks

Bumping for new information.

I've been attempting to connect a Cognex In-sight 5400-series camera to my KRC4 OfficePC (KSS 8.3.28) via Profinet, and ran into the same issues. I originally had Profinet V3.1.5 installed, and was unable to make any connection. Upgrading to 3.2.4 appears to have gotten me a successful connection.

Notes:
1. Virtual5 is set up as the KLI interface, and Virtual6 is set up as the Windows interface. This required different subnets, and netmasks selected to prevent any collision/crossover between the two interfaces.
2. The Cognex appears to be very fussy about netmasks -- unless the netmask matches completely between the camera and the robot's KLI interface, it's not possible to connect.
3. The WorkVisual side was quite simple -- simply add the appropriate GSD file to the Profinet tree. The GSD files for all In-Sight devices come with the install of the In-Sight Explorer software, usually in c:\Program Files (x86)\Cognex\In-Sight\In-Sight Explorer 5.2.2\Factory Protocol Description\GSD\. Rather than one GSD per model, there seems to be one GSD that covers all the In-Sight series cameras, which certainly makes things simpler.
4. It is necessary to set up the Cognex for Profinet under Network Settings, using the In-Sight Explorer software. The IP, netmask, and ProfiNet station name must be set, and match the same settings in WorkVisual for that device. The Acquire cell (usually Cell A1) in the Cognex spreadsheet must also be set to network-controlled acquisition.
5. The Cognex exposes 537 inputs to the robot's outputs, and 538 outputs to the robot's inputs (I wonder why the assymetry?). There is a mix of Bits, Bytes, and UINTs. I had to map each group of each type separately.
6. The first couple bytes of the Inputs and Outputs are pre-defined control signals for the handshake control of acquiring images -- Enable, Trigger, Complete, Online/Offline, etc. Bytes further up appear to have large ranges of user-defined values for moving data between the robot and Cognex applications.

So, at the moment, I have basic driver-level communications working, and I've been able to send over the Trigger Enable bit and get back. Getting actual image-acquisition working is next, followed by getting actual data from the processed images back to the robot.

according to ProfiNet manuals Both 3.1 and 3.2 require KSS8.3.6+
but if i am not mistaken, PN 3.2 must be used on KSS8.3.14+ or so (PN3.1 will not work)

So, I've made more success on this front. My last remaining issue is quite an odd one.

Basically, I've successfully used the Cognex Output Buffer to send whatever data I want to the robot. Since Cognex uses Siemens byte ordering, I have to use the Byte Swapping option in WorkVisual for any multi-byte mappings, but it works fine. I can use UINT, INT, and even Float (if I use my IEEE-754 converter in the robot).

The Cognex Input Buffer also works. However... the Byte Swapping in WorkVisual doesn't. Literally, it has no effect. After my success with the robot inputs, I followed the same process for the robot outputs. Set up a 16-bit or 32-bit word in the Cognex, mapped it to an Output block in WorkVisual, and ran my test program.
My test program has a SIGNAL declaration for the 16- or 32-bit word, and I simply increment its value while watching what the Cognex receives. And what I get (for a 32-bit allocation) is this:
Robot output 1 -> Cognex receives 16777216
2 -> 33554432
4-> 67108864

Basically, the lowest bit of the lowest byte on the robot outputs is being mapped to the lowest bit of the highest byte in the Cognex inputs. If I increment the robot's output value by powers of 2, I can watch the active bit march upwards, one bit at a time, through the highest byte in the Cognex, then jump to the lowest bit of the 2nd-highest byte, then from the highest bit of that byte to the lowest bit of the 3rd-highest byte, and so on. Until, when the robot sends 16777216, the Cognex receives a 1.

Obviously, I need to swap my bytes, yes? But here's the kicker: swapping the bytes in WV does nothing. Literally -- If I go into WV, swap the bytes, deploy the project, then re-run my test program, literally nothing changes in what the Cognex receives.
I also tried changing the mapping in WorkVisual between I/O, Signed, and Unsigned. No change. Un-swapped the bytes. No change. Swapped the bytes again (did this about 6 times). No change.

Now, keep in mind that, on the robot inputs, I can clearly see the WV byte-swap work. If I un-swap the bytes in WV, what the robot receives from the Cognex looks just like what I outlined above. If I swap the bytes, the robot receives exactly what the Cognex sends. But the WV byte-swapping on the outputs[/] not only does not work, but makes [b]no difference at all. I've also tried firing the $OUTs in the robot one at a time directly, rather than assigning integers values to the SIGNAL variable -- no difference.

I can't really believe that this is a Cognex-side issue. Even if it was, swapping and un-swapping the bytes in WorkVisual should make some visible difference in what the Cognex receives. Instead, it's almost as if the WV byte-swapping simply isn't doing anything for the outputs, only for the inputs.

I'm using WV 4.0.19, and my OfficePC is running KSS 8.3.28. I haven't had this kind of problem with WorkVisual before, connecting to Siemens PLCs (which also require byte-swapping). Has anyone ever run into anything similar? I've got feelers out to both Cognex and KUKA tech support, but so far nothing's come back.