Here is the schunk website for the tool changer module.
SCHUNK Hand in hand for tomorrow
If you download the catalog, page 55 goes over the wiring diagram.
Here is the schunk website for the tool changer module.
SCHUNK Hand in hand for tomorrow
If you download the catalog, page 55 goes over the wiring diagram.
First, post in the correct forum.
Second, go look on the servo amp for blown fuses. Its the biggest PCB in the controller. Be careful, because it contains lethal voltages. I'm not sure what controller version you are using, but the controller maintenance manual for your era controller will describe the location of the fuses.
If you are lucky, there will be a small baggie of spare fuses in the robot controller.
I mainly did that to simplify the code on the server side.
When I do a MD: backup, I just copy the entire contents of the MD: device into a folder via FTP. If I don't have FTP access, I do the same on the controller into a folder in the USB stick.
Why are you trying to use Karel for motion?
Well, he isn't using Karel itself to move, he is firing a TP program from Karel to do the moving. Or, at least, that is what the code itself looks like it is attempting to do. However, it doesn't actually write to anything the TP program could access, like a PR.
However, I'm still encountering a issue while running.
Error 3007 is "PROG-007 Program is already running". I've attached an excel sheet that will convert error codes into human readable errors.
I've tried to create a similar program before but just with .LS files. Why are you use MD backup and BACKDATE.DT? Are you planning to publish it to open source? Maybe I could test it or commit to it.
I originally had more grandiose plans for the app, mainly parsing the macro structure. That would require the sysmacro.va file.
I made it public if you guys want to fork it. It's a bit of a hot mess, as I used the townie AI to help write it.
You can view the source here:
Hmm. Would you message the backup to me directly? I'll debug it.
You didn't zero out the rest of the PR.
Try PR[1]=LPOS-LPOS to start with the point zero'd.
Also, I don't recommend using PR[1]. It is typically reserved for the home position. At least in automotive.
The SafeIO can do it, if you want to go the hardwire route. You may need some safety relays in the middle to translate though.
It would help if you listed what the errors are.
Were you able to get the program name to start with a number? if so how
But it must start with a letter.
HawkME already stated it, but programs must start with a letter. It is a fundamental limitation in the controller. There is no way around it.
Don't think I'm brave enough to release all the brakes! 😅 Would there not be quite a bit of movement in each link when this is done?
Its something you would do with the arm as close as possible to the pick/place position.
I don't recommend doing it, but it is an option provided your tool changer stand can take the weight of the arm on it.
A real redneck way to do it is to get the robot close to the pins, hit all the break releases, then touch up the point once the robot has settled in.
I've created a small web app that will generate the CALL graph hierarchy from a full MD: backup. It parses the .ls files, and looks for CALLS to other programs. Just zip up the backup, with no directories inside.
Using this tool, you can see what programs get called from where, and if there are any isolated programs in your backup.
Give it a try here: https://synapticrobotics-robotbackupcallgraph.web.val.run/
Your backup is deleted after the analysis is done.
Hovering over a program node will show what nodes it calls as orange. It will also show nodes that call it as blue. If a call is made to a program that isn't present in your backup (such as a system level karel program) it will show up as red. Programs that are present will show up as green.
You can also click and drag nodes around if you like, and also save a high resolution .png of the graph using the button below the graph area.
Short video of it in action:
Current issues:
Let me know if you have any issues with the tool.
I personally haven't done it, but I think it should be doable with the servo tool change option. You call a karel program to disconnect the servo before releasing the ATC.
Upon pickup, a similar karel program is called for servo connection.
It is option #J671. Chapter 26 of the spot tool manual goes over it.
Just right click on the robot controller tree, and select "add robot".
That is a very low F# lens. I would recommend against that, as you will have not the greatest guidance in the real world. Lots of fish eye.
A higher up, fixed mount camera is typically used in depalletizing operations.
Anyway, assuming your camera is calibrated, you could teach a simple 2d vision find with a GPM to find the red part. You would then train a reference position, and use that in your pick process.
Looks like your pictures aren't showing up. Could you reattach them?
When we did it, we wrote to a string register, and the robot would call that from the mainline.
Is it possible to use IF statements to check Karel variables? Has anyone tried it?
Your question piqued my interest, so I did a ton of digging and experiments on it. As far as I can tell, the answer is no.
For just TCP rotations, you can use the deg/sec speed option. That will limit the rotation of the tcp's speed.