I don`t have FTP...
How do you know this? FTP server is typical for R-30iA.
I don`t have FTP...
How do you know this? FTP server is typical for R-30iA.
There is a R-30iA Mate controller documentation CD for sale here:
https://www.robot-forum.com/robotforum/use…n-cds-for-sale/
By applying a current meter as the only load, you are creating a short circuit on the output.
It looks you were lucky and the output is overload-protected. Don't do it again!
Connect a real load, e.g. solenoid, and don't forget about a spark-killer diode.
I recall similar problem on early versions of R-30iB, especially with the maintenance data backup.
Looks fixed on the later ones.
The R-30iA outputs are sinking. Measure between +24 and the output.
Make a search on this forum for $SSR, read the found posts.
At least two of them are explained.
You described the DI mapping in the robot, but said nothing about the Ethernet/IP configuration.
Is it set as Adapter and enabled?
Does the connection size setting in the robot match the one in the PLC message?
Did you reboot the robot after assigning the IP address?
This is a handling application.
The robot moves by MOVL through calculated targets, without changing RX,RY (the tool is always hanging downwards).
It may be or may be not +/-90deg RZ rotation between consecutive targets. The MOVL speed is specified as linear.
When there is the rotation, its angular speed must be limited, to prevent losing the product from vacuum cups.
Is there a parameter to limit the T speed?
Or opposite, to limit linear speed ? (I could specify angular speed in MOVL in such case, with no worry about linear overspeed).
In Fanuc, I can specify motion time instead of speed. Is there such option in DX100?
If using VR, I have an opposite problem- need to limit the linear speed.
Any other ideas?
Limiting the T speed will also work for me.
Is there a way, in DX100, to limit the RZ angular speed, while executing MOVL with linear speed specified?
Once started manually, a BG program will start automatically on every boot, until stopped manually.
Be sure to set "ignore stop conditions" in its Detail.
Send a signal to the PLC, indicating the local Start button pressed, and let the PLC start the robot remotely upon this signal.
The signal may be created by executing in background logic: DO[n]=(SO[1:Cycle start]).
I mean, when you use absolute encoder, the absolute position of the robot is found out any way and not affected by batteries.
By setting the master counts you just "explain" to the robot that this specific point on the absolute encoder is your starting point.
Am I wrong?
Wrong in part.
Absolute encoder is absolute and not affected by batteries only within one turn.
Battery is necessary to store multiturn count.
By setting the master counts you just "explain" to the robot that this specific consolidated value of multiturn count and absolute position is the joint zero.
From my experience, the conveyor tracking option (when installed) requires steady motion not faster than 300 mm/sec, in order to have about 10 mm repeatability of the tool contact with the piece.
Even if you succeed implementing it programmatically, expect much worse result.
I would consider stopping the conveyor for pickup (in which case you still need to track the piece, but at least don't have to follow it with the tool). Or, even better, stop the piece by retractable stopper, without stopping the conveyor, if the robot is ready to pickup.
You still did not specify the speed and the necessary pickup precision.
Group DIs into GIs in I/O menu. Process the data from GI in your program.
The robot interprets data from GI as unsigned integers.
Try Assembly Instance 101d for reading from robot.
More reliable than what?