Hi All.I don't seem to be able to get any ethernet to come out of my simulation.I am using the latest Qlarity, fresh install on a Windows 7 PC.I have 'Default Simulation selected in the Settings/Simulation tab.

I am sending UDP packets to an address using EthernetClient.SendData("blahblah")

I don't see any packets using wireshark at all, and netstat doesnt report the connection.

Does this work in W7, or am I being stupid?Thanks,Jim

Edit:-So I seem to have found an error in my code. Perhaps someone could explain why this happens:I moved the initialisation lines below, to the top of the code object EthernetClient from where it was originally at the bottom.init targetipaddress := "192.168.0.204"init localport := 0init protocol := net_udp

This stops the code from working, although no errors are produced either on compile or run. Why do these lines need to be at the bottom of the code?

Also, the ethernetclient example is giving bad UDP messages when looked at with wireshark. It reports:Header Checksum: 0x0000 [incorrect, should be 0xb0fd (may be caused by "IP checksum offload"?)]All very confusing.

As to the Wireshark/UDP Checksum errors. This has nothing to do with Qlarity, but rather the network drivers and hardware on your PC. Your PC is not calculating TCP or UDP checksums, but rather leaving that to the network hardware. Wireshark looks at the packets before this point and sees incorrect checksums and flags the error. You will see this error with all UDP traffic from your PC (on that NIC). Probably with all TCP traffic as well. There are settings in Wireshark that can disable that error message.

The line order that the init statements appear should not be important. They can appear at the top or bottom of the object and the behavior will not be affected. It is possible that something else is going on. If you want to dig deeper into that, try putting the statements back at the bottom and see if things break. If they do, you might want to send a copy of your project (File->Collect For Output) to support@beijerinc.com and see if we can duplicate the problem here.

Hi Jeremy and thanks very much for the reply.I am writing an app that simply sends UDP messages to a given IP/port, and I think Ive done everything coreectly. I used the UDPClient example app as a basis for all the ethernet code, and sure enough, a port is opened and the data sent.

What I don't understand, is that the device that is supposed to be receiving the UDP message data does not recognise the UDP message, but it does receive it. I understand your point about the CRC checking, and have now discounted that as the problem.

I have captured a similar message from the receiving device, and I see that in the message from the panel, most of the start of the message header is all 00s, whereas most of it in the receiving devices version of the same thing is all FFs. Also, the message length is different, even though the encapsulated data at the end of the UDP message appears to be correctly encoded.

Any ideas? I thought that a UDP message was a UDP message and that there werent any variations in the format. Certainly I have had other people send the same data to the same receiving device over UDP before with now problems - I just gave them the IP and the port.

Any help from anyone would be much appreciated - perhaps I need to run a UDP server on another machine and see what it receives next.

Are we still talking about simulation here or did actual Qlarity hardware enter the discussion at some point here?

UDP communication in Qlarity Foundry simply acts as a wrapper around the standard Winsock sendto and receivefrom functions.

Is there any chance you can post some of the Wireshark dump data so that we can discuss from a common point of reference?

Normally if comparing a UDP packet with identical contents from two different sources, I would expect the following differences in the UDP header:

Source Port will probably differ (although it might not). The checksum (if available to capture at all) may differ. Also, if the datagram is very short there may be some extra, usually random, garbage bytes at the end as an Ethernet frame has a minimum size and your datagram will need to be padded to fill a complete minimum sized Ethernet frame.

There will probably be some differences in the IP header as well, but I am a little less familiar with that, so I have a harder time talking there.

Hi Jeremy.Yes sorry, I got hold of an actual panel to test my application with, so no longer in simulation mode.That's what I thought about UDP - just the wrapper.So I know have UDP messages going to one of my remote devices working properly, but the other one still refuses to work.At this point I no longer think the problem is with the Qlarity/Panel side, so problem solved.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum