can not broadcast to 255.255.255.255

[lavalava]

Guys,

I'm having a hard time sending and receiving broadcast packets at 255.255.255.255 using the provided example.  Could someone please help me out to see what am I missing?  I have no problem doing this sort of things in java but labview is tricky.  Thanks

Message Edited by lavalava on 08-24-2009 08:47 PM

[altenbach]

255.255.255.255 is is a broadcast address NOT a multicast address. Why would you want to send a multicast to a broadcast address? That makes no sense.

Try a multicast address in the valid range of 224.0.0.0-239.255.255.255.

[altenbach]

Try the plain UDP open/UDP write  (not multicast!) With an address of 255.255.255.255. Seems to work just fine.

(open the UDP sender.vi example, it even has a button to optionally send to the broadcast address xFFFFFFFF)

Message Edited by altenbach on 08-24-2009 11:02 PM

[lavalava]

Thanks, that works.  Another quick question, it seems that these UDP blocks are automatically converting all incoming data from bytes to ASCII.  Is there a way to write bytes only to a UDP block and receive bytes only instead of ASCII?  And is 548 is really the maximum byte array size can be read/write?  Is there a way to make it go higher than that?

[RavensFan]

ASCII are bytes.  Any byte from 0-255 is represented by an ASCII character.  So when the TCP/IP functions return a string and you look at it in normal display, it will be in ASCII characters.  You can also look at it in hex display.  You can also use string to byte array or typecasting to convert from string characters to the corresponding value of the byte in integer format.

[altenbach]

---

lavalava wrote:
Another quick question, it seems that these UDP blocks are automatically converting all incoming data from bytes to ASCII.

---

No, they are simply represented as strings (i.e. a series of bytes). You can typecast them to whatever you want.

(ASCII is a way of encoding bytes into characters and is irrelevant here. Strings != ASCII.)

---

lavalava wrote:
And is 548 is really the maximum byte array size can be read/write?  Is there a way to make it go higher than that?

---

I don't know where you got that number. Read the help for UDP write:

"In an Ethernet environment, restrict data to 8192 bytes. In a LocalTalk environment, restrict data to 1458 bytes to maintain gateway performance."

548 is the default size for reading, but you can set it to anything you want (within reasonable limits, but read the warnings in the online help!).

For broadcast use, I would probably recomment to keep it below the MTU value so it fits into a single UDP packet and does not need to be fragmented by the underlying driver. What size data do you have in mind?

[lavalava]

On the receiving end, if I right click on the string indicator and select "hex display" it shows bytes.  Which is good but I want to feed these string out from the UDP reader as "hex" only so I can run it into a parser.  How do I do that because it defaults everything to ASCII?  The type caster document you guys suggested was pretty hard to understand.  They didn't really tell you how to operate it and what are the list of eligible types you can feed into it.

Message Edited by lavalava on 08-26-2009 01:05 PM

[altenbach]

You still seem to have problems understanding strings. They have nothing to do with ASCII.

Can you tell us what kind of "parsing" you need to do? I am sure there is the equivalent of a "one liner" that does it all. 🙂

Please attach a small VI containing a typical string as diagram constant and tell us what output you need. 🙂

[lavalava]

I think we will be on the same page if you can run both receiver and transmitter.  Sorry if this takes some of your time away but it's probably easier to see it.

Ok, here is my intention.  Say I'm sending  0xAABBCCFF.  On the receiving, the UDP reader automatically converts 0xAABBCCFFto ASCII.  If I right click on the output indicator "Data Received" and pick "Hex display", it shows 0xAABBCCFF which is good but the problem is my parser is expecting 0xAABBCCFF.  I can't feed the output straight into my parser as 0xAABBCCFF because UDP reader already defaulted itself to output as ASCII as "ª»Ìÿ".  So obviously, I have do some data manipulation so I will see 0xAABBCCFF or simply "AABBCCFF" as string format.  How do I do that?

Message Edited by lavalava on 08-26-2009 01:25 PM

[RavensFan]

A byte is a byte.  A byte in a string can show up as an ASCII character (normal mode), a hex value that goes from 00-FF (hex mode, it takes to spaces on the screen, but each pair of hex values is still only one byte).  It can show up as a numerical value in an integer numeric indicator as 0-255 in decimal display or 00-FF in hex display (binary and octal are also available).

If you want a byte such decimal65, hex 41, or ascii character A to show up in a string that is the two string characters of a "4" and a "1", then you have to do some manipulation.

As for typecast, it takes any kind of input and converts it to something else.  Maybe what you want, maybe not.  The only way to know all that it can do is to experiment with it.