Posts by dnaumann

In a Karel program when CURPOS(0,0) is it by default in the world frame w/o setting any Karel frames?

Quote from Alfred

ahah still alive

After discussion with Fanuc, PCDK is an old protocol whose sustainability in time is no longer guaranteed.

Fanuc advised me to look into "Robot Interface" instead. So I'm implementing it in .NET. There are almost the same features as in PCDK : access to I/O, remote control of the robot, access to the registry, robot status...

For your information, I just published this kind of library for Universal Robots (https://underautomation.com).

Next month, I will release the same one for Yaskawa. And then, I will industrialize the library for Fanuc. So no release before the end of this year.

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.

Was wondering if there was anyway to log information out from the robot after it hits a DCS fault? Either it be to make a large file of all the DCS faults on the robot or be able to run tp/karel file after fault and log it externally.

Note: depending on the robot version, you might have to change server type in Filezilla to DOS with forward-slash separators.

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.

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?

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

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 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.

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

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.