Posts by dnaumann



    I have PCDK implemented in a lot of different products so I double confirmed this information with Fanuc support and the support agent said "I was able to get confirmation from my R&D department that PCDK will not be obsolete anytime soon." This is still hearsay but more recent hearsay lol

    If you have the socket option, it may be easier to setup sending the information across to a independent service then emailing it from there. Say like a python service accepting information from the robot in unidirectional communication line and then interfacing with the internet.

    Roboguide utilizes little endian for their bytes but real production robots from the same company utilizes big endian. A) I'll have to change my socket code from test to production to account for the change of endianness and B) since I'm truncating bytes to send UInt16 from Uint32s on the robot side, it is truncating the wrong side in simulation but not production. Hopefully there is just an option to set on Roboguide to change how it handles the byte swapping because there is little I can do without having a major refactor before every robot deployment.

    Have the FTP and Socket option and was wondering if you can support remote robots through either of those fully? Like for Karel support can you pre-compile it and send it to the robot in an off-state then will the robot use that updated version? Or as far as purchasing options or other ideas of getting remote programming changes going, let me know and throw your thoughts in the ring.

    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?

    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.

    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:

    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.

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

    Code
    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 :smiling_face:


    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.

Advertising from our partners