[cocktailyogi]

Sorry, I have written wrong units.

It should be:
calculate_delta() standard: average execution time: 800 µs

calculate_delta(), tuned with Roberts fatan2(), based on lookup tables:
average execution time: 720 µs

[cocktailyogi]

Hi guys,

I did some runtime-comparism of Roberts new math-libs in combination with reverse-transformation-function calculate_delta().

I tested it alone on the Arduio Mega 2560 und ideal circumstances and measured the execution time.

calculate_delta() standard: average execution time: 800 ms

calculate_delta(), tuned with Roberts fatan2(), based on lookup tables:
average execution time: 720 ms

It does not save much time. Maybe solving the transformation in integer-maths coul help.

Kind Regards,
Yogi

[cocktailyogi]

Hi Robert,

I can see your point and I think I also made my point clear. More dicussion on this does not make sense to me. We are talking about two complety different user concepts. The crowd will decide in the next few years.

Let us ste back to your Idea. Why GCODE+? If I got it right, you want to recode the GCODE from the slicing-tool?
Maybe you can get easier, what you want. The GCODE in 3Dprinting was designed for cartesian systems. All slicers do GCODEs in XYZ … the Deltas and SCARAs try to transform it in microcontroller (we have discussed this before already), while the XYZ-Printer yust moves.
Yust make an open-source Slicer like SLIC3R SCARA-compatibel. Add a new Gcode “move theta and/or psi in degree” and add kinematics selection to slicing-tool. The Slicer has to be converted to do the optimised for SCARA. Then the slicer could generate standard-gcode and you will not get bigger files than nowadays with a cartesian printer.

Yogi

[cocktailyogi]

Hi Robert,

nice and interesting discussion. I fully agree with you about Morgan Hardware and design-concepts. But you are wrong, there are other people, which also realised the genius in this concept-design, espeacially the Z-Axis impressed me and motivated me to build one. 😉 hehe

But the weak point here are the nonlinearities and computations. “Weak” means not unsolvable and not worth to do it.
In my opinion the limiting parts of inaccurateness on the Morgan will not be caused by mechanics (it is good!), but it is caused by software.
I have some other projects and ideas also going on. So please forgive me, I do not have the ressources to finish that job completely.

As physicist and product-tester I am always open for new concepts. Regarding your GCODE+ idea I am completely on the other side 🙂 So let us have a good discussion 😉

From my point of view it would be a step back because your are putting printer-specific stuff back to the computer. Sure, you would answer, that the slicing process is also machine-specific. Yes, you are right, for me the PC-based slicing is also only a temporary step in printing-development.

To make my vision clear:
If you look at it from the interface-side, it is always good, to standarise interfaces, and this should never happen machine-specific. GCODE are doing this, unfortunately the slicing process is machine-specific, so this is resulting in machine-specific code. My vision is to put the slicing-process also into the printer. Then you could have only STL-files and send them to the machine. The machine will take care of everything else. This make it possible to eleminate all machine-specific from the interfaces. Unfortunately, this will need MORE performance on an embedded-system.

The ideal target setup would be a small embedded-board. I.e.: Beagleboard. Even better would be a ZYNQ-Processor, which has buildin FPGA-Unit. Then we could have full realtime-capabilities and fast motion-control with very high precision. This stuff is today already available for 50-120$ and prices are dropping. In future our children will receive STL-files per Smarthone and send it via WIFI to the printing unit. This might be in Supermarket or at home.

Are we still on topic? *smile*

What do you think?

Yogi

[cocktailyogi]

I managed to reduce execution-time of the reverse-tranform by factor of 2 (!!!!) only by killing 2 useless divisions.

Execution time went from 700-900µs to 350-400µs. I will patch the fix and another bugfix into my github-tree later.

It seems, I opened beerbottle too early. Code was patched to death…. forgot a typecast. Now it only saves 10µs… Sorry for that!

[cocktailyogi]

Hi Robert,

crasy idea, sounds possible. But we are getting off-topic. Forgive me, my short-term goal is to get my printer ready to print parts for my next printer 🙂

I managed to reduce execution-time of the reverse-tranform by factor of 2 (!!!!) only by killing 2 useless divisions.

Execution time went from 700-900µs to 350-400µs. I will patch the fix and another bugfix into my github-tree later.

At the moment I am plying with your maths-lib, but my Arduino-toolkit alwas complains about “… not declared in this scope”. I cannot find any missing include. You should not forget to give oscarliang some credits in your lib. There is some copy-paste 😉

Yogi

[cocktailyogi]

Hi Robert,

respect, your business travel seems to be less interesting 😉 🙂 hehe

Thanks for your great work. I will start testing with it now and report later.

I have thought about your gcode-postprocessor idea. One technical problem would be communication-speed. 250000baud will not be enough to transfer data in realtime and avoid buffer underrun. We also should keep in mind, that there are two ways to optimize performance: Software-optimization or better CPU. Also code-readability is important and some optimisation-paths reduce this. Actually the Marlin-team seems to prefer better hardware on the roadmap.

If we compare costs of a 32bit ~100Mhz Board (i.e. Arduino DUE/Ramps-FD or Smoothieboard) it is not more expensive than a RAMPS/MEGA-Kit. So we should keep thi soption in mind.

But software-improovement is interesting and makes fun, we also can learn a lot. So lets tune it a little bit:

I did some research, what thinks cost most performane on Atmel 8bit-CPUs:

– floating point maths
(could be worth to move to fixed point, but also much work. Marlin-team seems to keep floating-point and move to faster hardware in future. Maybe we should onl move to FixPoint in reverse-Transform?)
– Division-maths a=b/c
(We have lots of divisions, I will see, what I can do.)
– trigonometric operations
(Robert is already on it.)

Specially we have a combination of all 3….

I found some libs, which may be useful, Robert. Maybe it saves you some work?
fixed-point-libs
http://sourceforge.net/projects/avrfix/

Trignometric-lookuptable and maths:
http://blog.oscarliang.net/enhanced-arduino-c-custom-math-library/

Kind Regards,
Yogi

[cocktailyogi]

hi again,

I found the reason for my compile-error: I did not knoe, that “avr/pgmspace.h” must be included. Now PROGMEM is operational.

By using optimized fsqrt(), execution time only reduced some µs, but is still in the area of 0.75-0.9ms .

The interesting part would be to optimise atan2() and pow(x,2).

Yogi

[cocktailyogi]

Hi Robert,

interesting concept nd impressive work, you have done there. Where are you living in Germany? I am german, as well.

At the moment I am not sure, if these optimizations will bring us into to the nessecary performance range with that small CPU, but I decided to do some measurements. I am testing the function calculate_delta() standalone on the hardware. My first results showed, that it needs 750-906µs to execute (from my SCARA-fork). This is far too slow, because we need to do it at least 200 times per second. This, means ca. 20% execution time only for maths-transform. Not much reliable time left for the planner and motion-control.

I wanted to test it also with your new-mathematics, but unfortunately, I am unable to compile it. On Arduino 1.5.6 beta it gives me “expected initialzer before PROGMEM”-error.

Another point to discuss:
We should use more than 900 values for the sine-tables, because this leads roughly to a position accuracy of 0.22-0.25mm. Could be better.

Yogi

[cocktailyogi]

Hi,

I think, getting the math fast enough is not possible on the 8bit CPU. A CPU with floating-point support or lots of MHZ would be nice.

The Smoothyboard has good specs, if I would have known before…. The price is also good. The onboard drivers also seem to be perfect. Good luck.

During the meantime I will build a XXL-Delta-printer. Maybe I will finish my Morgan with stronger CPU one day.

Have a good time,
Yogi

[cocktailyogi]

Okay,

found my extruder problem…. It was a broken wire to one coil…..

[cocktailyogi]

You are welcome. In August we couls have a cold beer on that sucess.

I have removed the M370 commands. Autolvelling is now in Marlin.
Arc support is still missing.

But I found another issue. My Extruder Stepper stooped working now. I am not sure, if it is firmware-related. It changed direction very quickly in one move. ?!?
Current is set properly.

Maybe you could test firmware on your printer.
Yust copy SCARA-config-files from example folder to main-dir and enter your feedrates.

Yogi

[cocktailyogi]

DONE! :-)))

It works!

I found the bug and now I have a Reprap Morgan with actual Marlin and Z-Min-Endstop.

The bug was a stupid “&&” instead of “||” in prepare_move(). Took me two days to figure out my mistake.

I did a pull-request in Github. Mybe they will pull it into masterbranch.
Here is the repo:
https://github.com/cocktailyogi/Marlin/tree/SCARA_by_Yogi

Enjoy!
Yogi

[cocktailyogi]

Hi Quentin,
I am still tracking down my firmware-problem. Maybe you could look at my response on M114 and tell me, if you see anything unusual?

In Home-Position after homing it brings:

X:-30.00 Y:-55.00 Z:0.10 E:0.00 Count X: 115.23 Y:243.88 Z:0.10
SCARA Theta:115.24   Psi+Theta:243.88
SCARA Cal - Theta:115.24   Psi+Theta (90):38.64
SCARA step Cal - Theta:109.61   Psi+Theta:122.35

After “G1 X0 Y0 F1000” it moves over the bed and then stops outside bed….:

X:0.00 Y:0.00 Z:0.10 E:0.00 Count X: 0.00 Y:0.00 Z:0.10
SCARA Theta:83.21   Psi+Theta:218.29
SCARA Cal - Theta:83.21   Psi+Theta (90):45.08
SCARA step Cal - Theta:79.14   Psi+Theta:128.48

“G1 X100 Y100” makes a move in 3 different directions and then stops on the front right corner…

X:100.00 Y:100.00 Z:0.10 E:0.00 Count X: 100.00 Y:100.00 Z:0.10
SCARA Theta:31.33   Psi+Theta:148.67
SCARA Cal - Theta:31.33   Psi+Theta (90):27.34
SCARA step Cal - Theta:29.80   Psi+Theta:111.60

I have no idea, what is going on….

[cocktailyogi]

Hi Quentin,

thanks for your answer. You were right. It could be soved like you mentioned. But I read your answer later….. Now I swoped my arms. It was no so much effort.
Unfortunately, I still have a problem with kinematics.

I implemented your kinematic-functions into Marlin-Masterbranch. The forward and reverse-transformations are doing well and the results are plausible. But the arms are moving very strange and not like expected, but reproducable. Homing works great. At the moment I am looking for an idea, what is wrong. I did only sligth modifications to your kinematic-functions, so there are no worries. I double-checked the results with your original-functions. It must be something with the motion-control itself.

If you are interested in my repository, please feel to have a look:
https://github.com/cocktailyogi/Marlin/tree/SCARA_by_Yogi

My goal is to merge it into the master branch. To get to that point I reduced public variable usage as much as possible and implemented everything by compiler-switch “#ifdef SCARA”

Kind Regards,
Yogi

[Author]

Posts