So all they really have to do is press the reset first, then the resume. Doesn't seem like too big of a deal, but if you really wanted to you could program the resume button to trigger a sequence in BGLogic that pulses the reset signal, then waits, then pulses the resume signal.
To do so you need to map your reset and resume UOPs to flags instead of the hardwired inputs. Then change your hardwired inputs to DI's. Then create a BGLogic program that uses the DI's to control the flags.
That makes sense, Cartesian is always relative to a tcp.
First, let me ask what is controlling your UOP inputs? Is it a PLC, HMI, hardwired buttons, internal robot control?
AB devices are really only designed to work with AB controllers.
AB PLC to Fanuc robot communication works really well, but any other AB devices are best to be controlled only by an AB PLC.
I would open up the tolerance a bit. What are they set to now?
Since this is a safety device then it should be wired to break the EAS safety signal, or go to a DCS safe input. Anything else will not be safety rated.
To resume you must pulse the reset signal, then the start signal. You could do that with a single button press if you set up the logic to do so either in an external PLC or internally using BGLOGIC.
Matlab can send an HTTP request. I think that would be the simplest option.
HTTP is the communication protocol used by all web pages on the internet and is commonly used for computer applications to communicate to each other. Google it.
Not possible.
That is the purpose of the KFloppy software. I know it works on RJ2. You must have the correct cable and a windows XP computer.
If you can send HTTP then you don't even need Karel. HTTP can set register values. You can monitor them in BGLOGIC to start a main program. In your main program you can conditionally call subprograms based on the register values.
I've never dealt with this device before but maybe you can connect to it with RsLinx and gain some insight. On some AB devices you have to set the number of cards attached which can be done in RsLinx.
It may be possible but sounds like a difficult job for a robot. Robots don't have the dexterity that a human hand does.
1. You would need a compliant end-effector so the robot doesn't constantly detect collisions, but not too compliant that it doesn't have enough force to scrape the paint off.
2. The Robot would need to have enough reach and access to booth without getting in the way of the painting process.
3. The robot wouldn't be able to tell if it was successful or not. Sometimes you probably scrape the same area until the paint has broke loose, but a robot won't know that. It will just do the programmed routine.
Good luck!
Yes, that's what the new pendants look like. Or just go to menu>file>backup controller as images.
Then to restore you boot up while holding F1 & F5 and select restore controller image.
The solenoid is internal to the robot. Are you sure it is labeled correctly? Take out the plugs and see where the air flows. Try toggling the other ROs to to see what happens.
Are RO 1 and 2 set up complimentary?
What is your air pressure?
Going off memory, I think the GO max value is 2000. You can easily verify by switching from TCPP to volts and set to 10 volts (that would be max analog value) and see what the GO is.
Lock PREG locks changing the value of all PRs. For sealant dispensing you must do that so it can "trust" the PR and use in it's look ahead calculation. If you don't it will set the flow output to a default value and ignore TCP speed. Of course remember to unlock. Best to lock just before SS and unlock right after SE and unlock at beginning of Main program.
Calibration will affect the scaling. Usually I just skip calibrating and set the system variable instead. No matter what it will still not go beyond the max output value which I think is 2000.
DispenseTool has is quirks for sure and doesnt work perfectly in Roboguide.
First you have to setup the dispenser in a controlled start menu.
Then you setup a sealant schedule in the Data menu set to TCPP.
Then set GO in the IO menu.
SS command includes a schedule #, for example SS[1]. Can be used on its own but more commonly as part of a motion instruction.
Also if you use any PR you must "lock preg" before starting.
There is also a dispenser calibration that needs to be completed or at least set the system variable value.
Doesn't really make sense the way you explained it but you can get the position in degrees from the system variable also. Why would you have to move to the position?
Why not use a skip condition? That is the intended way to do this kind of thing and doesn't require any BG Logic.
Yes, I think it usually comes with Roboguide.
I think you might be able to do this with the motion pro diagnostic tool.
I know for sure you can track tcp speed, just not sure about plotting with the GO.
I would just use PNS0001 as your main program if it doesn't have 'other' available.
