Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Mon Nov 20, 2017 12:51 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Sun Feb 23, 2014 5:59 am 
Offline

Joined: Fri Jul 13, 2012 10:16 am
Posts: 6
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.

Socket reports opened OK using EthernetClient.OpenConnection()

init foreignport := 4703
init targetipaddress := "192.168.0.250"
init localport := 0
init protocol := net_udp

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 := 0
init 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. :(

Cheers,
Jim


Top
 Profile  
 
PostPosted: Mon Feb 24, 2014 7:47 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
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.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Mon Feb 24, 2014 12:00 pm 
Offline

Joined: Fri Jul 13, 2012 10:16 am
Posts: 6
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.

Cheers,
Jim


Top
 Profile  
 
PostPosted: Mon Feb 24, 2014 12:48 pm 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Congo,

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.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Tue Feb 25, 2014 3:29 am 
Offline

Joined: Fri Jul 13, 2012 10:16 am
Posts: 6
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.

Many thanks for your input - I am sure you will hear from me again :)

Best regards,
Jim


Top
 Profile  
 
PostPosted: Tue Feb 25, 2014 7:37 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Good luck with your project. Let us know if you run into any more problems

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


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

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group