[NEW] OVM20 Lite, a simple board for lowcost printers October 05, 2017 06:29AM |
Registered: 9 years ago Posts: 5 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 05, 2017 09:08AM |
Registered: 10 years ago Posts: 14,672 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 05, 2017 11:56AM |
Registered: 7 years ago Posts: 363 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 05, 2017 11:58AM |
Registered: 9 years ago Posts: 5 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 05, 2017 02:45PM |
Registered: 10 years ago Posts: 14,672 |
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.
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 05, 2017 02:55PM |
Registered: 10 years ago Posts: 14,672 |
Quote
obelisk79
dc42, I don't know of any decent $37 32bit boards. do you? I'd love to see one.
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 06, 2017 02:55AM |
Admin Registered: 16 years ago Posts: 13,889 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 06, 2017 05:10AM |
Registered: 9 years ago Posts: 5 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 06, 2017 10:22AM |
Registered: 10 years ago Posts: 14,672 |
Quote
VDX
@dc42 - aren't you a bit too negative?
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 07, 2017 06:56AM |
Registered: 7 years ago Posts: 363 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers October 07, 2017 12:46PM |
Registered: 8 years ago Posts: 5,232 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 15, 2017 02:45PM |
Registered: 7 years ago Posts: 9 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 15, 2017 03:54PM |
Registered: 10 years ago Posts: 14,672 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 15, 2017 05:19PM |
Registered: 7 years ago Posts: 9 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 16, 2017 03:05AM |
Registered: 10 years ago Posts: 14,672 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 16, 2017 08:00AM |
Registered: 7 years ago Posts: 9 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 16, 2017 10:56AM |
Registered: 10 years ago Posts: 14,672 |
Quote
xor_ea_ebx
i do not like the added complexity during (initial) development.
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.
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.
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 16, 2017 03:45PM |
Registered: 7 years ago Posts: 9 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 16, 2017 05:47PM |
Registered: 10 years ago Posts: 14,672 |
Quote
xor_ea_ebx
should be discusses elsewhere. we lost focus on the threads topic.
Quote
xor_ea_ebx
each movement is split into accel / decel / linear approximated segments any way. so whats the problem there?
Quote
xor_ea_ebx
a good planner "joins" these segments an ideally makes a smooth motion.
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.
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.
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.
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).
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.
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.
Quote
xor_ea_ebx
most have a pi anyway so why not compute the path there?
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.
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 17, 2017 01:29AM |
Registered: 7 years ago Posts: 9 |
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.
// 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.
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.
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);
Quote
dc42
But I don't see that Linux offers me anything when it comes to trajectory planning.
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 17, 2017 09:47AM |
Registered: 7 years ago Posts: 363 |
Re: [NEW] OVM20 Lite, a simple board for lowcost printers December 17, 2017 10:50AM |
Registered: 7 years ago Posts: 363 |