[NEW] OVM20 Lite, a simple board for lowcost printers

Hello!

My name is Javier Loureiro, and for the last couple of years, I was assembling and selling the RAMPS 1.4 SB.

During those years, I got many questions from new users: which driver should i use? is it my arduino mega good? how do I plug the drivers?

So, I had the idea of a new board, that tries to simplify the basic 3d printer kit. It is not a "competitor" for other boards with more features. It is a board that will do the basics, but it will do it very well, at a fair price.

Best features:

- Full compatible with Marlin. No need for special drivers and configurations. You setup marlin like RAMPS 1.4, and it works. It works with the default setup from github. Download and upload (obiusly, you need to tune your printer anyway).

- Easy to assemble. One single purchase, with less options, missunderstandings, etc. It is ideal for kits, schools, workshops, etc.

- Powerful mosfets with extreme low internal resistance. They keep about 50º celsius (tested in sevilla, spain, during summer). The board is simple, but powerful.

- Branded Molex, no cheap dangerous power connectors. You can print for hours, days and months.

- 4 copper layers: better heat dissipation, longer life.

- Beautiful design!! black pcbs with blue leds are gorgeous smiling smiley

I understand, (and I agree) that most of the makers will prefer more options, expansions, and hacking choices. But imagine a school, a workshop, or a shop that sells basic kits. In that case, I belive that the ovm20 lite is a fantastic and reliable alternative.



We assemble the board in Spain. Here we have a small pick and place and we assemble and test everything here, step by step.

Here you have the full list of features [www.staticboards.com]

and we are today on hackaday! [hackaday.com] the board fits perfectly for a prusa steel, and the author decided to talk about the experience on the blog. That is why we decided to post more information here.

If you like to try it, we have the board available on tindie: [www.tindie.com]

I am 100% sure that you would do it on some other way, but I tried to keep the project simple and compatible. Hope you like this idea too!

I don't mean to demean your efforts; but why did you design yet another board using the same tired old atmega2560 architecture, when it would have cost you less to use an ARM Cortex M4 processor, and the resulting board would have been far more capable?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dc42, I don't know of any decent $37 32bit boards. do you? I'd love to see one.

yes, I have the idea of a board with 32bits for a more "pro" version. I think that we need a better technology right now.

but at this point, marlin with the atmega chip is a stable platform, and there is a lot of very good documentation.

I think that there is space for both products. That is why we use the name "lite" for this board.

Quote
staticboards
yes, I have the idea of a board with 32bits for a more "pro" version. I think that we need a better technology right now.

but at this point, marlin with the atmega chip is a stable platform, and there is a lot of very good documentation.

I think that there is space for both products. That is why we use the name "lite" for this board.

I suggest you stop worshipping the false god Marlin.

Marlin served the 3D printing community well when we only had 8-bit platforms. Now it's a dinosaur. It still has an archaic system that requires you to edit the firmware source, recompile and upload firmware to make changes. It still uses the Bresenham approximation, which was designed for drawing images on pixelated screens, and is arguably OK for slow-moving CNC machines but fails to provide smooth movement on 3D printers. It still doesn't compute the step timings for acceleration and deceleration phases accurately. It still generates segmented movement when controlling delta printers. It doesn't provide a web interface. It doesn't provide least-squares autocalibration for delta printers, or for calculating adjustments to bed levelling screws.

What the Marlin devs should have done at least two years ago was to create a separate source tree for a 32-bit version, so that they could make use of the power and more importantly the additional RAM provided by 32-bit processors. But they didn't (although there is at least one 32-bit fork). I realise that the Marlin devs have in many respects done an excellent job of supporting 8-bit platforms given the limited resources they provide, but they have singularly failed to move with the times.

Even in the 8-bit firmware space, Repetier is better than Marlin in important respects. It has a standard web-based tool to generate the config file. Until very recently, it was the firmware of choice for owners of delta printers with 8-bit electronics, because Marlin was so bad at controlling delta printers (leading to stuttering) and didn't provide sufficient delta calibration parameters (the RC fork of Marlin had a form of auto calibration, but it didn't always work and the fork wasn't maintained).

There are two excellent firmwares for 32-bit processors: RepRapFirmware and Smoothieware. Both are being developed actively. I don't think you will find a user of either of those firmwares who would voluntarily go back to Marlin - they are so much easier to use.

There is certainly room in the market for a 'lite' board - meaning a board with e.g. 4 stepper drivers rather than 5 and limited expandability - but 'lite' doesn't have to mean crippled i.e. putting in a MORE EXPENSIVE aging 8-bit processor plus a separate USB-to-serial converter chip, instead of a modern and cheaper 32-bit ARM processor.

I'm sorry if this seems like a rant, but as a professional electronics design engineer I find it crazy that someone chooses to design a system around a obsolescent 8-bit processor costing more than twice as much as a modern ARM processor, especially when firmware for the 32-bit chip is already available. If I did a design like that for an employer, I'd be sacked.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
obelisk79
dc42, I don't know of any decent $37 32bit boards. do you? I'd love to see one.

I would love to see a good low-cost 32-bit board too, but nobody seems to have produced a good, low cost, open source 32-bit design - even though it would be cheaper to manufacture than the current 8-bit designs. It isn't worth a professional designer like me designing one, because if it isn't successful then I won't cover my costs, and if it is then it will get cloned by Chinese manufacturers and I won't be able to make a living out of it, even though people will still expect me to support it.

In fact I did most of the design for a low cost 32-bit board in early 2015, and the design (with PCB not fully routed) is in my github repository. I gave up on it when $50 32-bit boards started to appear. But that design is out of date now, because technology has moved on in those 2+ years.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

@dc42 - aren't you a bit too negative?

I'm using Marlin4Due with RADDS since 2 years now for pastedispensing and laser-engraving without problems and with up to 400mm/s moving speeds ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Thank you for your opinions, andI understand your point.

But I see that the world is big enough, and we all are different. People have different interests and objectives in life. The power of the community is to help others with their different needs.

As I said, not everybody needs a new full featured board. And the fact is that we already sold hundreds of OVM20 lite here in Spain. So, definitively, there is a demand for this kind of electronics.

This board is easy, and well supported because it works perfectly with marlin. There are a lot of good tutorials for arduino, and marlin, and that is a great value for the community. It has powerful mosfets and reliable connectors, and that is a real and needed point. You will have less problems, and you will save time.

We are following the 32bits developments, and I am sure that we will release a new powerful 32bits board in the future.

thank you.

Quote
VDX
@dc42 - aren't you a bit too negative?

Perhaps... but I think he has missed a great opportunity. If he can make atmega2560 boards in Spain and sell them for $37, he could make make a 32-bit ARM Cortex M4 board with the same drivers and expansion capacity (no networking) and sell them for about $34 with the same profit, which would open up a whole new market. Or add WiFi and still keep the price below $37.

Edited 3 time(s). Last edit at 10/06/2017 10:23AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

He'd certainly get some of my money at those prices.

Hmm, I don't see fuses?! Are they SMD or did you forget them?

sorry dc42, i disagree. there are alternative firmwares available for 8bit controllers which allow high speed and smooth movements. e.g. there are at least teacup (which using a Gen7 board is also 32bit capable and below 40$ i guess -- if you like isolation milled boards) and klipper.

what i think, and probably the creator of klipper, the path planning should happen on a compute host. i.e. a raspberry pi or pine64 or pc. additionally, all that
bloated stuff like web-server, sd-card, lcd-panel, ethernet, ... should not be run on the real-time sensitive core mcu.

if you read the article about the amazing 1$ microcontrollers at [jaycarlson.net] you will see that an 8bit controller can have a
much lower interrupt latency than your cortex-m3/4 and cost like <1$. esp. the stmicro stc8 has an interrupt latency of only 6 cycles. compare this to your
cortex with 300 cycles if NOT using floating point in the interrupt context. if the potentially expensive -- as in computation time -- planner runs on the host you
could drive a delta bot easily with an 8bit controller. because the mcu does what it should do: emitting steps. nothing else. (ok some adc conversions, ...)

so the question remains, why an atmega2560 and not an efm8 laser bee or the stc8 (or even an atxmega).

i have 4 ovmlite20 boards running (and even replaced my duet wifi with one). i'm glad that these boards are absolutely minimalistic.

regarding software correctness and reasoning about timing issues i prefer the simplicity of 8bit architectures. I don't like the added complexities due to
cmsis and mbed.

i'm not saying 32bit is crap. You have to pick the right part for the job. e.g. klipper runs on 32bit archs as well. so you can choose whatever you want.

If you expect to be taken seriously, please don't pollute this forum with wildly inaccurate information. The basic interrupt latency of the ARM Cortex M4 is 12 clocks. This may be increased to 18 clocks depending on the memory architecture, plus potentially a few wait states if the clock frequency is high and the memory can't keep up e.g. if the vector table is held in flash memory. Nothing like the 300 clocks you mentioned.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

from the linked article:

"Another problem with ARM processors is the severe 12-cycle interrupt latency. When coupled with the large number of registers that are saved and restored in the prologue and epilogue of the ISR handlers, these cycles start to add up. ISR latency is one area where a 16 MHz 8-bit part can easily beat a 72 MHz 32-bit Arm microcontroller."

from the arm reference manual: doing floating point instructions during an isr add 50 cycles latency (pushing and popping).

dc42, maybe you should read the specs too. there can be wait stats because fetching from flash memory. this 12 cycles are they guaranteed or is it
an unsafe lower boundary?

from the Article: DMX 512 Receiver: ISR Latency: Atmel SAM D10: 391 Cycles, Atmel megaAVR 34 Cycles

the mega avr has as well a latency of 5 clocks, but then register saving starts. this counts as well for the latency.

You are also ignoring some things:

- The ARM interrupt latency includes the saving of some of the general purpose registers (5 of them AFAIR). So they are free to use immediately. The standard ARM ABI will only save additional registers if the ISR uses them.

- The SAM4E processor used on the generation 2 Duets runs at nearly four times the clock frequency of the STC8 that you quote, and eight times the clock speed of a 16MHz atmega.

So the comparison is between an ARM processor that has between 12 and about 24 clocks latency (allowing for wait states) at 128MHz but has some registers ready to use immediately, and the STC8 with 6 cycles latency at 33MHz but has no registers already saved, and you are likely to need to save more of them because each one is only 8 bits wide.

In summary, the latency measured in nanoseconds about the same for the ARM processor and the STC8 (and about twice as long for the atmega), but the ARM is then capable of doing some work immediately, and doing it faster. That's why the Duets can generate step pulses much faster than an atmega, see [reprap.org].

The linked article clearly says that the poor performance in the ARM ISR they measured was caused by a poor UART abstraction in the library they used. You don't have to use that library.

8-bit processors still have applications (I use them in my IR sensors, and the Duet3D Smart Effector uses one), but IMO they are obsolete in high pin count applications such as 3D printer controllers.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dc42, yes of course. but ir latency was just one of my "concerns". i do not like the added complexity during (initial) development. so step rates are not everything. proper motion planning (no not trapezoidal 2nd order / constant accel) using e.g. S-curves might be even more important. from this viewpoint
the main difference between marlin and klipper, reprapfirmware is RRF&klipper are not using bressenham. Unfortunately no firmware i am aware of is
using S-curve motion planning (for 3d printing).

maybe my initial statement was not clear or confusing: using 8bit is ok as long as you not going to do trajectory planning on it as well. you can leverage the additional computational power of 32bit cpus and do everything on one board on one cpu. but that is not what i would aim for. i want the planning separate from the "interface" card, like it is done for ages in cnc.

thus the ovm20lite fits my niche perfectly. the board and components are high quality (i worked as electrical engineer in industry as well). For me it is perfectly fine to be able to choose between fine 32bit boards like Duet* and fine 8bit boards. the host part of klipper runs even on a 64bit PI. so 32bit is of yesteryear 8bit firmware size is 12k.

ps. i would not add pressure advance to the gcode interpreter / firmware as this belongs to the toolpath generator. in case of 3d printing the slicer, in case of cnc the CAM software. this is separation of concerns and you learn about it in 1st semester university.

summarizing, i just wanted to thank @staticboards for their awesome work.

Quote
xor_ea_ebx
i do not like the added complexity during (initial) development.

What added complexity? Sure, 32-bit processors generally have much more capable and complex peripherals than 8-bit processors, but you don't have to use them. Ultimately it's down to what you are used to and what development environment/libraries you have for the processor you want to use.

Quote
xor_ea_ebx
maybe my initial statement was not clear or confusing: using 8bit is ok as long as you not going to do trajectory planning on it as well. you can leverage the additional computational power of 32bit cpus and do everything on one board on one cpu. but that is not what i would aim for. i want the planning separate from the "interface" card, like it is done for ages in cnc.

Perhaps it's been done on CNC machines like that because of the limitations of 8-bit processors. IMO it's much more natural to implement the trajectory planning on the real-time processor. And how else can you do segmentation-free delta motion? If I was going to use 2 processors, I'd do the user interface, file reading etc. on one processor and send ready-decoded GCodes to the real-time processor. But unless you want to do some very fancy things in the user interface beyond the comprehensive facilities that the Duet web interface provides, running everything on a single 32-bit processor works just fine. BTW the current generation Duets offload the TCP/IP stack on to a separate module (even though the older Duets had no problem running all the networking code on the main processor), and the colour touch screen has its own ARM 4 processor (it's the cheapest option I know of with the required I/O).

Quote
xor_ea_ebx
ps. i would not add pressure advance to the gcode interpreter / firmware as this belongs to the toolpath generator. in case of 3d printing the slicer, in case of cnc the CAM software. this is separation of concerns and you learn about it in 1st semester university.

I disagree. You can't implement linear pressure advance in the toolpath generator, other than by chopping the acceleration and deceleration portions of each extruding move into tiny segments to approximate it - and that would only work if the toolpath generator knows the actual acceleration of each move. IMO GCode for 3D printers should be machine-independent as far as possible, and the slicer has no business knowing machine parameters such as how much pressure advance is needed on a particular extruder, and the actual speed and acceleration that will be used for each move.

Pressure advance is part of trajectory planning - which is a real-time task, so for me the natural place to do it is on the real-time processor.

Edited 5 time(s). Last edit at 12/16/2017 11:34AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

should be discusses elsewhere. we lost focus on the threads topic.

doesn't sound it irrational/unlogical to you that your toolpath generator doesn't know about the used tool? i would say something is definitely wrong. each movement is split into accel / decel / linear approximated segments any way. so whats the problem there? a good planner "joins" these segments an ideally makes a smooth motion. if you actually depend on the firmware to do retraction and pressure advance you will get different results on different machines ->
so you inadvertently propagating the exact opposite of your goals: platform/firmware dependent gcode.

of course, you need to calibrate your extruder and adjust the toolpath generator accordingly. for every filament, for moisture and humidity, ... i think it is
easier to adjust your slicer than to constantly tinker with your firmware settings. the slicer has full knowledge of the object and paths, can optimize them
and minimize effects, you can't do that later on in firmware. "on-chip" planner as finite lookahead/back of like N moves.

the complexity of 32bit processors with caches is that you cannot guarantee about WCET or have only imprecise upper bounds. it is possible to
reason about execution times in presence of caches but that requires at least a monotone framework for data-flow analysis (may must analyses).
(i know there is cache content locking...). (i worked in compiler construction several years as well as on real time system WCET analysis).

linuxcnc/machinekit runs on top of a realtime linux kernel. the cnc guys didn't use 8bit controllers, they used to use LPT black arts on a usual PC.

why not start a new discussion/challenge and analyze the disassembly of your firmware and klipper/grbl/marlin regarding interrupt latency in step generating relevant paths? assuming you are using timers and not the DMA counter trick.

be aware that the stc8 or efm8 e.g. has register banks which can make register pushing obsolete in some cases.the efm8 runs at 72Mhz having a 5 stage pipeline. bottleneck is the 25Mhz flash memory connection. for step generation these are fine.

most have a pi anyway so why not compute the path there?

you can leverage full linux stack and cummunity; and actually safe on expensive development and customization time because everything is already there.

no need to glue esp8266 or an lcd to your interface board. the ~2k lines of step generation firmware is easy to maintain and support. threading: done. multicore: done, proper MMU: done. network: done, ssh: done, ... not to mention that this "pi code" will run on any pc. so debugging of the planner is much
easier as well... if you don't like 8bit use 32bit as interface but do not re-invent the wheel and write a new operating system for duet.

Quote
xor_ea_ebx
should be discusses elsewhere. we lost focus on the threads topic.

Sure, we can discuss this elsewhere if you prefer.

Quote
xor_ea_ebx
each movement is split into accel / decel / linear approximated segments any way. so whats the problem there?

The only significant approximation that RepRapFirmware does for Cartesian, CoreXY and Delta machines is to approximate smooth motion by individual microsteps - we don't use Bresenham.

Quote
xor_ea_ebx
a good planner "joins" these segments an ideally makes a smooth motion.

Sure; but why make the planner's job more difficult and the print less accurate by splitting up long segments unnecessarily, and then have to stitch them back together in the planner?

Quote
xor_ea_ebx
if you actually depend on the firmware to do retraction and pressure advance you will get different results on different machines ->
so you inadvertently propagating the exact opposite of your goals: platform/firmware dependent gcode.

The required pressure advance is highly dependent on the machine! It depends on the details of the extruder drive, Bowden tube, mixing chamber and nozzle. So it's much better done in the machine than in the slicer. Besides, I can adjust it on-the-fly while doing a test print, without having to re-slice the model. Splitting the acceleration and deceleration parts into multiple segments just so you can do linear pressure advance in the slicer is just ridiculous IMO. Plus the slicer would have to know the acceleration and speed settings of the machine in order to get it right. On some machines (especially CoreXY) the maximum speed and acceleration depend on the direction of motion.

Quote
xor_ea_ebx
of course, you need to calibrate your extruder and adjust the toolpath generator accordingly. for every filament, for moisture and humidity, ... i think it is
easier to adjust your slicer than to constantly tinker with your firmware settings.

I guess using 8-bit firmware has brainwashed you into thinking that the only way to change firmware settings is to recompile and re-upload it. Get real! Try using a modern 32-bit firmware with a good web interface - you'll be amazed at the improvement in usability.

Quote
xor_ea_ebx
the slicer has full knowledge of the object and paths, can optimize them
and minimize effects, you can't do that later on in firmware. "on-chip" planner as finite lookahead/back of like N moves.

Paths, yes. Accelerations and speeds, no.

Quote
xor_ea_ebx
the complexity of 32bit processors with caches is that you cannot guarantee about WCET or have only imprecise upper bounds. it is possible to
reason about execution times in presence of caches but that requires at least a monotone framework for data-flow analysis (may must analyses).
(i know there is cache content locking...). (i worked in compiler construction several years as well as on real time system WCET analysis).

And I work in safety-critical software. True, you can't do WCET analysis in the presence of caches. But has anyone ever done WCET analysis of a 3D printer firmware anyway? I very much doubt it. The SAM3X processor used on the first-generation Duets didn't have a cache. The SAM4E on the second generation Duets does, but enabling it makes very little difference and for many firmware versions we didn't enable it (it's likely to be more significant if you add external RAM).

Quote
xor_ea_ebx
why not start a new discussion/challenge and analyze the disassembly of your firmware and klipper/grbl/marlin regarding interrupt latency in step generating relevant paths? assuming you are using timers and not the DMA counter trick.

Why not just measure the performance instead, taking into account also the features that the various implementations provide?

Quote
xor_ea_ebx
be aware that the stc8 or efm8 e.g. has register banks which can make register pushing obsolete in some cases.the efm8 runs at 72Mhz having a 5 stage pipeline. bottleneck is the 25Mhz flash memory connection. for step generation these are fine.

I recall a similar feature in the Z80. It's very nice until you have to handle nested interrupts.

Quote
xor_ea_ebx
most have a pi anyway so why not compute the path there?

The vast majority of 3D printer owners don't have as Pi, and wouldn't know how to use it if they were given one. The Pi is great for tech-savvy 3D printer owners who want to add webcams, push notifications and the like. But I'd still prefer to keep real-time tasks - including trajectory planning - off the Pi so that whatever else I put on it won't end up causing stuttering.

Quote
xor_ea_ebx
you can leverage full linux stack and cummunity; and actually safe on expensive development and customization time because everything is already there.

no need to glue esp8266 or an lcd to your interface board. the ~2k lines of step generation firmware is easy to maintain and support. threading: done. multicore: done, proper MMU: done. network: done, ssh: done, ... not to mention that this "pi code" will run on any pc. so debugging of the planner is much
easier as well... if you don't like 8bit use 32bit as interface but do not re-invent the wheel and write a new operating system for duet.

That's all great for implementing a web interface, other user interfaces, file systems, storage etc. (although we have all of those on the Duet already). But I don't see that Linux offers me anything when it comes to trajectory planning. There are several well-developed RTOSes available for embedded 32-bot processors. Like I said before, for high-end systems I see merit in putting the networking, storage and user interface on a Pi or similar running Linux (it doesn't even have to be a real-time version), and putting step generation, trajectory planning and other real-time tasks on an embedded 32-bit processor.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
The only significant approximation that RepRapFirmware does for Cartesian, CoreXY and Delta machines is to approximate smooth motion by individual microsteps - we don't use Bresenham.

the algorithm the planner uses usually dissects each movement into an accel phase, near constant velocity and deccel phase at least. this has nothing
to do with bresenham.

i am talking about this:

	// Calculate the acceleration phase parameters
	const float accelCompensationDistance = compensationTime * (dda.topSpeed - dda.startSpeed);

	// Acceleration phase parameters
	mp.cart.accelStopStep = (uint32_t)((dda.accelDistance + accelCompensationDistance) * stepsPerMm) + 1;

	// Constant speed phase parameters
mp.cart.mmPerStepTimesCKdivtopSpeed = (uint32_t)((float)((uint64_t)DDA::stepClockRate * K1)/(stepsPerMm * dda.topSpeed));

Quote
dc42
I guess using 8-bit firmware has brainwashed you into thinking that the only way to change firmware settings is to recompile and re-upload it. Get real! Try using a modern 32-bit firmware with a good web interface - you'll be amazed at the improvement in usability.

don't bullshit me. you are smarter than that.

klipper firmware does not need to be recompiled at all. it is fully dynamically configurable. it does pressure advance in the trajectory planner (not slicer) on the compute host. (an AMD APU in my case). it runs on 32bit and 8bit. gives you very high step rates >300kHz on 32bit. grbl is also runtime
configurable. have you at least looked at one other firmware? marlin and repetier can use eeprom to store values. but you cannot switch the inverse kinematics i guess. using klipper: no problem, done on the host

i used the duet wifi & its web interface over more than a year on a daily basis. uuuuhhh, ohhhhh a "web" "interface". welcome in the 21st century.

every printer can have a web interface using esp8266 in couple of seconds... nowadays...

Quote
dc42
The required pressure advance is highly dependent on the machine! It depends on the details of the extruder drive, Bowden tube, mixing chamber and nozzle. So it's much better done in the machine than in the slicer. Besides, I can adjust it on-the-fly while doing a test print, without having to re-slice the model. Splitting the acceleration and deceleration parts into multiple segments just so you can do linear pressure advance in the slicer is just ridiculous IMO. Plus the slicer would have to know the acceleration and speed settings of the machine in order to get it right. On some machines (especially CoreXY) the maximum speed and acceleration depend on the direction of motion.

according to your implementation i can see exactly 3 machine depended parameters. steps per mm, acceleration and the pressure advance factor. i think
a slicer can handle this.

const float stepsPerMm = reprap.GetPlatform().DriveStepsPerUnit(drive) * fabsf(dv);
	mp.cart.twoCsquaredTimesMmPerStepDivA = roundU64((double)(DDA::stepClockRateSquared * 2)/((double)stepsPerMm * (double)dda.acceleration));

	// Calculate the pressure advance parameter
	const float compensationTime = (doCompensation && dv > 0.0) ? reprap.GetPlatform().GetPressureAdvance(drive - reprap.GetGCodes().GetTotalAxes()) : 0.0;
	mp.cart.compensationClocks = roundU32(compensationTime * (float)DDA::stepClockRate);
	mp.cart.accelCompensationClocks = roundU32(compensationTime * (float)DDA::stepClockRate * params.compFactor);

	// Calculate the net total step count to allow for compensation. It may be negative.
	const float compensationDistance = (dda.endSpeed - dda.startSpeed) * compensationTime;
	const int32_t netSteps = (int32_t)(compensationDistance * stepsPerMm) + (int32_t)totalSteps;

	// Calculate the acceleration phase parameters
const float accelCompensationDistance = compensationTime * (dda.topSpeed - dda.startSpeed);

so you are constantly and manually watching your machine printing all day long? just kidding

temperature is also printer dependent. so you don't set it in the slicer? max speed is printer depended. if you put everything into your board, your mcu has to be the slicer then. i don't see why i need to split a long line int "many" small lines due to pressure advance. if it is a long line, most of it stays at constant velocity and does not require tinkering with extrusion anyway. but you are right, the slicer has to generate couple small segments in the beginning and end of the line. you can have a look at recent kisslicer. it is implemented there.

Quote
dc42
But I don't see that Linux offers me anything when it comes to trajectory planning.

no it doesn't. cheap speed and ram maybe. but instead of focusing on bloated features on your controller, you could instead improve the trajectory planner. or do research.

i think we reached to point of where it is a philosophical question if one whats to have separate interface and compute cards or an all-in-one solution. if you are into the all-in-one solution you should use a 32bit controller for sure. (so marlin's dead) the other way it doesn't matter which architecture you choose for the interface card. same holds for doing everything in the slicer (the all-in-one slicer if you like) or have the actual planner (as opposed to toolpath generator) do it.
seeing it from this perspective it is absolutely fine to have more than one solution to the problem. i would prefer a different solution than you probably, but in the end it doesn't matter much.

i want to see s-curved (nth order, n>=3) based motion planning. for me it will be easier to implement on the host side. so that is the route i go. ideally i can reuse all of the code and control my cnc with it as well. (just using a different interface card because of power and stuff). rest stays the same.

Edited 1 time(s). Last edit at 12/17/2017 02:04AM by xor_ea_ebx.

Ok, different strokes for different folks.

DC42, you're an intelligent guy, but you often come across as mostly here to generate business for your own product.

Whether that is intentional or not is irrelevant. You've made a quality board. But you often argue that your way is the only right way. It detracts from your arguments frequently.

Edited 1 time(s). Last edit at 12/17/2017 09:48AM by obelisk79.

Stop hijacking this guy's thread arguing over differing design philosophies.