[RobertKuhlmann]

I guess not stepping was the fault, but the amperage your drivers give to the steppers (you loose steps if the current is too low or even too high). You’ll find several guides to calibrate the drivers throughout the internet.

[RobertKuhlmann]

I’m still not very happy with the precision of my Morgan. Using the drive-belt-clips already and having the motors mounted perfectly on the base, there are still wobbles along some printed routes. I’ll have to rework the pole I think and check the screws and bearings of the arms.

Update from the bed-front:
I’m using an 18A-variant (216 Watt at 12V) of my heated bed (driven with Traumflug’s SevenSwitch of course) at 130°C. Works very good. I just have to be careful not to pull up the prints to early. The bed has to cool down after printing, because otherwise the Kapton can stick to the print, because at 130°C the Kapton-adhesive looses its strength (getting it back after colling down).

[RobertKuhlmann]

Hi Whiskey,

the Kapton is safe up to 350°C. I use hairspray on Kapton as an abherant, because the ABS sticks to the Kapton surface very good – sometimes too good. Driving the heated bed with 120°C turns out to be a good choice for ABS, reducing warping (I’m using SevenSwitch for that, using a self constructed 12V/13A bed (look at RepRap-Wiki: http://www.reprap.org/wiki/Robert%27s_Heated_Bed).

I’ve modified my Morgan for more precision (the first prints weren’t very precise though). I’m using the clamps for the belt now an have fixed my X-and Y-axis steppers solid to the platform (using stuff I had around here instead of new self printed motor mounts, that weren’t usable at all).

Important thing was to fill in the gap between threaded rods and bearings: So I finally found out what the “tightening kone” was intended for. But I’m using standard thread sealing PTFE string for that purpose.

And I’m a real fan of Quentin’s SDS-drill-Z-axis drive. The drills aren’t very cheap here, but app. 7€/pcs. is acceptable and it’s so nice to have a fast Y-axis that works with very good precision as well.

I didn’t use the motor-mounts I was printing in the video, because I didn’t have M3 x 50mm at hand and the print stopped before the higher mount was finished. But I’ve replaced their function by some metal struttigs, reducing their backlash to a (non visual) minimum.

I will try to give Teacup a Morgan-extension now.

[RobertKuhlmann]

After crashing my electronics with my heated bed I decided to use Traumflug’s SevenSwitch to power my 13A heated bed (6 Min from 21°C to 110°C) and it works like charm.
My heated bed, covered with Kapton and prepared with hairspray and powered to 110°C gives the best results untilnow.

I modified Marlin to output the calibration data with more precision (8 digits, instead of 2). But on the long run I’ll use Teacup as firmware, rather than Marlin. Have to transfer the Scara calculations to Teacup for that.

But first I’ll have to print new Morgan parts (as Quentin proposed) to get even better print results.

[RobertKuhlmann]

Sounds and looks good. And a competitive price from start (with only relatively small amounts built, I guess). Promising…

With 120MHz speed seems to be no problem.;)

[RobertKuhlmann]

Impressive. So where can I find Smoothie?

[RobertKuhlmann]

Hi Quentin,

I’m in on it. In a few minutes I’ll begin some test-prints. Of course I was busy until now (had to help my father with a computer-problem). It seems something always wants to keep me from printing. 😉

Some results on the new math-library so far?

[RobertKuhlmann]

Morgan need to be a machine for all, and printing straight out of software like Cura would be a mandatory feature for a commercial ready system. Not a toy for makers. A tool for people with ideas, regardless of their backgrounds.

I agree with that too. That would mean to my approach to integrate the preprocessor into e.g Cura. First it has to and will be an external tool, but integrating it into the printing-process should be no problem as long as we talk about Open Source projects like Cura.

You will excuse me if I remain positive about my project 😉

Of course not. 😉

By the way: The “Forschungszentrum Juelich” (a scientific institute) will build several Morgans by some of their trainees. They will, if they do as I asked them, put them on the Morgan-world-map, as soon as they have finished the builds.
I support them with infos and links.

Hey. Weekend. Time to start a print on my Morgan – finally. 😉

[RobertKuhlmann]

Hi Yogi,

that would bind the user to that specific slicer or one that is “scara-compatible”, while a post-/pre-processor would be independent from the slicer as well as the actual Marlin-firmware version, as long as it contains the low scara-low-level commands.

But what I like the most: Any Morgan-owner would benefit from GCODE+ without any modification or invest. Just update your Marlin-firmware and use the preprocessor for your GCode-files before printing.

And, yes, it’s not about one concept being superior over another, but different aspects of how to look at specific problems with 3D-printing.

[RobertKuhlmann]

Hi Yogi,
(sorry for answering that late, but there was no internet on my train back, yesterday).

I’m not with you, when you argue to integrate more computations into the printer-electronics.
Your own PC can easily and with best accuracy calculate the printer commands for many files and several printers (if you own more than one) and still is good enough for its normal PC-tasks.

But the printers already out there have a weak micro-controller with a spit of memory, running on frequencies my armclock would be ashamed of.

You’re right: Accuracy is a matter of software, prior to mechanics. Of course the basic concept of a printer limits its abilities, but with good parts and good work the physical basis can be brought to a very good accuracy. What we can do with software, on the other hand, shouldn’t be limited by the investment into the printer.
I’d far more like to build several Morgans with, let’s say, 60$ electronics, where I have to precalculate the printjobs om my notebook first, than to build them with e.g. 100$ electronics, just to let them do a task my notebook would still outperform by any measure.

Your argument about standards and interfaces is okay. But even GCODE+ would be a standardized interface, only the content would be machine specific, what is, as you’ve stated yourself, the case even in GCODE today. Even in GCODE you have to specify the nozzle-width, the print-material a.s.o.

My point is to move some specific tasks of the printing process onto a platform that it’s far more suitable for and leave the (mathematically) simple part work to the micro-controller.

Your vision of sending the STL-files to “the machine” is okay. If I built a printer farm, I would invest into one PC that manages all print jobs, precalculates them and delivers the results to the several micro-controllers.
I’d call it the thin-client approach, transformed to the 3D-printer-level. Whereas your fat-printer-client would be interesting, if you need only one single printer, and even then you’d still have you PC for other tasks and just not use it for 3D-print-jobs.

I’ll transfer the caculations to a seperate for my PC and publish the results in a few days (it’s not a very complicated task though). And it will be using the most accurate floating point datatypes available on my platform to get the most accurate results. After the concept is proofen in praxis I’ll try to realize it with a special math library that allows (almost) unlimited accuracy.

I can’t follow your point of smart boards being cheap and still keep going down in price. More COU-power and more memory always costs more ressources. And sophisticated printer-electronics are not available everywhere. But especially availability is that central important point with RepRap. Everybody everywhere should be able to build one. And therefor the count and the level of complexity of the required parts should be as low as possible. That’s what makes my concept of outsourcing maths from the micro-controller fit better into the philosophy of RepRap. I think. 🙂

[RobertKuhlmann]

You won’t believe that:
They charge 5€/hour for internet in my hotel! They are crazy! I went to my favorite restaurant in cologne and I am online here for free (have a Telekom hotspot flatrate though).

@Yogi: I know that feeling soooooo well. 😉
But that’s okay. When measuring performance always keep in mind, that the compiler may optimize.

The printer that primarily has to print for me is under construction in parallel (a RepRapPro Mendel, but not bought from them). But Morgan is where my heart beats. I loved the concept from start. Okay, I forgot to print something with it until today, but after seeing the first calibration patterns scratched into my aluminum building platform in best accuracy (my hotend didn’t work that day), I was sure being on the right track to contribute to Quentin’s idea.

I had Oscar Liang in the code-comments but removed him, because he isn’t the original source of this idea, just published and documented it. I thank him for doing so, nevertheless.
By the way: Where did you see copy&paste from Oscar? There’s nothing left, but I admit, he pointed to the right direction.

I’ve updated GitHub. Marlin.h was missing. I think you’ll have to merge my files with yours to get a working Marlin.

I’m using WinMerge for that: http://winmerge.org/
Really good tool to compare and merge files and hole directory-trees.

And we’re anything but getting off-topic. 😉 (topic is “Scara kinematics and CPU-performance”) Nobody is more ontopic, than we are. 😀

But I can understand that you want quick results. Sometimes I want them too. But then there shows up an interesting problem that waits to be solved and I can’t hold on me any longer, leave my printing plans behind and solve that new problem, that’s blinking and flashing so interesting. 🙂
Since I’ve started to work on software problems in my job again (I paused for several years with that) it’s like a drug again. Thinking new ways and solving problems others didn’t or failed with, is what I like the most. That’s where my sympathy to radical solutions originates.

So lets take a look at 3D-printer electronics on a basic level:
The micro-controller combined with driver shields for external devices as stepper motors, endstops and displays needs information on how exactly to drive these units to get the result we want.
On the other hand every slicer software translates 3D-models into a unified language that describes them layer- and coordinate-oriented. So why should the micro-controller do additional translation work? Something it was never designed for? Lacking of fast memory its main purpose is to drive the external I/Os most effectively and precisely.
Whereas your PC has the capabilities to calculate the behavior of whole planetary systems in parallel, but we only let him transform 3D-models to 2D-command-lists.
I think, let the PC do his job and cut the food for the micro-controller in pieces that fit into its (tiny, memory and CPU-power lacking) world.

Lets take a more detailed look into the problem:
GCODE says: “Do a move from A to B while a certain extruder is active and do this with a certain speed.”
It reads like this “G1 X12.45 Y11.47 F2500”
Our micro-controller remembers the last coordinates where he thinks the printer head should be, and now “the mc” starts to calculate how to reach the given endposition within the shortest way, and how exactly it has to manage the steppers to achieve that?
Why not let the PC “play” this scenario in its gigantic memory with its overwhelming CPU-power and tell the poor, power and memory lacking MC the result of the PC’s finger exercise?

And this for the price of a few extra commands in the Marlin firmware, leaving the rest of it untouched and therefore compatible with existing procedures and software? The longer I think of it, the more i love it.

We only need to transfer the calculation work to the PC and write the results into the GCODE. I’ll definitely work on that for the next days.
Maybe I’ll print something when there’ll be a pause. But lifting Marlin to the next performance level sounds far too interesting to leave it undone.

One final statement why I’m so interested in this topic:
I called a folk in Berlin a few days ago to print me some parts for my Morgan (for the SDS-z-axis andmore). He is a very experienced maker of 3D-printers and delivers excellent print-quality.
When I told him I was working on a Morgan he stated, that he does like the concept but thinks it’s to slow and not competitive in speed and accuracy. I’m totally contrary to his opinion and his criticism on Morgan motivated me to intensify my contribution to make Morgan an overall success.
There are details in Morgan’s design, that make it superior to many other printers, even if most of them weren’t noticed in public until now. E.g. the correlation and dependency between building platform an z-axis. Morgan’s printings are much more immune to Morgan’s frame-movements while the print process than any other printer I’ve seen.
The Psi-Theta-arms and their drive allow extreme precision with simplest materials. You can build this printer with almost no experience, getting a precision you’ll have to invest months for, when building a Prusa or Mendel.
Improvements on Quentins’s design can be done with ease and you can freely decide how much oney or ressources you wnat to invest to improve buildspace or precision.
The concept of Morgan is ingenious. So I’m willing to give my 2 cents to help on its success.

Of course, GCODE+ will improve any existing 3D-printer, not only the Morgan. But hearing Morgan is inferior, just because its mathematics are a bit more complicated than that of other 3D-printer models, is not acceptable.

Sounds like I’ve got a lot of work to do in the next weeks. 😉

[RobertKuhlmann]

Hi Yogi,
I think I have to complete the picture I’ve outlined above.

I think GCODE+ has to be brought to the micro-controller via SD-card, network or similar. Most boards support SD-cards to enable printing independently of a connected PC.
GCODE+ only would be larger, due to containing printer-dependent commands. But these commands wouldn’t need any further calculations, but could be executed directly on the printer hardware (e.g. containing steps/motor, instead of distances or coordinates).
I want to use the existing hardware (even the older models) instead of waiting or paying for upgrades. That saves ressources, not just money.

Lets just unburden the micro-controllers from trigonometry and stuff. They aren’t built for that anyway.

After finishing MATH_SPEED_LEVEL_IV I will try to analyze what has to be done to achieve these goals. I have a strong feeling it may work (usually a good sign).

Another idea I have in my mind is quite similar to yours, regarding fixed point mathematics, instead of floating point. The more radical approach (I like radical approaches, you see? 😉 ) is to only use integer-arithmetic at all. Considered in more detail, the “world” we are thinking about isn’t contingented by rational numbers, but integers. E.g. the building space of any printer has a limited number of points where we can deposit plastic. One layer with e.g. 200mm x 200mm in a resolution of 50 microns effectively has 4000 dot x 4000 dots.
Any connection between two of these dots can be reached by sending a determined amount of step-commands to two stepper motors. In fact nothing we really need trigonometry for. Even arcs in this rastered world are only approximated, where real math would describe them as round.

So instead of struggling with sqrt-COU-cycles we would have replace floating point mathematics with algorithms for a determined raster world. Sounds promising to me.
The drawback of this approach might be the memory required, but that’s only a feeling.

Greetings from the train
(more from my hotel room)
Robert

P.S:: And, yes, the travel is less interesting than Marlin/Morgan/Arduino 😀
Will arrive in Cologne soon…

[RobertKuhlmann]

Lost my mind, though. I took my Arduino with me on my business travel, but forgot to take the USB-cable too. 😮
Brain -> working on Marlin/Morgan -> nothing left for other processes

[RobertKuhlmann]

Hi Quentin,
it seems to be my karma to be the last one to benefit from my work. I made some calibrations and they all worked well. But I still didn’t find the time to start a print. Well, I changed to your SDS-z-axis at last and it works like charm. My hotend is fixed and works, I just don’t find the time for an armlevel-calibration as the last step before printing. But working on the firmware was more interesting, challenging and, last but not least, time consuming. But that’s okay.

GitHub is updated with new versions and additional files:
https://github.com/RobertKuhlmann/Marlin_maths/pulse

Looking at the accuracy-tests, facos does a perfect job. I tested with 5000 entries in the acos table.

fsin() and fcos() could be faster with a more effective parameter-handling. I had to check them for their sign and handle deg values over 360 degrees. I didn’t check that, but do you know or can you figure out if we see deg-values outside the 0360 degree-range? If not we could set fsin(), fcos() and ftan() to “unsafe mode” and skip the parameter handling. That would save a lot of CPU-time.

sqrt and accuracy:
If accuracy of fsqrt is not good enough while an accurate sqrt-replacement isn’t faster, maybe a totally new approach is needed.
And with “totally” I also mean “radically”. E.g.: Why don’t we move all trigonometric and other expensive calculations completely from the microcontroller? It should be possible to write a GCODE-postprocesoor that accepts the fundamental parameters (calibration-results) of a Morgan. It could then precalculate all the planning and motion-control prior to printing, resulting in a big GCODE+-file (as I would call it). C would only have to execute the prepared low-level-commands.
The low-level-commands could be realized as an extension to GCODE.

Didn’t anyone ever thought about such an approach? Or are there any objective arguments not to give this a try? Doesn’t sound too complicated to me.

[RobertKuhlmann]

sq() compared to pow:

 2.1a SQ(float) compared to pow(x,2) 10000 times   sq s;pow s
    0.52300000 s;0.53399996 s

[Author]

Posts