Posts by AlanL

I haven't done it with EIP, but I've done it with both Modbus TCP and SRTP. Both are pretty easy and may be worth it to check out. Put what you want to send into SNPX_ASG in the robot and do whatever you want with it in the PC. I'm not sure exactly what need it fills, but we have to have the HMI option. I think the option enables either modbus communication or snpx.

Looks like you are using CNT0, try upping those. CNT0 moves are pretty close to fine moves so the robot is going to be accelerating and decelerating a lot between each move, if the points are close together it won't have the opportunity to move fast. If you don't need the accuracy a CNT100 move is going to be much faster. Usually I use CNT100 for open air moves and like 1 move before a fine move for a pick I'll switch to somewhere around CNT10. But if you need accuracy to get into tight spots or to avoid things you'll need to keep your CNT value low.

I've used this before, but I think it's unsigned. You may be able to modify it to ignore the last bit and sign it yourself

R[1] = (high byte * 65535) + low byte

Set $IO_AUTO_CFG to FALSE

Menu > Next > System > Variables > $IO_AUTO_CFG

You can do a circular or circle arc move (may depend on the software version). It's another type of motion like linear or joint.

We used to run into that on occasion. If I'm remembering right, I think it was happening only with PR[1] for us and may have had something to do with PR[1] specifically. It was something that only happened a couple times a year.

I don't see any way you could. We use Python scripts that get called by task scheduler on an IPC every day. You could probably write a script that monitors an output to trigger a similar script.

Unfortunately most manufacturers instructions only show you how to setup EIP on an Allen Bradley PLC. Most of the time you can find those things in the product's documentation. For times when they don't include it you'll have to look through the .eds file and try to pull the information out of that. Fair warning, the .eds file isn't easy to make sense of. You can use EZ-EDS Editor to help you interpret the file. You'll also have to find the bit/byte/word mapping of the assembly instances so you can map you I/O accordingly.

That's a battery alarm. There are 4 batteries under the cover in the bottom of the robot arm. I think they are C batteries. You'll probably have to remaster or do a recovery after changing the batteries if the robot wasn't powered.

SO 5 & 6 aren't used for HandlingTool. Although, I can't say for sure that also means they are unusable.

You can add a timeout to the wait and have it jump somewhere else. We stymie that by having the label that is jumped to turn on an output to trigger a red light, pause the program, and just have it jump back to itself so if they restart they are stuck in a loop. Savvy operators could still go up to the line it failed at and restart, but they'd have to know where to go.

It sounds like you want to go into system/config and change Remote/Local setup: to local.

I wouldn't do an image to duplicate between lines, I believe images take mastering data so you'll make more work for yourself. I haven't tried an AOA from one robot to another, I've always been too weary about getting a couple files that could be a problem. I would take an AOA and take all of your TP and karel. I think these will get you most of what you need: diocfgsv.io, numreg.vr, posreg.vr sysegd.sv, sysframe.sv. There may be a few more, but these will get you most of the way there.

Rack 89 is for the Ethernet/IP protocol. I think you want to wire to CRMA15/16 (assuming you have it) and map your GIs to slot 48.

You can also use socket messaging and set up $SNPX_ASG and to write directly to the register and skip the group input. I think you need an option like the HMI option for $SNPX_ASG to do this though. I believe if you do an internet search for fanuc robot srtp you'll find some Github projects that can take up a lot of the backend.

1st thing I would check is that the + and - are facing the correct way on all 4 batteries. It's really easy to mix them up. Sometimes the BZAL alarms are hard to get to go away when you change the batteries, but I haven't seen one come on the next day.

I think you can get this error a few way, but the main time I encounter it is in TP programs trying to use PRs. If you try are doing anything with a PR it needs to be initialized, if you look at a PR and it has a * then it isn't initialized. If it has a "R" it has been initialized. All you need to do is shift record to initialize one, then change it to what you want.

If your using karel you can run into it there. The error is just telling you that you are trying to use something that isn't initialized, you may have to chase it through your code.

Just plug into the switch

If your image is corrupted I would start by restoring the image. Once the image is good you can reload from backups.

To get files from Roboguide to a robot I usually just save them to a folder on my desktop. That way I can transfer them either with ftp or a usb stick. I think there is a way to do it inside Roboguide, but I've found that I use it so infrequently that I don't bother trying to remember.

If your process can handle it you may have some luck changing the CNT100 to something like CNT10

Would it put it in a singularity at that position?