Fusion 360 -> Fanuc System R-J3iB

(Just for future reference, 0V pins, COMB1-5 pins and internal GND test points (1,2) are all internally connected.)

Please let me know if I should start a separate thread for these little questions...

I am attempting to offset the Z axis of the UFRAME using digital inputs; this is to account for surface deviations in parts we are attempting to trace.
I have this -sort of- working, but I must periodically apply an offset to a position, which means that for a long move it will not update until the next position.

I can go into depth about my current solution, but I am wondering if there is a way to update a motion's offset dynamically?

Let's say, for instance, I have:

PR[5,3] = R[7]
J P[1] 50% FINE OFFSET PR[5,3]

PR[5,3] = R[7]

J P[2] 50% FINE OFFSET PR[5,3]

etc...

I can update the specific axis in the position register from a generic register, but even if positions 1 and 2 are two feet apart, I will only get a Z adjustment for P[2] based on the value read in before motion started.

The brute-force method is to break long motions into shorter chunks, which is doable. I'm just curious if this can be handled more efficiently.

P.S. I attempted writing the PR[5] from a "RUN" (parallel) statement, but sadly this requires the use of motion group 1. Even though motion is not being handled from this parallel routine, a motion group still must be assigned to update position registers. I CAN however update the register, which you see above.

Thanks HawkME, I should have known that easier = additional paid options

Good tip on the loop though, since this is pre-compiled I know how many points I will navigate to. I could possibly iterate through points in a single "for" loop if speeds and types of motion stay the same. Memory isn't really an issue here, so I'll cross that bridge when I come to it.

We had an overheat alarm the other day on one of the intelligent power modules (IPMs), so I'm doing some cabinet cleaning today. This old gal is NASTY. It came in tripping a breaker, which was likely due to the 5lbs of weld spatter piled on the internal transformer.

On the control, I have process I/O, Devicenet I/F, Main (slot 1) and PSU. As I unrack these to blow them off/clean them, I'm not worried about process I/O or Devicenet PCBs being volatile, but MAIN has the backup battery. Is there anything in the PSU that will be lost if I unrack these two? They could -potentially- be sharing the battery through the backplane.

I've done a controller backup, but I'd rather not test my ability to restore it!

FYI, for anyone else reading this the PSU does not have any volatile memory. After looking at it, I doubt it has ANY memory. If you go to clean things, make sure you leave all the little cards on the MAIN (SLOT1) PCB, as they look like they could have some volatile memory on them.

I have a basic post processor working! I need to clean things up, but so far so good for 3D. I'm going to try to figure out 5 axis post processing as well, but that will take time.

I had posted in another thread about FTP over ethernet, sadly this controller does not have the option.

CF card transfer is working for now, but is there a way to upload over RS232? It seems from what I'm seeing that this port is intended for use with KAREL only.
I suppose I can write a KAREL program for RS232 transfer, but maybe there's an easier way?

Nation, thank you again! Apparently you've got all the tools. I tried to mark your post as helpful, but then realized this stole the tag from your first really helpful post.

I'll give this a try this evening!

Long overdue, I finally got to give this a try. It worked great!!! I prepared some notes since I know I'll forget the steps, and I'm putting them here for future use.

I used a Windows XP computer with a hardware serial port. I'm unsure how much flow control plays into this, as at 9600 baud I think both the controller and PC keep up quite well. You could likely ignore flow control and just use Rx, Tx and 0V lines.

On robot teach pendant:
    Menu > File > File > [UTIL](F5) > Set Device (1) > Floppy disk (1)
    
Run CMD.exe
cd to kfloppy.exe folder
run kfloppy.exe

Setup > Port Settings, modify as appropriate. Did not have to change defaults for RJ3iB, only port number.
File > Change Directory, move to an appropriate folder (preferably other than the executable folder).

For backing up programs:
    On the PC:
        Create an empty folder through windows explorer or command line, then change directory in kfloppy
        (as shown above) into this folder. 
    On the robot:
        Menu > File > File > [BACKUP](F4) > your choice of files to transfer
        Note: I had a repeating error where the file cannot "open for read". This is likely due to 
        *.TP not being ASCII readable. The log file "KFLOPPY.LOG" will be automatically generated and also
        placed into the directory with the backup files.

For sending programs:
    On the PC:
        Create an empty folder through windows explorer or command line, place your file to be sent there,
        then change directory in kfloppy (as shown above) into this folder. 
    On the robot:
        Menu > File > File > scroll down to the extension of file to transfer (I did not have luck transferring all file types, but I am unsure why)
        [LOAD](F3), then you should see a prompt to agree to transfer the file you are trying to load
        
What is happening here?
    This utility was apparently written outside FANUC with the intention of emulating an RS-232 capable
    floppy drive. You are configuring the program with the correct parameters so that the controller can 
    see it on the UART, then dumping programs to the "floppy" or requesting programs from the "floppy".

If I ever get bored, I might try to create a 64-bit compatible version of this that will work with USB<>UART converters. But no promises, I'm rarely bored