Posts by sibrdave

can you be more clear as to what you are trying to do? One way to set the current active workobject or tool during auto is SetSysData wobj (or tool).

This is a possible 2 part question based on an available solution to the first.
Q1) is there a standard function to calculate a robtarget displacement from one workobject to another? Eg. I have a robtarget created in workobject1 and I want to reference the same position in workobject2 without moving the robot or declaring new constant robtargets.
This seems like a simple function to provide but i couldnt find anything that does exactly this, so I created one:
FUNC robtarget TargetDisp(robtarget pSource, PERS tooldata tToolUse, PERS wobjdata wSource, PERS wobjdata wDestination)
VAR robtarget pDestination;
VAR jointtarget jTemp;

jTemp:=CalcJointT(pSource,tToolUse\WObj:=wSource);
pDestination:=CalcRobT(jTemp,tToolUse\WObj:=wDestination);

RETURN pDestination;
ENDFUNC

Works great.

Q2) if there is no such standard function provided then i can use the one I created but I would like to add a comment to the declaration that shows up in the tooltip when you mouseover the function in robotstudio. I can't seem to find anywhere explaining the syntax to adding the comment although there is a placeholder for a comment in the help for function declaration.

Actually i was referring to the override select shown in attached pic. Menu/setup/ovrd select. You can assign DI's from the plc over profinet to allow the plc to control the override speed. Normally values for fieldbus I/O default to zero when disconnected or comms lost. So if you had DI 1 & 3 in my example both on the robot would run at 100% but if u lost comms the override select would interpret it as a request to run at 10%.

Sounds like PN comms loss, maybe a bad cable? Or ive seen slow plc scan times create delays in rpi. If your speed override is active and both signals off = 10% then that would explain the slowdown. What plc is running? And what is the overall scantime?

Can you be more specific as to what you are trying to do, access IO, access web page etc. You can certainly open socket communications between your C# app and your robot if you have the socket messaging option installed.

Use the opc da client driver in kepware then add the tags u want. I used generic tags of a 16bit datatype then remapped them on the plc and in roboguide. Once u have the driver running in kepware, it will become available in roboguide external devices with the anonymous host type. Once u have the opc conected in roboguide, add external io and you will find your opc tags in there to map to group inputs/outputs.

Correct. At step 3 you will power off the controller and then remove battery power.

The process only seems lengthy for the first attempt at finding the master pulse positions. If you can do this ahead of time as a preventative measure and somehow mark the robot to know where to jog each axis, it can be done quite quickly. The benefit of this restore master method as opposed to any remastering method is that the robot calibration and hence positions will be exactly as before. All other methods except quickmaster rely on human precision and will inevitably be slightly different at best. No matter what you do, if you lose master counts due to BZAL, you will need some reference point to jog to if its not the factory zero marks. Maybe a hardstop? But you said you didnt want to add hardware. The encoder position is the only other thing to look at but you need a starting reference position. Im curious, what was your original idea that involved needing the marker pulse?

Youre in luck, i have posted a thorough description of how the factory mastering counts can be restored after bzal without remastering. This will work for your situation with some slight modifications. When u say the robot cannot go to the witness marks, do u mean only all axes at the same time but possibly one at a time? Factory zero is not necessary, you can remaster to whatever position you want and still be able to restore after bzal but its very helpful to have some new scribed or otherwise marked position for a new "zero" if you cant reach factory zero on an individual axis. Check out this post https://www.robot-forum.com/ro…3668/msg117802/#msg117802

Your understanding is correct. Did that info help with the issue you were trying to resolve? Or is there anything else you can add to describe the issue you're trying to resolve?

dmr_grp[1].spc_count updates with each count. If u jog until this parameter value is equal to zero, you will be on the marker pulse position. I think i read that the count value is actually a couple pieces of data at different bit offsets such as count, revolutions, and maybe error check, so u might be able to calculate how much to increment the spc count for each revolution of the motor.

Has anyone had success with the thread edgar_martin94 linked? It was also my understanding that roboguide does not have a driver implementation for an ethernet adapter to communicate outside of the software (probably intentional). Roboguide does however provide a small doorway to an external communication link through OPC. At the bottom of the cell browser tree theres an object called external devices. Here you can make custom connections to an opc server thus bridging the gap from di/do gi/go to anything on the outside that can be an opc client. This means a real plc, hmi, simulated hardware, pc, android, ethernet lan, internet, profibus, serial, etc. Your imagination is the limit.

Thank you, im looking forward to your feedback so i might be able to improve on the explanation. Its great that u have a development robot you can test with, and will take some time out to test. I will appreciate your input, be sure to let me know if the process is difficult to follow or you cant get it to work.

Wouldnt u just create a custom unit load that only consists of a partial pallet worth of units? It sounds like you are short cycling the pallet load by forcing it out too soon so the unit load indexer is out of sync. Can u provide more details of what u are trying to accomplish?

Why was it unprofessional? I was asking him to explain why he shot down my solution without an explanation, i think thats fair. By the way you are wrong about master counts, they are not arbitrary. There is 1 sync pulse per revolution which is what triggers the counter when u first power on the motor, thats why u need to establish the pulse count first. Since there is one specific pulse, it is mechanically linked to the position of the axis its motor controls. I know my other post seems lengthy but it was an attempt to bring clarification to how the motors and master counts work, so once u understand it you can restore a robot inless than an hour. Much faster than remastering and touching up a ton of points. BTW, its a forum, not all solutions are the best for every situation and some people want to have alternate solutions too. Until someone can prove my solution doesnt work, i stand by it because ive used it on 3 robots since i wrote it, and it saved the day.

Vision mastering is reported to be very accurate and one of a couple of valid solutions. However there is a way to restore your robot mastering in the bzal situation without remastering because remastering inherently will give you slightly different positioning every time. Search for my posts and u will find a full description of how this works and is likely the fastest/cheapest way to get ur robot back to the EXACT same positioning as before bzal.

If you want to debate my solution you should provide some facts and explanation like i have. Why do u think my solution doesnt work? Can u explain what quick mastering does and how it works in comparison? The solution i provided WILL work in the event quick master has not been set up like in the OP scenario. The whole issue is that the pulse coders have lost their count position which can be restored. I have a lengthy description in another post if u search it up.

Actually the way you tried to preserve the zero positions is not correct unfortunately. However there may still be a way to get it back to good. If u know u are going to be removing cables from the motor(s) which causes the pulse coders to lose count, then u should jog the robot into a position that leaves the pulse counts at or just beyond the master counts. Then when u first power on the motors after changing the cable, you have to jog to establish a new pulse, from the position you left the robot in. This should put the pulse counts back to the factory counts and after calibrating, zero marks will align. An apparent misconception is that zero alignment is the same as factory master counts, it is not. The master counts are how many counts to get to zero alignment after powering on the motor from first assembly. This is what quickmaster is for, it does the same thing but u need to set it up before disconnecting cables so in your case u need to re-establish master manually.

You should have a battery box somewhere for the aux axis, otherwise you would have to remaster that axis each time the controller was powered off/on. But thats a different issue than the OP. Its sounding to me like the motor is overheating causing the pulsecoder to fail, are you sure the brake config is correct in the aux axis setup? Some motors will have no problem driving through the brake while still engaged which would cause a lot of heat and probably even blow the brake fuse.

I dont know where any documentation is to point you towards, i just figured it all out myself. Yes i did it with a siemens plc simulated (but also with a logix5000) the setups are similar. Use kepware opc, its a free download but annoyingly has a runtime time limit. I dont currently have a tutorial but if u have enough time to spend and an aptitude, you can figure it out. I can help with questions if you get stuck along the way but you should see if you can get it working without a spoonfed walkthrough. Siemens plc sim, roboguide external device connection, and kepware.