Someone told me about DART studio, Doosan's IDE, which makes this easy.
Posts by schnepper
-
-
Hi,
Does anybody know of a way to upload and download DRL files between a Doosan cobot controller and a PC other than using a USB stick? Having to use a USB stick really slows down the development process. With most other robots we work with, there is a way to copy from a PC to the robot controller over the network. Looks like Doosan runs Linux on their controller, so it would certainly be possible to run an ftp or scp server on the controller.
-
Thank you, Nation. That was a big help.
-
How do I see CPU usage on a R-30iB Mate Plus controller?
-
Fanuc Tech Support gave me the solution. The GET_PORT_VAL Built-In Procedure will return a no-zero status if there is an error, in this case the error is PRIO-104 (Device is off-line).
-
Thanks for the ideas, CSaunders. The first idea is not practical for my case. I'm actually reading all the DIs in a loop to see if any have changed. I tried the UNINIT idea, but it didn't compile.
-
If I try to read a DI on a device that is OFFLN, my Karel program throws INTP-347 (Read I/O failed) with an underlying cause of PRIO-104 (Device is off-line). I'd like to ignore this error and continue program execution or detect that the device is offline before attempting to read the DI. I already detect if the DI is not assigned using GET_PORT_ASG, which works well.
Is there a way to determine if a DIO device is offline before reading it? Either in Karel or TP code.?
Is there a way to continue execution after receiving this error? I tried using a condition handler but it does not work. Here is the code for that.
Code
Display MoreCONDITION[OFFLINE_CH]: WHEN ERROR[13104] DO WHEN ERROR[12347] DO NOMESSAGE NOPAUSE NOABORT CONTINUE ENDCONDITION ENABLE CONDITION[OFFLINE_CH] FOR i = 1 TO DI_COUNT DO IF assigned(PORT_TYPE_DI, i) THEN dis[i] = DIN[i] ENDIF ENDFOR
Does anybody have ideas to solve this?
-
Hi,
I am using socket messaging to read commands in a Karel program. The sender is a Linux PC. The controller is sending a TCP Window Update packet for every byte it reads from the socket, slowing the process considerably. It takes >200ms to read a 51 byte message.
I've attached a Wireshark screenshot. Packet 45 is the PC sending commands. Packets 47-70 are the Karel program sending progress messages. Packets 71-122 are all TCP Window Update packets, each incrementing the window size by 1 byte. Messages are received intact and the program works correctly. It is just too slow for our application. I know this is an old beast, but Fanuc's TCP stack should be more efficient than this.
Has anyone else seen this? Is there a workaround? I looked for system variables that might control the TCP window size or flow control, but didn't find any. Do formatting options on the READ statement help?
Details:
R-J31B controller running version 6.4
M-16iB/20 robot
Relevant lines from my Karel code:
MAX_STR_LEN = 128
cmd : STRING[MAX_STR_LEN]
cmd = ''
READ socket(cmd)
Thanks,
Mark