Project: Teacup Firmware

I just need to know if I can somehow control fan. I saw (I think) in some other thread that you sugested control spindle (which is why I´m bothering you with this) with gcode code for fan (on/off), so I would like to explore this possibility. I very appreciate your help and support of your fw. Many thanks

Quote
dronecz
I had page opened half day and few minutes ago decide to write answer, those posts a saw just second I posted my reply.

Thanks for the explanation, glad to read this. I admit I'm a bit over-sensitive against stuff which looks like coming from people who ask in the hope somebody else does their work.

Quote
dronecz
I saw (I think) in some other thread that you sugested control spindle (which is why I´m bothering you with this) with gcode code for fan (on/off), so I would like to explore this possibility.

This gives you plain PWM and, AFAIK, works for DC motors, only. That said, fans are defined just like heaters, but without the temperature sensor: [reprap.org] config.default.h has an example, too. M106 S1 ... M106 S255 to turn the fan on, M106 S0 to turn it off.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Thanks for the explanation, glad to read this. I admit I'm a bit over-sensitive against stuff which looks like coming from people who ask in the hope somebody else does their work.

I donť want somebody do my work, where is fun finding answer in that.

Quote
Traumflug
This gives you plain PWM and, AFAIK, works for DC motors, only. That said, fans are defined just like heaters, but without the temperature sensor: [reprap.org] config.default.h has an example, too. M106 S1 ... M106 S255 to turn the fan on, M106 S0 to turn it off.

Ok, thanks for pointing that out. I thought that a will make Arduino Uno or Adafruit Trinket listen for PWM signal which will come from Gen7 board and make spindle spining. I´m no programmer so this is maybe dead end but I will try to make more search on that.

I looked at your link and that´s what I had in mind in previous post. Connection to Gen7 board I shoul make trough SevenSwitch board to selected pin in config.h or is there other way, or did I understand it wrong.

Once again many thanks for help. I tryed Marlin and Repetier to work with Gen7 board but Teacup have best config file and best examples for me.

Ah, this bitshifting of dda->c poked into my eye again. This time I couldn't resist to get rid of it. Result: 1.2% faster performance, 52 bytes smaller code. On the experimental branch, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hello guys (no girls, I think?),

Traumflug told me of this project and it sounds very promising to me. I will read me in and contribute, if I can.
I'm a german software developer, I'm 48 years old and not very happy with Marlin (need it for my RepRap Morgan though).
I like what I've read so far.

Edited 1 time(s). Last edit at 07/21/2014 05:50PM by RobertKuhlmann.

Today I have the pleasure to congratulate @nikkiverre, which successfully completed Teacup's port to the Teensy3, an ARM Cortex-M4 based controller. Based on David Forrest's work, nikkiverre confirmed success by actually printing:





Best of all, this port is pretty close to previous code, so it should be manageable to get this onto the master branch. For now, it's on the "teensy3.1" branch: [github.com]

Well done!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I've started to implement extensions for scara-printers into the Teacup-Firmware. Thanks to Traumflug for his hints on where to start and to look at.

I'm not very familiar to Github, so I'm not sure if I can start a branch without write-access to the project. So I've published my first results in a seperate Github-project so far: https://github.com/RobertKuhlmann/Teacup_Firmware_Scara
The actual Commit compiles without errors, but is untested.

Approach:
Taking Quentin Harley's modifications of the Marlin firmware for his RepRap Morgan printer as a template, I use the STEPS_PER_M_X/Y constants hold the values for "steps per degree" for the Theta(x)- and Psi(y)-arm. scara.h defines the scara-arm-lengths and the platform-offset (the position of the central scara-axis, iow. the scara-null-point, relative to the printspace-null-point).

The new function "scara_um_to_steps" in dda_maths.c calculates the Theta- and Psi-steps. Scara-calculations require more steps, more memory and more time, compared to calculations for delta-printers. I'll try to replace the current atan2-calls by Cordic-algorithm and see if this saves some CPU-cycles and to get rid of floating point operations - if possible.

There are two places in dda.c where "scara_um_to_steps" is called: "dda_new_startpoint" and "dda_create". In both places the new code is encapsulated by the conditional define SCARA_PRINTER.

SCARA_PRINTER is defined in config_wrapper.h, because I didn't wanted it to interfere with the several config-variants for the controller-hardware, keeping it as global as possible.

All modifications I made can be found by searching for SCARA_PRINTER and in scara.h.
I'm using a modified ThermistorTable.h as well. The project contains an additional file: "ThermistorTable.double.EPCOS_Extruder_B57560G104F_Bed_B5786S0104F.h" that I've copied to ThermistorTable.h (it's my default configuration of thermistors).

TODO:
Calibration needs to be modified too. This will be my next task. Again Quentin Harley's work in the Marlin-firmware is a good startpoint and template for the modifications in Teacup.
I'll try to implement Quentin's calibration commands into Teacup. There are three commands for the arm calibration (M360, M361, M364).
Configurations are not completed for now. So don't use this version on a real printer without completing configurations and tests first!

Comments, contributions and critic is welcome.

Edited 1 time(s). Last edit at 08/16/2014 07:01PM by RobertKuhlmann.

One general question regarding Scara-printers and printer-firmware:

The actual processing interprets GCode-entries e.g. to fill up a buffer with fundamental microcontroller tasks. If the buffer is full, interpretation stops until enough entries in the buffer were processed and deleted. So for simple GCode-Commands the interpretation is ahead of the execution, but for complex commands it can happen that filling up the buffer is slower than the execution, slowing down the print as a consequence.
This can be observed especially with the Marlin firmware on Scara-printers like the RepRap Morgan. More speed would have to be paid with less accuracy and precision. But while every step in a print that consists of commands, that don't depend on sensor-data (like temp.-settings), is predetermined from the moment the GCode is generated and the printer is known.

So in my opinion it would make sense to prepocess the GCode, just prior to send it to the microcontroller, leaving the task of complex operations and calculations to the PC (which outperforms any microcontroller vastly). Besides my efforts to implement scara-logic into Teacup, I'm thinking of writing a preprocessor for GCode-files that converts every G0/G1- and similar command into "micro"-commands that can be transferred into the mc-buffer without further processing.

As the sequence and content of this commands is predicted by the existing GCode on one hand and the printer on the other hand, both of which are known when preprocessing would take place, there would be no further need to give precision a miss in favor to enable a fast print. It would even be possible to leave out some machine-specific code (like my scara-implementation) off the firmware, reducing its size and memory consumption.

I think it's not too complicated to write such a preprocessor and implement a new GCode-command. Without changing the behavior of the firmware at all, except for the ability to handle preprocessed GCode-files. I'm tinking about this for a while now. Teacup is implemented so clean and efficient (esp. compared to Marlin - my serious-minded compliments to all Teacup-contributers) that I'll give it a try in Teacup, since doing this in Marlin would be less fun.

Where to start? The preprocessor can be placed at three positions in the 3D-print-process:
Either:

1. An external program that processes a GCode-file. The processed file can be uploaded to the printer by the user.
2. Integrated into Slic3r the preprocessor could act just before exporting the GCode-file or make a second (preprocessed) file in parallel.
3. The preprocessor could be integrated into the transfer-software, processing every single GCode-command before it is transmitted to the printer.

As solution No. 1 is the one that needs less modification of existing software, it's my preferred approach by now. The preprocessor should read out the required machine parameters from a connected printer (special GCode-command for that) and store them into a local config-file. If the read-command would not be supported by the connected printer, preprocessing wouldn't take place (except using a prepared config-file of course). Sending a preprocessed file to a printer without the enhanced firmware would result in GCode-errors, with no further consequences, except that this will not print.
The next argument for solution No. 1 is, that it leaves it to the user which software he uses for slicing and transmission (including prints from SD-card).

I'll start a new Github-project for that in the next days and keep you informed about the progress. I would also suggest a new Teacup-branch for this (if applicable; can keep it to my own Github as well).

Suggestions, comments and critics welcome.

Quote
RobertKuhlmann
So in my opinion it would make sense to prepocess the GCode, just prior to send it to the microcontroller, leaving the task of complex operations and calculations to the PC

Has been discussed quite a number of times and as you see, host <=> controller communications is still in plain, human-readable ASCII and controllers still fill their movement queue them selfs. :-)

Reasons:

- Binary communications isn't that much faster than ASCII. "X35.678" is 7 bytes, sending the same in binary would be 5 bytes ("X" and four bytes for an integer).

- Controllers were fast enough to move cartesian robots so far.

- Things become very tricky when unexpected things happen.

Approaches I'm aware of:

- RepRap-style acceleration. There, the F keyword means "feedrate at the end of the movement". Feedrate at movement start is given by the previous line. You basically send one line of G-code for the acceleration ramp, one for the constant speed part and one for deceleration. Not too bad, because when keeping feedrate over several movements, this requires only one additional line per additional movement. This allows to do all look-ahead calculations on the host PC. Teacup should support RepRap-style acceleration, see ACCELERATION_REPRAP in config.h. May be bit-rotten, though, because very rarely tried.

Approaches I can think of, not seen tried so far:

- Preprocess at least scara => karthesian conversation, letting the controller think it moves an karthesian bot. Not sure how much computing work this saves, though.

- Send a readily filled DDA structure over the serial line. All the time consuming stuff when receiving movements is feedrate => timer delay calculations, lookahead, micrometers => steps conversion, and the result of all this is put into a DDA structure (severyl of which make up the movement queue). A filled DDA is some 70 bytes, though, so you loose some time at communications.

- Get rid of these hundreds of tiny segments in favour of Bezier (curved) movements. With Beziers you can approximate a geometry some 8 to 10 times more accurate at the same data size. Keeping accuracy, this means 10 times fewer movement commands accordingly 10 times fewer lookahead calculations.

- Actually measuring performance of this preprocessing stuff. Not yet done, AFAIK, making any plan to improve it pretty much a speculation :-)


All this said, any code actually written for trying is much much better than many many pages of just wishing loudly, of course. I found your new code already, looks good!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
...
Has been discussed quite a number of times and as you see, host <=> controller communications is still in plain, human-readable ASCII and controllers still fill their movement queue them selfs. :-)

Reasons:

- Binary communications isn't that much faster than ASCII. "X35.678" is 7 bytes, sending the same in binary would be 5 bytes ("X" and four bytes for an integer).

Don't get me wrong. I don't want to change to binary communication or even change the syntax of GCode. I just want to place custom GCode-commands into the file.

Quote
Traumflug
- Controllers were fast enough to move cartesian robots so far.

- Things become very tricky when unexpected things happen.

I think Quentin's approach with the Morgan has a big potential and it saves resources. Weak microcontrollers will always be easier to buy and cheaper than state-of-the-art hardware. So I prefer to use "old fashioned" but robust and cheap microcontrollers, instead of waiting for new hardware to become affordable.
Guess you mean Quentin's invention to be one of the "unexpected things" that happened?

Quote
Traumflug
...
Approaches I can think of, not seen tried so far:

- Preprocess at least scara => karthesian conversation, letting the controller think it moves an karthesian bot. Not sure how much computing work this saves, though.

That's exactly what I want to do.

Quote
Traumflug
- Send a readily filled DDA structure over the serial line. All the time consuming stuff when receiving movements is feedrate => timer delay calculations, lookahead, micrometers => steps conversion, and the result of all this is put into a DDA structure (severyl of which make up the movement queue). A filled DDA is some 70 bytes, though, so you loose some time at communications.

I agree. And it would contradict my very own approach to save resources, if I'd think of a solution that requires "modern" hardware just to be fast enough for more communication.
(printing from an SD-Card is a different issue here; let's talk about that later)

Quote
Traumflug
- Get rid of these hundreds of tiny segments in favour of Bezier (curved) movements. With Beziers you can approximate a geometry some 8 to 10 times more accurate at the same data size. Keeping accuracy, this means 10 times fewer movement commands accordingly 10 times fewer lookahead calculations.

I strongly agree. I'm quite old and can remember the time, when character sets of operating systems began to use Bezier-curves to enable scalable characters for high-resolution monitors (I think GEM from Digital Research was the first to support that). M$ Windows needed years to catch up with this development and needed a third party software: from Adobe.
But no one seems to think or work in that direction for 3D-printing. Too bad. Maybe I will give it a try, after finishing scara-calibration and GCode-plus (GCode plus Scara-movement commands). Many algorithms to handle Bezier-curves are published under GPL. Acquiring the knowledge needed should be no fundamental problem though.

Quote
Traumflug
- Actually measuring performance of this preprocessing stuff. Not yet done, AFAIK, making any plan to improve it pretty much a speculation :-)

I thought this as part of my work on improvements. Wouldn't make any sense to improve something without measuring the results.
I've done this for Marlin already to verify my new Marlin-math-library (for RepRap Morgan of course) to improve speed. But the result wasn't promising enough to invest more work on that.
The progress without parameter-checking was very good (up to three times faster calculation of scara-coordinates on an Arduino Mega), but the checks (you seriously can't do it without them) reduced the advantage to app. 20%. Not worthy to invest so much memory (for precalculated tables) for this little reward. losing some accuracy as well.

Quote
Traumflug
All this said, any code actually written for trying is much much better than many many pages of just wishing loudly, of course. I found your new code already, looks good!

Thanks. It's a pleasure. As you've noticed already I'm not only talking, but really work on things (those I'm able to work on of course).
Having said this: My first Gen7-board is almost ready (forgot to order the 12MHz-Quartz). To support mounting it's a good idea to toner-transfer the silk- and the components-layer on the top side of the PCB (after etching of course).

Edited 3 time(s). Last edit at 08/19/2014 07:02AM by RobertKuhlmann.

Good Evening,

I found this thread while searching for SCARA...so it seems "Teacup" is currently modified for SCARA robots by Mr. Kuhlmann (Guten Abend! :-) )!?
Well, this is great and very interesting!
Still I´m very new to all this 3d-printing stuff and perhaps I didn´t get it directly, so please excuse if my question is too obvious for you, but:

What type of SCARA geometry will be implemented??

As far as I tried recherching this forum, there are several different approaches:
1. "One-arm" SCARA where the motor for the lower arm sits on the upper arm, just like the heliumfrog scara: [www.heliumfrog.com]
2. One-arm SCARA, where both motors sit in the base, and rotation of the lower arm has to be compensated with respect to case 1.
3. Parallel-arm SCARA where the motors are spatially separated, just like this one: [forums.reprap.org]
4. Parallel-arm SCARA where the motors are coaxial, like the Morgan: [reprap.org]

I really would like to built a SCARA type machine, but for understanding and modifying the controlling softwares code I do not have enough brain juice....so I think it would be very, very helpful to clarify which mechanical geometries can be driven with which software approach!

Best regards
Mike

@RobertKuhlmann has a Morgan, so that's likely what he implements.

Looking at the code changes so far it much looks like the other three types aren't too complicated. I'm a bit (positively) surprised how simple this apparently is. Just implement um_to_steps() and steps_to_um() for your mechanics and you're ready to go.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ah, OK....Morgan style....

@Robert: Wouldn´t it be useful to directly implement the kinematics for the (3.) Parallel-arm SCARA where the motors are spatially separated ?
When setting the motor displacement to "zero" the coaxial geometry (4.) would be resumed....and one software could serve two different SCARA types.

Quote
theothermike
Ah, OK....Morgan style....

@Robert: Wouldn´t it be useful to directly implement the kinematics for the (3.) Parallel-arm SCARA where the motors are spatially separated ?
When setting the motor displacement to "zero" the coaxial geometry (4.) would be resumed....and one software could serve two different SCARA types.

Let's see. In general the mathematics for all four variants should be very similar.
Quentin Harley only implemented case no. 4 in Marlin and I primarily focused on that too, of course (and this look very similar to no. 2, when it comes to mathematics).

I don't n know scara-type RepRap printers except the Morgan today. But I'll have a look at your links and take them into account. It should be possible to cover them all with just a few additional constants/conditionals.

And thank you very much for reminding us this "scara-specific-aspect".

Quote
theothermike
Wouldn´t it be useful to directly implement the kinematics for the (3.) Parallel-arm SCARA where the motors are spatially separated ?

Well, do that. If you want write access to the Teacup repo, drop me a line. Robert is kind enough to push his work right there.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@RobertKuhlmann. I just stumbled across this thread. I'm building the SCARA printer located in the Polar printer sub forum. Its up and printing using the Marlin fork created by tssalo, but it is an older version of Marlin. Would it be difficult to add an auto bed leveling feature to Teacup along with this proposed SCARA feature? It would simplify alot of things.

Auto-bed-levelling is easy to implement, as you can see in Quentin Harley's Marlin-armlevel-branch.
But even the Marlin-version Quentin's work is based upon is outdated. I've tried to merge it with the up-to-date original Marlin-branch, but could not get it to work in acceptable time. That also was the time when I began to read about Teacup and to take a deeper look into the Teacup-sources.

Teacup-source compared to Marlin is better organized, well documented, more clearly structured, better managed and it benefits from its (obviously) good qualified contributors. It may not be as "cool" as Marlin; does not include every brand new feature that pops up somewhere in a forum. But what is in Teacup-master-branch seems to be stable, well implemented, tested and you can rely on it (and if not it's commented in the source/config to warn you).

What I've observed in Marlin, when arm-levelling (the misleading name for the bed-levelling used in Marlin) is active, is a drawback in print speed and sometimes in accuracy. I'm not finally sure if some of the negative effects come from mechanical problems of my Morgan-build or the firmware. But I think Marlin is way more sensitive to performance-issues than Teacup, because it's not as optimized. I'm very curious about Teacup's performance on my RepRap Morgan and quite sure that it will perform better, therefore making fewer problems when it comes to arm/bed-levelling.

You should write a Github-issue on that and you may assign it it to me, if you like. If you can't write an issue yourself, just send me the text and I'll open it for you ([email protected]).

I too have tried to merge the old Marlin SCARA file with the new, having no success. I'm not sure what a Github-issue is, my programming skills are limited as best.

Just describe the concrete requirements you would like to see regarding auto-bed-levelling. I'll open th issue for you. An issue in Github is a point of interest, a task that needs to be resolved by someone.

If you go to the homepage of the Github-Teacup-project you'll see a little exclamation mark in a circle on the right side, titled "Issues". You should read them to get an overview what topics we work on (and maybe don't) and you can participate in the discussions there.

Thank you RobertKuhlmann, that would be extremely helpful. I was thinking that a probe could rotate down in a similar manner to how other auto bed leveling systems work. The arm would then probe in three or four locations and make the necessary adjustments.

Would it also be possible to add a variable to account for the X and Y steeper motors that are spatially separated. I think spring loading relatively inexpensive geared stepper motors holds a lot of promise. So far, no backlash has been transferred to my prints.

BTW: Just found out that I have tomodifiy "update_current_position" too (in dda.c).

Quote
Evil Monkey
Thank you RobertKuhlmann, that would be extremely helpful. I was thinking that a probe could rotate down in a similar manner to how other auto bed leveling systems work. The arm would then probe in three or four locations and make the necessary adjustments.

QuentinHarley's implementation of "armlevel" is semi-automatic. During print the bed level follows a height-correction-matrix (automatically; 11 x 11 points over the x/y-dimension of the buildingspace). The matrix was entered in an extra calibration-step (manually; commands M370, M371,M372, M373; M375 output matrix). So this approach doesn't even assume a plain bed-surface, nor an exact bed-adjustment. But you will have to calibrate one time to fill the matrix (that takes app. 3-5 minutes; with some routine you can do it 1 Minute).
The RepRap Morgan only needs to be calibrated after changes in the construction (e.g. after changing the bed; that's what I do quite often to test my heated beds: RepRap Wiki: Robert's heated bed).
RepRap Morgan is very tolerant against being moved around - the construction is very stable.
Of course you could automate the task of filling the matrix by adding a sensor to the toolhead, but this would raise the mass of toolhead and therefore the mass that has to be moved during the print. So you would lose accuracy or speed (your choice). I think this problem is common to almost all 3D-printer-models. The less mass you have to move, the less stress is applied to the construction.

I would like to split your suggestion into two parts and both of them are not specific to scara-type printers or Morgan:

1. Auto-bed-leveling: The z-axis is moved automatically to level out inaccuracies of the surface and the adjustment of the bed. The matrix is filled during a manual calibration procedure.
2. Auto-bed-calibration: The z-calibration-matrix is filled during an automated calibration step. An automatically activated probe helps to measure the calibration points.

No. 1 only has to be transfered from Quentin's Marlin-variant. I'd like to hear Traumflug's opinion if this would make a seperate branch or should be specific to the scara-branch (despite it has nothing specific to scara-printers and could be useful for any printer-type - I guass).
The second task would only be interesting, if the probe could be realized in a way that doesn't have to much drawbacks in printquality or speed. The solutions that are out there so far are automatic, but inelegant as well. In my opinion we need a solution that not only "does" the job, but does it elegant, effective, with few ressources (in hard- and software) and accurate, of course.

There's a commercial solution out there, using IR-LEDs and-sensors, measuring the distance between nozzle and bed. It seems to be very accurate but expensive and it's not open hardware. And it's too big (if you'd ask me).

I've got a new idea for such a probe (nobody knows of this idea so far; you're the first to read this):
Task:
We need to measure the distance between the nozzle and the bed-surface for several points (the more the better) and store the measurements in an array that will be used to auto-level the bed to keep a constant distance between nozzle and bed on every x/y-coordinate during print.

Problem:
The nozzle may and should be could during the measurement. Therefore it may be, and often is, dirty, partially covered with filament remnants. So the nozzle likely is electrically insulated and most of the printbeds electrically insulated anyway. The filament remnants on the (cold) nozzle would affect the measurements too. The mechanic and other parts of a z-probe affect accuracy and/or speed of the print, even if not in use.

Solution:
We build a small plastic cap that has a defined height and covers the nozzle with some vertical clearance (with respect to filament remnants) and some clearance in diameter too. The outer height of the probe is constant of course. The probe may have a tip like a nozzle without the hole in it. The inner hole of the probe (where the nozzle will be situated) has some simple springs to keep the probe in place.
The body of the probe consists of two parts. The upper part is a ring and its inner diameter is big enough to contain the nozzle and the springs as fixture. The lower part is the round tip of the probe, being sharp on the bottom end and flat on the upper side. Between the flat end of the bottom part and the upper part we place a piezoelectric plate (e.g. from a very very cheap speaker or sth. similar - even new it costs a few cents). The upper part of the probe has a small hole where two thin wires can comes out from the piezo.
We connect these wires to a small PCB with the required electronics to convert the piezo signal to something we can send to an IO-port of our microcontroller. The firmware will take care of the offset between nozzle-tip and probe-tip.

With the probe attached to the nozzle we can start our automatic measurement. After we've finished the measurement, we can take of the probe and print as usual with no extra weight on the toolhead and not additional wires. Sounds promising to me.
Best: You can print the parts of the probe. The electronics should be very simple and somewhat independent from the hardware.
I think I'll post this idea in an extra thread.

Quote
Evil Monkey
Would it also be possible to add a variable to account for the X and Y steeper motors that are spatially separated. I think spring loading relatively inexpensive geared stepper motors holds a lot of promise. So far, no backlash has been transferred to my prints.

I didn't get your point here. You have to take into account that I'm used to RepRap Morgan, not any other scara-type printer out there (esp. polar-printers). The mathematics seem very similar (if not equal), but you need to inform me about the mechanical details you refer to and why.

Edited 2 time(s). Last edit at 08/22/2014 11:49AM by RobertKuhlmann.

That probe sounds great!

The Morgans arms utilize the same axis of rotation for both the X and Y stepper motors. I was referring to the variable in the Marlin version called Scara_axis_spacing. This takes into account the horizontal separation of the geared stepper motor that move the arms. This current build has the geared stepper motors separated by 85 mm. Is it possible to implement in this Teacup version?

Quote
Evil Monkey
That probe sounds great!

The Morgans arms utilize the same axis of rotation for both the X and Y stepper motors. I was referring to the variable in the Marlin version called Scara_axis_spacing. This takes into account the horizontal separation of the geared stepper motor that move the arms. This current build has the geared stepper motors separated by 85 mm. Is it possible to implement in this Teacup version?

Ah. I begin to understand your point. Should be possible of course. I need to know the effect this has on the calculations for scara-movements and -positions.
I'll take a look at the Marlin-version you've stated before. But I'm sure it will be no problem to integrate this into the scara-branch.

I like the probe too. I've conclused my thoughts on that because of your post. I'll make a 3D-model of the probe as soon as I can. Should be quite simple. But I need support with developing the electronics for that. I will discuss this in the new developer-thread I've opened a few minutes ago.

Quote
RobertKuhlmann
I'd like to hear Traumflug's opinion if this would make a seperate branch

Yes, a new branch, please. Like one branch per topic. You can base a branch on top of another to have both topics.

Uh, and I see I have to speed up my branch integration work. All this stuff has to settle in experimental/master one day. Right at the moment I'm working on getting rid of thermistor tables. Just enter R0, T0 and Beta of the thermistor and you'll be set.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote
RobertKuhlmann
I'd like to hear Traumflug's opinion if this would make a seperate branch

Yes, a new branch, please. Like one branch per topic. You can base a branch on top of another to have both topics.

Uh, and I see I have to speed up my branch integration work. All this stuff has to settle in experimental/master one day. Right at the moment I'm working on getting rid of thermistor tables. Just enter R0, T0 and Beta of the thermistor and you'll be set.

I've read about that and it's a very good idea, since almost nobody makes his own table of measured values, but copies the table in datasheet or (more often) calculates the table with exactly the same values you want to use anyway.
So we will not lose too much of accuracy at all, except for the very few that really made it with their own measurements.

The issue is calculation speed. These tables mean to speed up thermistor voltage to temperature conversion and it requires some efforts to do that similarly fast as an interpolating table lookup. Currently it's more than 10'000 CPU cycles per conversion, which would account for some 2% of the available computing speed. A table lookup costs about 2000 CPU cycles (it requires two arbitrary-value multiplications and a division, all 32-bit).

I tried to use a polynomal, which is even faster than a table lookup, but then you're back to square one: you have to do some manual calculations before compilation ... which nobody does. I have to get away with those values found directly in the data sheet, preprocessor and runtime math.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Good evening,

I think I have calculated the inverse kinetics for the single-arm-SCARA and the parallel-arm-SCARA as well.
Here are the calculations...



Perhaps it is useful for someone...? (hopefully there´s no mistake in it!?)
The parallel-arm-SCARA kinetic seems to be easier than the single-arm with respect to calculation effort.
In case of the parallel-arm-SCARA, the math for the second (right) arm is identical with the one for the first (left) arm for d=0.
Unfortunately, I do not have any programming experience.... Could somebody please tell me the filenames which are needed to be modified?

BR,
Mike

In the marlin version, check out marlin_main.cpp and look under the section called parallel SCARA kinematics.

Quote
theothermike
...
Perhaps it is useful for someone...? (hopefully there´s no mistake in it!?)
The parallel-arm-SCARA kinetic seems to be easier than the single-arm with respect to calculation effort.
In case of the parallel-arm-SCARA, the math for the second (right) arm is identical with the one for the first (left) arm for d=0.
Unfortunately, I do not have any programming experience.... Could somebody please tell me the filenames which are needed to be modified?

BR,
Mike

The forward and inverse kinematics (iow: depending on if you need angles from coordinates or vice versa) for scara-systems are well known and documented:
e.g. http://www.machinebuilding.net/ta/t0323.htm

@Evil Monkey: I think you'll only find scara-kinematics in Quentin Harley's Marlin-version, not in the original project from Eric Zalm (Quentin made his own Github and not a branch of the original Marlin firmware).

Quote
RobertKuhlmann
One general question regarding Scara-printers and printer-firmware:

The actual processing interprets GCode-entries e.g. to fill up a buffer with fundamental microcontroller tasks. If the buffer is full, interpretation stops until enough entries in the buffer were processed and deleted. So for simple GCode-Commands the interpretation is ahead of the execution, but for complex commands it can happen that filling up the buffer is slower than the execution, slowing down the print as a consequence.
This can be observed especially with the Marlin firmware on Scara-printers like the RepRap Morgan. More speed would have to be paid with less accuracy and precision. But while every step in a print that consists of commands, that don't depend on sensor-data (like temp.-settings), is predetermined from the moment the GCode is generated and the printer is known.

I just saw your post. I've been thinking along similar lines
recently.

What I've been thinking of trying out in an experimental firmware is
replacing the standard G1 gcode commands with timed stepping
sequences. That is, instead of sending the micro-controller a command
to move the head a number of millimeters at a specific velocity,
commands would be sent to pulse a given stepper pin starting at a
specific time (measured in clock ticks) and for a given duration
(measured in clock ticks) with a given time between pulses (measured
in clock ticks). To make sure acceleration doesn't require an
excessive number of commands, an adjustment factor could also be
specified to allow the time between pulses to be linearly adjusted.

To put this into pseudo-code, I think the stepper irq handler could
look something like:

void handle_step(struct queued_command *cmd)
{
    do_step(cmd->step_pin);
    uint32_t newtimer = cmd->pulse_time;
    if (cmd->pulse_adjust)
        newtimer += (cmd->pulse_adjust * cmd->elapsed_time) / 65536;
    cmd->elapsed_time += newtimer;
    if (cmd->elapsed_time < cmd->end_time)
        schedule_next_time(newtimer);
    do_unstep(cmd->step_pin);
}

I think one could, in theory, do all the acceleration, lookahead, and
kinematics in the slicer.

There is some complexity to this of course. Multiple steppers would
need to run in parallel, so the command parsing and queuing would need
to support multiple simultaneous stepper sequences. One would also
need to ensure the command queue was kept sufficiently full and the
robot doesn't get too far ahead of the command stream (though the cpu
should never be a bottleneck as there would be no need for complex
acceleration and kinematic math).

The above would require more commands then current G-code when the
head is accelerating, because acceleration can't be fully modeled with
simple linear scaling of the stepper frequency. So, several commands
(probably around 8-10) would be needed to approximate constant
acceleration. Although this is more commands, when the head is
accelerating, it is running slower then its full velocity and thus
there is more time for commands to be sent.

Anyway, I thought I would raise the idea here. If this has been
attempted before or someone knows why it wouldn't work, please let me
know.