The UOP Input Signals of your xxTool manual covers the intended uses of the Prod Start and Start UI signals
Posts by CSaunders
-
-
Would you be willing to share the source code? I am curious on how this work
not sure if you were also asking about the user/pass portion of the original PC, but it can be recreated utilizing $password.$num_users and $passname.$name/$password
hope this helps.
-
I recommend the PLC guys add logic to record the ACK when the production start bit (or something similar) goes high. A group output could be sent from the robot to avoid looking for a consistent ACK and to monitor sequence progression.
-
here is our weld setup
In the example above we tried a 1 in the brackets. No difference
can you send a picture of the SETUP->Weld Equip screen?
-
If you have the J541 Password Protection option you can use something as shown below to prevent certain users from accessing or modifying system variables. Change the level #'s and access 0/1's to meet your needs.
<SCREEN level="1" sp_id="34" scrn_id="1" access="1" rw_access="0"/>
<SCREEN level="2" sp_id="34" scrn_id="1" access="1" rw_access="1"/>
<SCREEN level="3" sp_id="34" scrn_id="1" access="1" rw_access="0"/>
Without J541, you may be able to set the specific system variable in BG logic - depending on the user this may not be effective either.
-
I had the same issue installing a new Rev over top of an old one. The solution was to completely uninstall the old version, then install the new.
-
Check the value of $SCR.$RUNOVLIM
-
I haven't tested it, but the built in UNINIT function might work, so long as you don't leave it unsubscripted. Something like this:
nChk = 0
For nChk = 1 to 32(whatever the array size)
If UNINIT(yourArray[nChk]) THEN
yourArray[nChk] = 0
Endif
Endfor
-
Looks like your syntax is a little off.
Best way to clear that up is break each condition down into parenthesis.
If ((UO3=ON or UO4=ON) AND (DI11=ON and DO449=ON))
-
You'll unfortunately always have to power cycle an OVC alarm. The alarm refers to a higher than desired current draw on axis 6 motor (in your case). Typical causes are mechanical failure of the reducers or gearing, overloading, brake releasing (open circuit) during motion, or just pushing or pulling too hard.
Hope that helps.
-
Hello
I have the same problem right now, the robot was moving in manual and sudenly the robot stop and showed up this alarm SRVO-046 OVC alarm. What do you mean when you say check the axis configuration? Can you explain me How I can do that? Please
It would benefit you to start a new thread with details of your robot - arms, external axis', etc
-
Is there an option to Reset Ownership above where you entered the HEX/Date?... Hit it, then switch to the General Tab and re-generate the SNN.
-
I was thinking torchmate cahnges the TCP frame values automatically , how to do that??
Or It is only to see those variation in DATA, nothing else, its not for auto updating or adjusting TCP???
Pls answer
Torchmate adjusts the tool frame each time TM_Adjust is executed. If you see variation after running torchmate several times concurrently, I would assume you aren't using the correct tool frame or something else is configured incorrect.
-
I believe SET_ATCP is hidden by default. You can try manually calling it by selecting INST -> Call -> Call Program -> STRINGS -> Type "SET_ATCP"
-
because i dont now when drop should be done. I have only one signal, if position of pallet is X then call transfer therefore checking signal should be independent of program run, must be monitoring all the time.
Still a bit muddy on why you need to, but you can accomplish your BG logic task by using Macros instead - may need to utilize abort signals if the robot is busy with another program at the time you send the macro bit.
-
Try Cell->I/O Interconnect from the top menu line. UI isn't listed in the list of data you can interconnect, but you can circumvent that by configuring the UI to DI in the I/O UOP In settings.
Not sure on your typical UOP configuration, but this is how I cycle simulations
-
Toggle QUICK/FULL MENUS via Function Key
-
Is it possible for you to leave a DI ON all the time and UALM in BG Logic if it ever goes off? Simplest way I can think of.
edit: or maybe check the port value with IF UNINIT and see how that handles offline conditions? Never tried
-
And by jarring do you mean that it is jarring itself? i
I suggested that the part could be jarred/slip in the gripper due to the robot's rapid acc/deceleration, but STEP mode would rule that out.
Not sure what else to recommend other than a dial indicator or fixed/stationary object you can bring the gripper and/or part over to for determining what is varying.
-
Without knowing too much about the gripper or component, I recommend setting up a dial indicator, programming a point to apply a set measurement, and then sending the robot to that point from various other positions. That would give you an idea of the robots capability.
Is it possible the part is shifting in the gripper? 100% Fine moves could cause jarring, potentially allowing the component to move.
Advertising from our partners
