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.

    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.

    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.


    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

    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.

    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

    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 :grinning_squinting_face:

    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