[roboterxj]

hi jpa, it sounds like you are moving rite along. good that you have the guides. Your link looks like all of them, at least that I have.
So I have a terminal emulator on "PUTTY" I can use that to move the arm in simple move and joint commands, and in world coordinate moves as well. BUT I can't get past that. I got pretty frustrated so I put this on the back burner a bit. if I remember as far as I got. I was able to get some very simple one line programs to compile, but I could not send them to the controller I keep getting not compatible CROS messages. Which was really frustrating because there was only one copy of CROS involved and that is on the controller. If you have a bit of time some day, I would like to see if you can send or publish a sample program that you had success with from the terminal to the controller?? That would be great.
If I thought I could make some progress I would pick this back up in a minute. as I too want this arm to accept some g-code, for some very light CNC mill/router/cutter work. I want to at least be able to get it to do some even 2D CNC work, at least to start.

I am wondering if maybe I am having a incompatibility issue with the PUTTY terminal? As opposed to a different " brand" of terminal emulator? I would think not, but heck I don't know. like I said I can get the terminal to run basic single axis moves and even the multi axis world coordinate moves, but I can only do one move at a time.

thanks for keeping up the communications on this. Have you seen the CRS F3 thread on the Rasberry Pi forum, there were several operators on that forum, but the thread has gone a bit dead at the moment.

https://www.raspberrypi.org/forums/viewt...p?t=116806

good luck with your arm
thanks

[jpa]

I would like to see if you can send or publish a sample program that you had success with from the terminal to the controller??

The programs I've tried so far are pretty simple. My eventual goal is to send the coordinates from PC in real time. The RoboDK approach is processing the complete path into a .r3 file, which should work also.

I'll explain here the steps I've used to transfer files to the controller, compile and run them:


Part 1: Install uudecode
This is a custom utility I wrote to make file transfer easier, without using any of the original PC software. To install it, do this in the serial console (PuTTY should work fine):

1. Go to binaries directory:  "cd /bin"
   
2. Use built-in editor to create new file:  "edit uudecode.r3"
   
3. Type edit command to insert text on line 1:  "i1"
   
4. Copy paste the code from here    https://raw.githubusercontent.com/Petter...udecode.r3
   
5. Press enter to terminate insert mode
   
6. Type "s" and enter to save, then "q" and enter to quit editor.
   
7. Compile with "r3c uudecode.r3"
   

Part 2: Transferring files
Pasting to edit only works for simple files that have no empty lines. Now with the uudecode installed, we can easily paste any files by first uuencoding them on the PC. 

1. As a test file, you can use this: https://raw.githubusercontent.com/Petter...le_test.r3  It will move +- 50 mm distance from current robot location in X and Y directions, repeating that 10 times.
   
2. uuencode the file. On linux there is uuencode command, on Windows you can use it online e.g. here: http://www.webutils.pl/UUencode
   
3. You should now have an encoded file like this: http://paste.dy.fi/Nbz/plain  If the file name on header line is wrong, you can edit it, that's the name it will get on the CROS side.
   
4. Go to directory where you want to put the application: "cd /app" is a good place
   
5. Type "uudecode" and enter, and then paste the encoded file from step 3.
   
6. Then you should see the file with "ls -l" and be able to compile with "r3c simple_test.r3".
   
7. Run with "./simple_test" and it should move the arm. ARM power should be on first, and it may ask you to press pause/continue to take "point of operation", i.e. give permission to application to move.
   

If you run into any errors there, just ask!

[roboterxj]

thanks JPA, I will give it a try this weekend.

thanks

[Gordax]

Hi JPA, 

I am impresses with your work so far with ROS and the CRS robot.

I have a A465 with the c500c controller which I am also trying to get running.

I have encountered a problem when I try to run the move command with a Cartesian Location 

move cloc( int flags, float x, float y, float z, float roll, float pitch, float yaw, float e1, float e2 )

as

move cloc( 0, 400, 0, 300, 0, 0, 0, 0, 0)

Its throws an error and asks for position Flag

Have you managed to send the controller any cloc locations?

Or do you know much about the position Flags?

I will also check my reference frames again, I suspect I have an error there. But I still don't think it will solve my position Flag error.

Also I have flashed my controller with another version of Cros and re calibrated it - havent checked the precision yet.

Cheers

[jpa]

move cloc( 0, 400, 0, 300, 0, 0, 0, 0, 0)

Its throws an error and asks for position Flag

The position flags are manipulated with loc_flags_get() and loc_flags_set() functions as described in the RAPL-3 reference:

Code:

global const LOC_INVALID =0x00
global const LOC_VALID =0x01
global const LOC_CALIBRATE =0x02
global const LOC_MARKER =0x04
global const LOC_NULL =0x08
global const LOC_METRIC =0x10
global const LOC_TOOL =0x20
global const LOC_BASE =0x40
global const LOC_OFFSET=0x80

Probably you need at least LOC_VALID and might want LOC_METRIC and LOC_BASE.
You can take current position with here() and use loc_flags_get() and loc_cdata_get() to see what kind of flags and position it uses by default.
The manual has some examples where cloc constants are used as arguments to e.g. tool shift, in which case the flags don't seem to matter. But when passing it to move() directly, you need to set them.

[kumarip]

Thanks for the information

[Gordax]

Hi JPA,

Thanks for the info and I did get it moving but the flags are still giving me problems.

To take it back a step, do you think it is wise to try to control the robot using Cartesian locations of should I be trying to control it by precision locations/encoder pulses?

I went down the Cartesian locations road because that is what the RoboDK app output, I couldn't see an option to output joint angles or encoder pulses.

I am currently trying to send the controller precision locations (ploc) but I get an error stating the machine type is incorrect. I am trying to find out if I set the machine type (mc_a465) in the Robcomm3 app or on the controller.

How are you controlling the robot, how are you implenting the RoboDK code?

Thanks for you response.

Cheers

[jpa]

To take it back a step, do you think it is wise to try to control the robot using Cartesian locations of should I be trying to control it by precision locations/encoder pulses?

How are you controlling the robot, how are you implenting the RoboDK code?

I think controlling by cartesian locations should be fine.

So far I haven't actually implemented controlling at all, as I got a bit busy with other projects. But my current plan is to send precision locations (joint angles) from ROS.

[Jani]

Hi. I have problems with f3 teach pendant, it connect for controller but it can't move robot. Does anyone know the right settings for pendant?

[jaws180]

May I have a copy of robcomm