I am inspired by your work and wanted to ask if you could help me with.

Theothermike - can you please share foto of printed parts? How precise and how fast SCARyllA can print?

Evil Monkey - how your printer work with this firmware?

Pavlo - can your firmware work on Smoothie board or Duet2 or any other 32 bit boards?]]>

I need to post an update on the single arm Scara when I get time. Not had a lot of time to play with it as much as I would of liked, as it has been a busy year work wise.

That is the problem when you turn your hobby into a business, you end up with less play time trying to keep up with the demand of production products and less on the fun parts.

But it is great going to work and doing what you love each day, instead of working for The Man as such.

With the Scara MK3, I could not find any open source code that was suitable and good enough, so ended up designing our own controller and writing dedicated firmware/software.

The problem with that though is de-bugging and getting it to the stage where you are happy to release it. We made up a few units that are out in the hands of developers and being tested, so more on that design later on down the line.

We looked around for European supplies of the strain wave gearboxes and as usual Harmonic drives seem to be leading the way, but very expensive. We had the UK rep pop in and see us the other day at the workshop, with his case of samples and some really impressive products, but the price is crazy.

We sourced a company outside the UK and even though a long makeup time they produced a gearbox to our spec and it works really well ( I have attached a picture, these are 100:1 and fit nice onto a Nema17 motor). But just ordering in a few for doing prototypes is expensive, with them coming out at $1000 for a pair, but still cheaper than any European supplier.

But if we order in quantity the price does drop a lot and is actually viable to getting a model in production and keeping the price down. This is the way we would like to go in the future so we can produce cost effective machines, but also be able to offer a low cost, yet accurate gearbox to the hobby users for their own designs. I seriously cannot believe someone has not done this so far with the pace that Mechatronics has evolved over the last few years.

The design of the rotating ballnut is looking pretty good this end and a simple case of fixing the ballscrew either end to base plate and top mount so it is static and then setting up a bearing to house the ballnut, combined with a pulley connected to the ballnut and another Nema 17 motor that is mounted in main block. I have sourced suitable, off the shelf bearings and waiting from out supplier to see if they can make the custom ballnuts to suit.

I have allowed 100mm spacing between each arm link to the motors and the block ends up being about 170mm wide and 110mm high with all motors and gearboxes contained within. So now you just need to add the static ballscrew/Thread and a couple of linear rails. This makes life easy to extend the height to suit your needs. Just swap out the ballthread and longer rails.

So all good fun as usual

Cheers

Sean]]>

thank you! Documentation here in the forum is also a giant help for myself.

Pavlo has really done great work, I already thought about asking him about ABL and multiple extruders but I´m not ready yet and do not want to be a stressor... ;-)

Unfortunately I currently have not so much time for it...but it will be better in some time.

Still I have to think about the laser mount. I would like to implement at least a small manual height adaption...

It will come and I will post it here.

Would be very interesting to see more about your design, especially the rotating ballscrew nut. So feel free to share your thread link ! ;-)

I already saw your scaras MK1-3 some months ago, which were also quite inspirating.

Where do you source your harmonic drives?

I also already searched for a more compact, integrated stepper-harmonic drive combination. The coupler arrangement here is one thing I also don´t like so much.

Ideally a HD with an integrated flat stepper would be ideal....but never found and "smart" stepper-gear combinations are a little bit too costly...

Kind regards,

Mike]]>

Really nice work and thanks for sharing.

And thanks Pavlo Gryb for the Marlin-5bar Firmware.

I have had a parallel scara design on the table for a while, but as usual not much play time. But this thread has got me back to the urge of protoyping and making.

Going to try and keep everything in one chunk of metal for the arm drives and also the Z-Axis by trying to add rotating ballscrew nut configuration and holding the ballscrew thread solid in place. This will save a bit of space not having the usual stepper motor and coupler configuration and also no moving bed.

The chunk will contain 2 motors with harmonic drives for the arms and 1 motor to turn the ballscrew nut.

Will start a new thread showing the build as do not want to hijack this one but great stuff and a big help.

Cheers

Sean.]]>

He made it accept g2/g3 commands, so path trajectories exported from inkscape, CAMBAM, etc. should work now!!

[www.youtube.com]]]>

Quote

**theothermike**

The mathematical base zero coordinates (x=0, y=0) without offset sits in between the two shoulder joints ?

Yes.]]>The mathematical base zero coordinates (x=0, y=0) without offset sits in between the two shoulder joints ?

[attachment 59409 Configuration.h]]]>

It´s quite logical !! I had to mechanically change from x_max, y_max, z_max to the corresponding min pins.

Great stuff !

One further thing regarding the calculation of the offsets:

The mathematical base zero coordinates (x=0, y=0) without offset sits in between the two shoulder joints ?]]>

comment line with - #define DISABLE_XYMAX_ENDSTOPS to enable xy max

Again in my setup i used min endstoppers for homing.]]>

Edit: OK, I see in Marlin_main the parity is changed with it...

I setted:

#define INVERT_X_DIR false // for Mendel set to false, for Orca set to true #define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false and #define X_HOME_DIR -1 #define Y_HOME_DIR -1

But now the xy_max endstops are not effective any more..!

Using "M119" they definitely get triggered, but machine moves on!]]>

#define INVERT_X_DIR false // for Mendel set to false, for Orca set to true #define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false and #define X_HOME_DIR -1 #define Y_HOME_DIR -1

Added:

Also you may change (i've updated git hub firmware - now it is in configuration.h)

#define FBSIGN -1 // for 5 bar only]]>

Proof

Just modify values as you want

#define Linkage_1 70

#define Linkage_2 80

#define FiveBarAxesDist 0 // the distance beetween axes.

Plus extra math for mount bar controlled by:

#define EndPointMountOffset 18

#define EndPointMountAngle 50

Visualizer]]>

[www.youtube.com]

The rest depends on where you set your bed zero coordinates, but they are reached in a linear, understandable manner.

Nevertheless, firmware still lacks g2/g3 codes ! :-((

I tested un-uncommenting the g2/g3 routines, but that gives movements out of bound.......

So, if anybody has an idea how to implement g2-movements, please let me know ! :-)]]>

Of course, there were some more issues in my forward calculation program routine. But I was able to debug them using a different procedure.

I defined much more variables than initially needed, calculated each small term and printed them out using the serial-out.

Then I compared the values with the excel sheet and was able to correct each term separately.

But now homing works, software endstops work, jogging is fine, gcode acceptance at least seems to be fine.

This brings me to the next level and to do´s :

- Manufacture last aluminum parts.

- Fabricate Laser driver & holder.

- Clean up my firmware modification.

- House and mount the Arduino+Ramps.

- Readjust y-motors magnet holder (endstop position still lies in xy-workspace which is not good when hitting "homing" again).

- Write simple Arduino adjustment program & fabricate corresponding positioning device. I want to make a spacer which defines exact parallel arm positions. From there, jogging and counting steps until endstop triggers. Using the excel calculation the precise angles can then be defined.

With this it´s only a matter of time to enforce & unleash SCARyllAs indisputable power ;-))]]>

On the right side, the argument in the epsilon term must be divided by "e".]]>

With this I can calculate the arm coordinates to be approx. x=-73 and y=105.4

I have to correct the inverse calculation. When calculating Epsilon, it must be divided by e, not c....

Photo will be posted asap.]]>

[attachment 59079 IMG_0119r.jpg]

Distance between Clamp and HES-box surface is 0.5mm:

[attachment 59080 IMG_0120r.jpg]

Best of all: Endstop switches are working ! :-)) x-motor port of Ramps-shield is right shoulder joint, y-motor port is left shoulder joint. Switches are connected to x-max pins.

Proof is here:

[youtu.be]

And that´s the arm position after homing:

[attachment 59081 IMG_0125r.jpg]

Roughly measured, the real angles after homing are:

Theta (beta within my drawing): 113°

Psi (alpha within my drawing): 192°

which roughly corresponds to following coordinates:

x: -105 mm

y: +105 mm

OK, so far, I tried to modify the FW...unfortunately with no success.

I refer to this one: Marlin-armlevel

Within "Marlin_main.cpp" I switched Quentin Harleys with my inverse kinematics:

//++++++++++++++++++++Inverse Theothermike Begin +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // /* SCARA_C2 = (pow(SCARA_pos[X_AXIS],2)+pow(SCARA_pos[Y_AXIS],2)-pow(Linkage_2/1000,2)+pow(Linkage_1/1000,2)) / (2 * pow(Linkage_1/1000,2)*sqrt(pow(SCARA_pos[X_AXIS],2)+pow(SCARA_pos[Y_AXIS],2))); //checked SCARA_S2 = pow(85.0-SCARA_pos[X_AXIS],2)+pow(SCARA_pos[Y_AXIS],2); // pow(85.0-SCARA_pos[X_AXIS],2)+pow(SCARA_pos[Y_AXIS],2); SCARA_K1 = Linkage_1/1000-Linkage_2/1000; SCARA_K2 = 2*Linkage_2/1000*sqrt(pow(SCARA_pos[X_AXIS],2)+pow(SCARA_pos[Y_AXIS],2)); SCARA_K3 = (SCARA_S2+SCARA_K1)/(SCARA_K2); // (SCARA_S2+SCARA_K1)/(SCARA_K2); SCARA_theta =(atan2(85.0 - SCARA_pos[X_AXIS],SCARA_pos[Y_AXIS])+3.1415927/2.0-(SCARA_K3)-pow(SCARA_K3,3)/6.0-3.0/40.0*pow(SCARA_K3,5)-5.0/112.0*pow(SCARA_K3,7)-35.0/1152.0*pow(SCARA_K3,9)-63.0/2816.0*pow(SCARA_K3,11)-231.0/13312.0*pow(SCARA_K3,13)-143.0/10240.0*pow(SCARA_K3,15)-6435.0/557056.0*pow(SCARA_K3,17)); //atan2(85.0 - SCARA_pos[X_AXIS],SCARA_pos[Y_AXIS])+acos((SCARA_S2+SCARA_K1)/(SCARA_K2)); //(atan2(85.0 - SCARA_pos[X_AXIS],SCARA_pos[Y_AXIS]) + acos((SCARA_S2+SCARA_K1)/(SCARA_K2))); SCARA_psi = atan2(SCARA_pos[X_AXIS],SCARA_pos[Y_AXIS])+3.1415927/2.0-(SCARA_C2)-pow(SCARA_C2,3)/6.0-3.0/40.0*pow(SCARA_C2,5)-5.0/112.0*pow(SCARA_C2,7)-35.0/1152.0*pow(SCARA_C2,9)-63.0/2816.0*pow(SCARA_C2,11)-231.0/13312.0*pow(SCARA_C2,13)-143.0/10240.0*pow(SCARA_C2,15)-6435.0/557056.0*pow(SCARA_C2,17); //acos(SCARA_C2)+atan2(SCARA_pos[X_AXIS],SCARA_pos[Y_AXIS]); delta[X_AXIS] = 180 - SCARA_theta * SCARA_RAD2DEG; // Multiply by 180/Pi - theta is support arm angle delta[Y_AXIS] = SCARA_psi * SCARA_RAD2DEG; // - equal to sub arm angle (inverted motor) // */ //++++++++++++++++++++Inverse Theothermike End +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Somehow, the FW has problems to calculate the inverse cosine function acos(). I spent hours and suddenly it was clear...therefore I approximated the acos() using its Taylor expansion at x=0.

At least it somehow calculates some values and jogging is possible.

Afterwards, the forward calculation was added in "Marlin_main.cpp":

//################## Theothermikes Calculation for SCARyllA Begin.################################################################################################# // Perform forward kinematics, and place results in delta[0] // /* float y1, y2, x1, x2, df0, df1, df2, df3; y1 = sin(f_delta[Y_AXIS]/SCARA_RAD2DEG) * Linkage_1 / 1000; y2 = sin(f_delta[X_AXIS]/SCARA_RAD2DEG) * Linkage_1 / 1000; x1 = cos(f_delta[Y_AXIS]/SCARA_RAD2DEG) * Linkage_1 / 1000; x2 = 85.0 + cos(f_delta[X_AXIS]/SCARA_RAD2DEG) * Linkage_1 / 1000; df0 = (sqrt(pow(df1,2) + pow(df2,2)))/(2 * Linkage_2/1000); df1 = (x2 - x1); df2 = (y2 - y1); df3 = atan2(df2 , df1) + 3.1415927/2.0-(df0)-pow(df0,3)/6.0-3.0/40.0*pow(df0,5)-5.0/112.0*pow(df0,7)-35.0/1152.0*pow(df0,9)-63.0/2816.0*pow(df0,11)-231.0/13312.0*pow(df0,13)-143.0/10240.0*pow(df0,15)-6435.0/557056.0*pow(df0,17); delta[X_AXIS] = x1 + Linkage_2/1000 * cos(df3) + SCARA_offset_x; delta[Y_AXIS] = y1 + Linkage_2/1000 * sin(df3) + SCARA_offset_y; // */ //################## Theothermikes Calculation for SCARyllA END.#################################################################################################Again, acos() was not working --> Same Taylor expansion.

Within "Configuration.h" settings using the measured coordinates after homing are:

// Manual homing switch locations: // For deltabots this means top and center of the cartesian print volume. // Scara: x centered, y 0 #define MANUAL_X_HOME_POS -105.0 #define MANUAL_Y_HOME_POS 105.0 #define MANUAL_Z_HOME_POS 210 // Distance between nozzle and print surface after homing.

Offsets equal zero, so that the "real" coordinates and angles should be given:

// SCARA tower offset (position of Tower relative to bed zero position) // This needs to be reasonably accurate as it defines the printbed position in the SCARA space. #define SCARA_offset_x 0.0 //mm #define SCARA_offset_y 0.0 //mm

Steps per rev. settings are:

// default settings #define DEFAULT_AXIS_STEPS_PER_UNIT {711, 711, 100, 450} #define DEFAULT_MAX_FEEDRATE {300, 300, 300, 45} // (mm/sec) #define DEFAULT_MAX_ACCELERATION {400, 400, 400, 8000} // X, Y, Z, E maximum start speed for accelerated moves.Currently the gear ratio is 1:80, motors exhibit 200 steps/rev and driver is set to 16x microstepping, yielding in a total of 256000 steps/rev = 711.111 steps/deg.

So far, so good. I think mechanical and electrical system is running as it should, but FW is still faulty.

I still do not understand how homing is working.

After homing, by submitting M114 to the device, the x,y-coordinates do not equal the setted home position and the angles are completely wrong.

After endswitch triggering, does the FW take the setted home coordinates and calculates the corresponding angles?

Perhaps I still have an error within the calculations or something during code execution goes wrong?

Do I need to swap motors?

In Quentin Harleys version, he multiplies Theta inside the IK by (-1). Why that? Have I missed some inverted motor direction?

However, when using the unmodified FW, it somehow correspond correct ( jogging +x --> movement -x, angles and home coordinates not too far away,..)

I will check calculation using an excel script or so...Really weird the Marlin-armlevel-FW....]]>

Could be helpfull to check :)]]>

So I decided to design and manufacture a corresponding HES-box (material is black POM):

[attachment 57645 POM-HES_Box.JPG]

The HES´s will be glued into the box to give a sturdy finish.

It will be set into the middle beteen the two gears:

[attachment 57646 NeuerHallHalter2.JPG]

Next step will be a small redesign of the magnet holder clamps...

I want to use two 3x6mm NdFeB-magnet rods (N45). Lateral distance between them seems to be OK from the breadboard tests...]]>

Looks weird (quite nested) and I´m sorry it´s not written very clearly, but it was a first try.]]>