Truncating Messages and It Returning Zero Over the Socket

Say I have an uint32 and I truncate it down to uint16 like:

sampleUINT=64
-- UINT32 to UINT16
WRITE my_port((sampleUINT)::2)

When I read it in over the socket, I end up getting 0 for everything I've truncated vs all correct data for those I have not. Is this an error in the way I'm reading this values in or is this an error in the way I am truncating it? Further question is what changes about the data when truncated vs not truncated to cause it to be read untruncated then not read when truncated?

Thanks hopefully this leads to some good discussion

Edit: It is sending the full byte length as if it were transferring over, just comes across the line as all zeros. Even if it is a variable set before the sending of information that doesn't change.

Also will it being a virtual robot have any effect to this end?

Quote from jmd2777

Is this code written in Karel?

How did you declare the variable sampleUINT? Maybe you could post more of the code.

How is my_port declared?

Oh yes, it is in Karel. I'd say the code itself isn't in question, as it is sending other variables correctly. Just not the one's that were modified using the truncate symbol (::). The my_port is just a simple socket connection that sends data over. I would imagine that it shouldn't change too much after being truncated as it would still be sending bytes across.

Quote from jmd2777

It would still be helpful to see the code. For example, do you open my_port using the

ATR_UF attribute?

The way :: operates depends on if you are using the port in ASCII or binary mode.

Let me mock up that code:

PROGRAM RobotForumTest
VAR
    test_port : FILE
    MessageID : INTEGER
BEGIN
    SET_FILE_ATR(test_port, ATR_UF)
    OPEN FILE test_port('rw', 'C3:')
    MessageID = 21
    -- test port to write to
    WRITE test_port((MessageID)::2)
    COLSE FILE test_port
END RobotForumTest

Quote from Nation

Is it a big endian vs little endian issue? You may be cutting of the section of the int with all the data in it.

I don't believe it is, because all of the data is coming across the way I would expect it at both the beginning and the end of the "packet" sent. It is just spots where that :: operator is used that isn't coming across. Good thought about big endian/little endian.

Quote from jmd2777

Thanks.

Could it still be an endian thing?

The manual is a little confusing. It says that the First Format Specifier indicates the number of least significant bytes of the INTEGER to read or write, with the most significant of these read or written first.

So does that mean by using ::2 you are writing the 2 least significant bytes?

Very good point! I'm going to try this on the actual robot and see if it has to do anything with that actually. Because before I remember my bytes being in big-endian format but when running it on the virtual robot it is in little endian which is really weird. But that could account for the wrong end of the information taken. Why would the virtual robot use little endian while the robot pendant itself use big endian?