RobotStudio event

Dropping Files

Sessa709
Sessa709
edited November 5 in Robot Controller
This is a continuation of the discussion I started here.

We are having a problem where files are sometimes not being loaded into the pendant.  Here's part of the code:

VAR loadsession loadid1;

!SetDO doWaJobActive,1;
  RunPrgNrInropa := 0;
  LoadPrgNrInropa :=0;
bLastRoutine := FALSE;

WHILE bLastRoutine = FALSE DO
      WaitDI diReadPrgCmd,1\MaxTime:=50;
       SetDO doReadPrgAck,1;
       StartLoad "PC:"\File:="Inro"+NumToStr(LoadPrgNrInropa,0)+".mod", loadid1;
       WaitLoad loadid1;
       TPWrite "Loading Inro"\Num:=LoadPrgNrInropa;

Then it increases the counters, unloads the program, starts again...

What's happening is the program is stalling at the "StartLoad" line with a 40702 or a 40698 error.  Its as if the FTP program isn't getting the signal to load the file...which I can see on the Filezilla Server log.  Normally when it gets to that line, the server will say:

2024-06-17T01:19:54.449Z << [FTP Session 2 10.10.10.10 robot1] 200 Noop ok.
2024-06-17T01:19:56.044Z >> [FTP Session 3 10.10.20.10 robot2] NOOP
2024-06-17T01:19:56.044Z << [FTP Session 3 10.10.20.10 robot2] 200 Noop ok.
2024-06-17T01:19:57.186Z >> [FTP Session 2 10.10.10.10 robot1] TYPE I
2024-06-17T01:19:57.186Z << [FTP Session 2 10.10.10.10 robot1] 200 Type set to I
2024-06-17T01:19:57.187Z >> [FTP Session 2 10.10.10.10 robot1] PASV
2024-06-17T01:19:57.187Z << [FTP Session 2 10.10.10.10 robot1] 227 Entering Passive Mode (10,10,10,2,211,25)
2024-06-17T01:19:57.188Z >> [FTP Session 2 10.10.10.10 robot1] RETR /Inro1.mod
2024-06-17T01:19:57.188Z << [FTP Session 2 10.10.10.10 robot1] 150 Starting data transfer.
2024-06-17T01:19:57.188Z << [FTP Session 2 10.10.10.10 robot1] 226 Operation successful

However, when the file is dropped, the server is just going "NOOP" "200 Noop ok." as usual.  The only way we're able to get the files to load is to stop the Filezilla Server, and then start it again.   This seems to force the file to load as we can start from the StartLoad line.  Over the course of 26 files, this happens about 8 times throughout the session.  I've tried playing around with different FTP servers, and the only thing that "works" is creating a windows task to start and stop the FTP server every few minutes...but even that is problematic. 

Any ideas?
Post edited by Sessa709 on

Comments

  • lemster68
    lemster68 ✭✭✭
    Add an error handler to that routine to address those two errors.  Then RETRY or whatever seems to be the most appropriate course of correction.
    Lee Justice
  • Got that.   Still hangs up on the "StartLoad" line.

            ERROR
        IF ERRNO = ERR_WAIT_MAXTIME THEN
    IF RunPrgNrInropa>10 THEN
                ErrWrite "Timeout on Signal",
            "Trynext attempt";
    TRYNEXT;
    ELSE
                ErrWrite "Timeout on Signal",
            "Program execution stopped";
    STOP;
                        RETRY;
    ENDIF
    ENDIF
    IF ERRNO = ERR_LOADED THEN
            CancelLoad loadid1;
            Waittime 1;
    RETRY;
  • lemster68
    lemster68 ✭✭✭
    I am assuming that when you mentioned that you restart the Filezilla server, you are doing that on the PC side.  Is that correct?  Is there some way that you can reinitialize it from the robot end?  Perhaps try CancelLoad on the timeout error before you RETRY.
    Lee Justice
  • Yes, I'm trying to figure out how to reinitialize the connection from the robot end, but I'm not having any luck.  I tried putting a CancelLoad in that section of the program to no luck.  Didn't see any commands come through on the filezilla connection, and the file didn't transfer.  I tried writing a ReadDir procedure to see if that would work, but I couldn't figure it out.  Any other ideas?   Thanks for the help!
  • lemster68
    lemster68 ✭✭✭
    Wow.  This is turning out to be quite the rabbit hole.
    I found this:
    CancelLoad can only be used between the instruction StartLoad and WaitLoad
    And this:
    Execution of StartLoad will only order the loading and then proceed directly with the next instruction without waiting for the loading to be completed.
    So, with the WaitLoad immediately following the StartLoad we are in sort of a predicament.
    This makes things even more fun:
    RETRY cannot be used for error recovery for any errors from WaitLoad

    The manual does not indicate that there is an ERR_WAIT_MAXTIME for the StartLoad or WaitLoad instructions.  There is, however, for WaitDI.  The Errors I suggest checking for will be ERR_FILNOTFND and ERR_IOERROR.

    I always recommend that people use a TEST CASE in their error handlers instead if IF statements.  People expect that there could be one or only a few error scenarios when in fact there could be some other error that is completely unexpected.  For this scenario, one should always include a DEFAULT in the TEST CASE.  Use a Break or Stop instruction in the DEFAULT.  If one finds oneself here, it will be necessary to see the value of the system variable ERRNO and match it with one of the built in error numbers to see what the error is that occurred.
    Next, I will suggest using a unique loadid for each module.

    Finally, have you reached out to Filezilla tech support yet?
    Lee Justice