LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UTC time to OLE date...

You're still mixing datatypes! One of your 0 constants is an I8. Another is I32. Right-click on each constant and make sure everything that's going to the main Build Array is a U8. Other comments:
  • It is pointless to convert a constant that is U8 to a U8.
  • Use an array constant instead of building an array for the TypeCast function. The number of elements is irrelevant. It can be empty. All that matters is the datatype.
  • Use the Spreadsheet String to Array for your IP string massaging. It does the same thing as the loop.
  • Once you get your datatypes fixed there should be no coercion dots. You will need to change the datatype of your "appended array" to be U8, though.
See attached VI with comments in purple.
Message 11 of 20
(2,803 Views)
Thanks a lot for you comments. After I have implemented them the coercion points went away.Smiley Happy
0 Kudos
Message 12 of 20
(2,798 Views)
I have a question about the UDP receiver. After I've  sent my  UPD packet I should expect a UDP packet in response. How should I wait for it? The wait time can be like 30 seconds or even couple of minues. Should I run UDP read in While loop constantly or something? Please help.

0 Kudos
Message 13 of 20
(2,752 Views)
You're asking a totally different question, so in the future it would probably be best to start a new thread. Without knowing anything else about your process, I would say to have the UDP read in a separate loop. This way it can simply monitor the UDP port and read the data once it gets, if ever. You have no indicated what you're supposed to do with this data. Is it supposed to trigger something else?
Message 14 of 20
(2,743 Views)
Sorry. I thought that  since it is UDP related then I should ask this question in this thread since UDP was  mentioned in this thread before.   When I catch a UDP packet I need to process it by splitting it in bytes and decoding the information  I need. Pretty much the packet contains a command status that  I 've sent  using the transmitter that  was discussed at the beggining of this thread.

Below is the packet description that I got from the software guy who maintains the tool from which I need to catch the UDP packet.

 



0 Kudos
Message 15 of 20
(2,738 Views)

One complication you will have to deal with if you want to listen to the packets coming out of the transmitter: The transmitter packs multiple data packets into one UDP packet. The UDP packet format is as follows:
 

UDP_Packet_Counter                            [Int32, starts at zero and increases monotonically, 4 bytes]

Data_Packet_1

Data_Packet_2

Data_Packet_3

..

Data_Packet_N

 

Each Data_Packet has the following format:

 

AT0, AT1, AT2, AT3, AT4, AT5, AT6, AT7,           Acquisition time [8 bytes]

0,0,0,0,                                                             Packet_Type_ID [0->packet_wrapper, 4 bytes]

PL1, PL2,                                                          Packet_Length = PL2 * 256 + PL1

Packet_Wrapper_Body                                       Packet wrapper body, total of Packet_Length bytes

 

The Packet_Wrapper_Body has the following format:

 

TS1, TS2, TS3, TS4,                                          Toolstring number for the toolstring that will receive the packet. For your case TS1 through TS4 are all zeros.

PT1, PT2, PT3, PT4,                                          Packet_Type_ID. The packet you are looking for has values 237, 255, 255, 255.

NPL1, NPL2, NPL3, NPL4,                                 Net_Packet_Length = NPL4 * 16777216 + NPL3 * 65536 + NPL2 * 256 + NPL1.

Packet_Body                                                     Packet body, total of Net_Packet_Length bytes.

 


0 Kudos
Message 16 of 20
(2,736 Views)

The Packet_Body format is different for each packet type. For packet type -19 (=acquisition started successfully), it is as follows:

 

4,0,0,0,d,c,b,a,                                                  Encoded IP address of sender (in this case, the transmitter)

DEFA,0,0,0,                                                      Decimation factor.

 

So to detect the “acquisition started successfully” packet, you will have to do the following:

 

Foreach UDP packet

   Ignore first 4 bytes

   Foreach Data packet (loop until no more bytes are available)

      Ignore first 12 bytes

      Calculate Packet_Length from the next 2 bytes so you know where the next packet starts.

      Ignore next 4 bytes

      Verify that next 4 bytes are 237, 255, 255 and 255.

      Ignore next 9 bytes

      Verify that DEFA equals the DEFA you used when you started acquisition

      Skip “Packet_Length – 18” bytes to advance to next packet

 

0 Kudos
Message 17 of 20
(2,735 Views)
Well, the question on the thread was actually about converting UTC time to OLE datetime, but it doesn't matter.

To your question... You basically have 2 different issues: (a) knowing how many bytes to read; and (b) decoding the packet information.

For (b): The UDP Read returns a string. You can use the String to Byte Array function to get an array of bytes. You can then index out the appropriate byte to get the information you want based on the definition you've been given.

For (a): Since the packet length varies you first need to know how big the packet is. This means you have to read enough bytes to be able to get to the PL1 and PL2 bytes, which tell you the size of the packet. An example of this is actually shown with the TCP examples. If you open the Example Finder and search for "TCP/IP" you should look at the "Simple Data Client" and "Simple Data Server" VI. The "Simple Data Server" send out an array of numbers, and prepends the number of bytes (which is an I32). The "Simple Data Client" consequently reads 4 bytes initially (the size of an I32) and converts that string to an I32 so it knows how many bytes it needs to read. You need to do something similar by first calling UDP Read with a fixed value of 14 for the "max size" input. This corresponds to the first 14 bytes of the packet. The first 8 bytes is the acquisition time. The next 4 bytes is the packet type ID, and the next 2 bytes are the packet size (PL2 and PL1). The formula given then tells you how many bytes the packet is, so you can call UDP Read again, with the calculated value.
Message 18 of 20
(2,729 Views)
Hi,
I have prototyped a basic UDP receiver based on the example that comes  from NI.
I always get an error:"Error 56 occurred at UDP Read in UDP_RX..vi"
Could some one tell what I did wrong?
I asked the transmitter people to broadcast packets to port 1600. So I know that there are packets to receive.
Thanks.
Ruslan.

0 Kudos
Message 19 of 20
(2,699 Views)
That simply won't work because you have no synchronization between the sender and the receiver. You're assuming that the sender sends the data in the time it takes your code to go from the UDP Open to the UDP Read. That's simply not going to happen. The reason why the UDP Receiver example is written the way it is is because you don't know when the data will arrive (or even if it will arrive), and you don't know how many bytes you will actually get. Thus, you have to use a loop like the UDP Receiver example does.
0 Kudos
Message 20 of 20
(2,693 Views)