About the S-Curve work currently going on

[Arthur Wolf]

TL;DR: Encouragement :)

The work you guys have been doing on s-curve is very valuable and very interesting to a lot of people. There is potential for your work to have pretty wide-ranging uses.

I'm a bit worried though: I talked at an event a few years back with somebody who designs S-Curve-capable CNC controllers for a well-known control-hardware company, and he explained it's an issue that's much more complex than anyone he's ever met imagines.

Their controller has a dozen patents and several methods that are just outright not meant to be publicly known. He pointed out a lot of limitations in some of their competitors, and some they themselves still had to iron out.

He explained they even have completely different algos for when the machine is doing an arc, or for a lot of other special cases. Their thing isn't one algo, it's many, as well as an algo to decide which to use when, and the company has been at making these work for decades now.

He looked at Tinyg's S-curve code at my request and explained it was extremely naive and would have lots of weird/unpredictable issues ( he said it looks like what they had after a week of work when starting the project in the 80s ), just from taking a glance at it, just from the general structure of their implementation.

He said there are good reasons why there aren't good Open-Source implementations of this, it's just way too difficult for volunteer work.

I'd still really like you guys to try though. Maybe we can get to something that's a step up from what we have now, even if it's not even close to the theoretical perfect s-curve output.

Unit testing would be extremely important here ( to us ). On the Smoothie side, if your code existed, was easy to set up, and was easy to add tests to, we'd have lots of edge cases to add as test cases to your test suite, which in turn would help point out expected issues/limitations and improve the code.

Being able to run your algo against a complete test suite that includes the edge cases we know could/would be an issue, would go a long way towards convincing Smoothie's lead dev ( Jim ) this is worth attempting an implementation of.

And having the algo and test suite would make this work ( as well as the work of other cnc firmware devs like David here ) much easier on the devs, and therefore much more likely that an attempt at integration/implementation would happen.

Really hope you guys can get to the point where you've got a good algo that performs close to the theoretical ideal.

Actually. To measure if a given algo is good or not, you need to compare it with something. What would you compare it with? Do you have some sort of other code that generates an "ideal" s-curve, that the real-time algo can then be compared with?

Anyway, that's how things look like from our side of the project. Hoping your answers go the direction we'd like them to go :)

Cheers, and thanks again a ton for working on this, it has the potential to help a lot of people.

--

勇気とユーモア

[Scott Wilson]

Arthur,

That definitely makes sense, but I think the killer here would be multi-access coordination. Trinamic eveb sells dirt cheap controllers that do s-curve moves, but only in a single axis, and specifically have no solutions for multi-axis advanced movement. I know you had been told that multi-axis coordination was critical for PnP, but I can't think of how, and I don't think anyone has made that claim recently.

-Scott

[Arthur Wolf]

Well, if you aren't going to need axis sync, this is pretty trivially easy ...

Were the recent discussions on S-curve strictly about single-axis work?

What makes S-curve hard is the multi-axis aspect of things, keeping the axes synchronized and exactly where you want them, with all limits respected, but with the closest-to-perfect accuracy.

If you're only going to do S-curve on a single axis, that's like 20 lines of code...

Of the reasons to have multi-axis sync, one of the ones I remember easiest, is the fact non-sync movement ( each axis goes as fast as it cans to where it wants to be ), is much less intuitive/predictable to the user than synchronized ( start -> straight line -> arrival ) movement. Depending on machine setups that doesn't only apply to used controlled moves, but also to some automated ones.

Also, there's a pretty big advantage to sticking to multi-axis firmwares like Smoothieware or RRF: these already have large communities and volunteers that improve the system, test it much more than you could anytime soon, etc.

These older / 3D-printer-origin systems, are very mature, have large communities that are very good at providing help, but more importantly have tons of features besides the simple movement stuff, that users say they appreciate, and that it would take you a very long time to reproduce if you started a new project from scratch...

I'm generally a proponent of improving on the existing rather than start fresh ( my taste in these things is «whatever makes life easier for the users», which new projects are sort of the opposite of ), but I know not everybody is like that.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e291491-ef6f-4641-a1d1-97a29e71c437o%40googlegroups.com.

--

勇気とユーモア

[Scott Wilson]

Agreed, and I think to see if its worth the trade-off (purpose built s-curve controllers vs established) we need to get some prototypes going. Then we need to profile the time spent on movement, and see how big of a difference s-profiles can make.

Almost entirely unrelated, but is there any thought or work to making moves in smothieware via SPI commands? There seems to be very little work on it in any of the gcode controllers, so I'm guessing its either difficult or zero demand.

-Scott

[Arthur Wolf]

On Sun, Aug 30, 2020 at 9:54 PM Scott Wilson <scott.t...@gmail.com> wrote:

Agreed, and I think to see if its worth the trade-off (purpose built s-curve controllers vs established) we need to get some prototypes going. Then we need to profile the time spent on movement, and see how big of a difference s-profiles can make.

Almost entirely unrelated, but is there any thought or work to making moves in smothieware via SPI commands? There seems to be very little work on it in any of the gcode controllers, so I'm guessing its either difficult or zero demand.

Some people sometimes ask about it because they just discovered the feature exists in the chip, and they think it'd feel "neat", but there's no real demand for it in terms of it actually providing an advantage/improvement, no.

We have not seen concrete ways to keep several SPI-controlled drivers in sync, so we aren't moving forward until that issue is resolved.

-Scott

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dd07afed-f436-4ce7-8930-e980b249ea68o%40googlegroups.com.

--

勇気とユーモア

[Scott Wilson]

> feature exists in the chip, and they think it'd feel "neat"

The way this is related to the orginal topic is: several Trinamic drivers can use s-curves when moved via SPI. So there is a valid reason.

-Scott

[papyDoctor]

I don't know why you are talking about the tricky consideration of CnC controlling here.

Here -as I've mentioned several times before-, the constrains are not the sames. Algos can be much simpler and also faster. Motion is faster too.

Also, I'm sorry but I've shown a method to calculate without iteration a true perfect S-Curve motion. XY synchronism is simply a matter of controller implementation.

Finally, to test/measure implementation, I've a very simple solution: With some low cost FPGA board (like the CYC1000 I've mentioned also before), I'll make a high resolution counter (10ns res) to count the pulses and store time arrival. These data can be stored locally on the board and then downloaded afterward for analysis.

[Marmelade]

@Scott

The trinamic stepper drivers do not have build-in s-shaped ramp generators.

Some of them have trapezoidal and a few have SixPoint ramp generators.

For true 7-segment s-shaped motion you need separate ramp generators (motion controller, fpga, etc.)

And for monitoring and parameter setup the fastest solution is using chips with spi bus.

[ma...@makr.zone]

Some have.

https://www.trinamic.com/products/integrated-circuits/details/tmc4361a-la/

The can even do asymmetric entry/exit velocity and acceleration, though it seems to be limited to some combinations.

See also:

https://www.trinamic.com/technology/motion-control-technology/

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/be71d4ee-ec54-40e4-8009-3adca7ae1eeao%40googlegroups.com.

[Marmelade]

@Mark

No, the TMC4361A is a motion controller (expensive), not a stepper driver.

It's a nice chip except for very high acceleration values combined with high resolution.

On Monday, 31 August 2020 11:52:36 UTC+2, ma...@makr.zone wrote:

Some have.

https://www.trinamic.com/products/integrated-circuits/details/tmc4361a-la/

The can even do asymmetric entry/exit velocity and acceleration, though it seems to be limited to some combinations.

See also:

https://www.trinamic.com/technology/motion-control-technology/

_Mark

Am 31.08.2020 um 10:36 schrieb Marmelade:

@Scott

The trinamic stepper drivers do not have build-in s-shaped ramp generators.

Some of them have trapezoidal and a few have SixPoint ramp generators.

For true 7-segment s-shaped motion you need separate ramp generators (motion controller, fpga, etc.)

And for monitoring and parameter setup the fastest solution is using chips with spi bus.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[ma...@makr.zone]

Yes, if you want to make that distinction. Strictly speaking, as soon as ramps are generated it is always a motion controller, so it doesn't really matter whether if it is in one or two or three ICs.

The important distinction (that I believe Scott wanted to point out) is whether the MCU is generating the ramp or not. Btw. I agree that it does not make sense. The MCU can and should do it.

Nevertheless, @Scott, such a thing does exist, look at the TRAMS (linked below). That's not S-curves, but I guess the pattern would be the same. It does only make sense for an 8bit controller (and I really don't know why these 8bit buggers even exist anymore).

https://github.com/trinamic/TRAMS

https://www.trinamic.com/support/eval-kits/details/trams/

_Mark

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6f90fe2f-ec65-4573-9edf-e8be7850a726o%40googlegroups.com.

[scott.t...@gmail.com]

No, the TMC4361A is a motion controller (expensive), not a stepper driver.

It's a nice chip except for very high acceleration values combined with high resolution.

They're $12 on digikey which doesn't exactly break the bank.

 

@Mark- thanks for that reference! I'll see what I can figure out. I think you're right about doing ramp generation elsewhere in the stack, but I'm all for exploring options.

-Scott

[Arthur Wolf]

I took a look at the datasheet for the TMC4361, and I couldn't figure out how to use it to control more than one axis/motor.

Is it actually only for one axis at a time? ( in which case a multi-axis system would need as many TMC4361 as it has axes, with maybe nozzle steppers being ok controlled the classic way ).

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ca8d348a-5548-4e31-b7af-4a960fc5dbc0n%40googlegroups.com.

--

勇気とユーモア

[Scott Wilson]

> Is it actually only for one axis at a time? ( in which case a multi-axis system would need as many TMC4361 as it has axes, with maybe nozzle steppers being ok controlled the classic way ).

Yup- its only single axis.

[Arthur Wolf]

On Mon, Aug 31, 2020 at 10:56 PM Scott Wilson <scott.t...@gmail.com> wrote:

> Is it actually only for one axis at a time? ( in which case a multi-axis system would need as many TMC4361 as it has axes, with maybe nozzle steppers being ok controlled the classic way ).

Yup- its only single axis.

Well then I guess they would work for PnP setups that don't need axis synchronization, and not for the others.

Though I don't really see what is great about using a $12 piece of hardware to do something the microcontroller is capable of doing mostly for free, with code ( s-curve code, for a single axis ) that's really not that bad to implement...

 

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CACK509UAVd5Wd50BKxw%3DiXuOh8iETZFhj1d141F9137o4N-JUA%40mail.gmail.com.

--

勇気とユーモア

[dc42]

I looked at implementing S-curve acceleration profiles in RepRapFirmware well over a year ago and I did a mathematical analysis. I came to the following conclusions:

1. It's possible to implement on an ARM processor, but the maximum step rate would be reduced.

2. Assuming you keep the total acceleration/deceleration times the same, switching to S-curve acceleration is worse for exciting low-frequency ringing, which is the predominant issue in 3D printers because of the mass of the print head and the elasticity of the belts and motors. If the main problem is high-frequency ringing, then S-curve acceleration is better.

I also feel that there is no point in implementing S-curve acceleration for 3D printer applications unless at the same time you eliminate the instantaneous speed changes needed between the movement segments when forming an arc from linear segments ("jerk" or "junction deviation" in 3D printing language). However, for pure travel moves (which I think is all you ever have in OpenPnP), this isn't a consideration.

Following my analysis, I left S-curve acceleration on the "to be implemented" list, but I lowered its priority. Meanwhile I implemented Dynamic Acceleration Adjustment (DAA), which (unlike S-curve acceleration) is effective at countering a low-frequency resonance, but only at a single frequency. See https://duet3d.dozuki.com/Wiki/Gcode#Section_M593_Configure_Dynamic_Acceleration_Adjustment.

I don't have enough experience to know whether low- or high-frequency resonances are the predominant issue in OpenPnP; but in mechanisms using using belt drive I would be surprised if low frequency ringing wasn't the bigger issue.

By "high frequency ringing", I mean ringing where the period is lower than the time spent accelerating or decelerating. By "low frequency ringing" I mean ringing where the period is greater than twice the time spent accelerating or decelerating.

[Arthur Wolf]

If anyone has several resonance issues, a note from my experience with large laser cutters ( belt-driven, heavy head, similar to large pnps ), a very efficient counter to resonance ( ignoring increased micro-stepping, 3 or 5 phase motors etc, which do help ), is mechanical, that is using fly-wheels/dampers.

Each time I added one for a customer, the difference was very noticeable ( so much it was surprising ).

This is also a very old trick that I've seen done in machines all the way back to the 70s ( when many machines couldn't do much better than half-stepping ).

https://www.cnczone.com/forums/stepper-motors-drives/30941-making-harmonic-dampers-flywheel-motors.html

Skipping frequencies is also very effective ( I'm not sure if David is doing skips or something fancier ). I did a dirty version of that for a customer by hacking Smoothie's code ( not an actual feature, just butchering the code ) a few years back, and I can confirm it helps a lot.

I noted that skipping multiples of a frequency, instead of just a single frequency, worked even better ( at least in the single setup I tested this in ).

Ended up removing the hack and fixing the issue with flywheels for that customer too.

--

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e2ccb82-48ff-4672-a720-e4040a8771f9o%40googlegroups.com.

--

勇気とユーモア

[ma...@makr.zone]

Hi dc42

The major problem (AFAIK) in PnP are vibrations of the head and attachments. The speeds and accelerations are so high that the whole rig starts to bend and swing (we're talking DIY mechanics here). Often machines are also badly misbalanced (like my Liteplacer) but even for better construction, some of that imbalance is unavoidable with the drag chain unrolling etc. 

You see some of the bad effects here:

https://groups.google.com/g/openpnp/c/bEVZvYoXO98/m/hl14FcspBwAJ

I guess there are some (low) resonant frequencies in the construction and I also started to think about actively cancelling these frequencies. I guess one could do a (damped) integral over the past acceleration and inverse-feed it back into the motion planning.

For now, I'm exploring adding some Jerk control from OpenPnP for controllers that don't have it. OpenPnP plans full 3rd order ramps i.e. the full 7 segments including constant acceleration segments (not the simplified rigid "S-curves" of some controllers, those get slower and slower in the longer moves, which are so important for OpenPnP). The moves planned/predicted by OpenPnP are then interpolated into small segments of constant acceleration, shaped to simulate Jerk control (and other types of advanced motion control, like motion blending in the future).  Obviously this does not create fully smoothed ramps but a nicer-that-a-trapezoid-looking velocity ramp is approximated (like a polygon).

Just uploaded a new video of the effects on fluids and springs:

https://youtu.be/6vo3OwGte3c

I think some jerk control is needed. But it isn't the silver bullet. Also, it must work with look-ahead planning i.e. solutions with entry/exit velocity/acceleration 0 are unacceptable, IMHO.

My planner is intended as a future starting point for implementation in a strong MCU. I was carefully preparing it for a C++ port, i.e. simple array data, no dynamic memory, etc..

It can now do single moves, with any entry/exit conditions, including uncoordinated moves, i.e. going through corners smoothly, overshoots and blends etc. But it can't do multi-move optimization, i.e. can't find the optimal junction velocity and acceleration for the overall path yet.

https://github.com/markmaker/openpnp/blob/test/src/main/java/org/openpnp/model/MotionProfile.java

Note, that once that is working, there is no longer a need for hacks like "junction deviation" etc.

I would be willing to try to integrate that into Duet3D, once it is ready. Like I said, this will only work on a strong MCU like Duet 3.

I haven't really explored Duet step generation yet, but my thinking goes into pre-calculating pulse-buffers ahead of time. There is enough RAM now. I'm sure there are powerful algorithms that can dither those curves into pulses very efficiently when done for many cycles at a time and in advance. The pre-recorded pulses would then ideally be pushed out by DMA (RAM to GPIO), i.e. perfectly clocked/no nasty real time constraints. Or at least by a very dumb and quick IRQ.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e2ccb82-48ff-4672-a720-e4040a8771f9o%40googlegroups.com.

[Arthur Wolf]

On Wed, Sep 2, 2020 at 11:39 PM ma...@makr.zone <ma...@makr.zone> wrote:

Hi dc42

The major problem (AFAIK) in PnP are vibrations of the head and attachments. The speeds and accelerations are so high that the whole rig starts to bend and swing (we're talking DIY mechanics here).

I think this is a good opportunity for a PSA we should make a from time to time:

If this is your first CNC ( laser, pnp, cnc mill, etc ) build, and you are designing the machine yourself, in my experience 95% of users later regret not building sturdier.

It's better to have your machine be a bit too heavy ( making it a bit slower on accel, which isn't as important with pnp as with other machines as a lot of your time is spent making long moves ) but rock-solid in terms of accuracy/absence of shaking.

Get some thick aluminium or steel tubes or t-slot-bars, and whatever your instinct is telling you to size them, double or triple it. At least design it so it's easy to replace your structure with something sturdier.

I talk to a lot of people building machines, often new/weird types of machines ( innovating, proofs of concept etc ), and lots of the time am able to follow the project from beginning to end.

I hear people complaining they should have made their machines heavier/sturdier ( including pnps ) so often, I just spill out this PSA any chance I get :)

 

There are good reasons why industrial machines are so heavy, and use welded stell for the structure.

Sorry for the bother if you already knew.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b97548eb-bf90-ffed-3048-6a83945d0b6e%40makr.zone.

--

勇気とユーモア

[ma...@makr.zone]

New video link, had to delete the old ... forgot to delete the audio :-].

https://youtu.be/cH0SF2D6FhM

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b97548eb-bf90-ffed-3048-6a83945d0b6e%40makr.zone.

[ma...@makr.zone]

>There are good reasons why industrial machines are so heavy

I agree.

But: wouldn't it be even cooler, if we could drive a cheap, bad rig so "intelligently", that at least some of the problems vanish?

:-)

Consider how these huge building cranes haul stuff. They're the antithesis of rigid. But if you watch them, you see how incredibly efficient the are. They deliberately decelerate early, let it swing to target and then just quickly counter-act the pendulum (don't really know how to describe, but I guess you know what I mean). With a good operator, the payload stays right over the target. Incredible. A bit of that built into a controller would be veery nice.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAMHZkm6kexX1TOMsR5kstow7oFG0-kRdQnn%3DgUdyuEty3vPXKg%40mail.gmail.com.

[Arthur Wolf]

Sure, was definitely not advocating for ignoring software fixes just because there are also hardware ones.

S-curve can definitely help with heavier stuff, it's pretty much just closer to the laws of physics than simple acceleration is.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8a353b16-b7ee-3d6f-4669-dc0510d5242f%40makr.zone.

--

勇気とユーモア

[Harjit Singh]

Mark, I didn't follow what you were showing in the new video link. Particularly, the relationship between the component position jogging and the different motion profiles being applied to bottles.

In this thread you talk about smoothieware and S-curves but it seems you are adding S-curves to OpenPNP so that we can use any controller i.e. Smoothie or Marlin or ?? and get the benefit. Or am I mistaken?

Thanks for your efforts. Your notes are very well written and very informative.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6b7e2048-75fa-6faa-17b3-1bb08eb0d696%40makr.zone.

[ma...@makr.zone]

> In this thread you talk about smoothieware and S-curves but it seems you are adding S-curves to OpenPNP so that we can use any controller i.e. Smoothie or Marlin or ?? and get the benefit.

Yes that's exactly the idea. OpenPnP predicts the motion with full 3rd order (Jerk) control then interpolates it on a constant acceleration Controller. I found that would be most useful to all those people (including me) that don't want to rip out a controller and rewire the machine.

The move is split into many small segments and the allowed acceleration is then stepped up and down, approcimating what it would be with Jerk Control.

Just to avoid misunderstandings: this is just one possibility for the new MotionPlanner in OpenPnP. It could also send the commands directly to a true 3rd order motion controller, and that would obviously be a much better solution. Or you can switch back to constant acceleration if your machine is very stiff (unlike mine).

You will have the choice:

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAEm8oEQQhSNp9iS9CeeunYLPxzvPOu_V6fX3oVYqQXjg6eTgWA%40mail.gmail.com.

[Arthur Wolf]

If you turn this host-side s-curve code into a library, this can be used in 3D printing software like Slic3r and laser software like Visicut, with great benefit, by the way. Could even work with Fusion360 if it was rewritten in Javascript and put in one of their post-processors.

Note there's unit-testing code for Smoothie that ( I believe ) allows testing Smoothie's planner without a physical board, so if you want to do unit testing of your code, this would enable you to do it without requiring running your gcode against an actual board, tell me if you need more info on this.

If you've got any interest in going into the library route once you have this working, tell me and I can very likely find both testers and contributors/helpers for the effort.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/137ec2b5-7db3-8c0e-c86c-2a29f01fddff%40makr.zone.

--

勇気とユーモア

[ma...@makr.zone]

Hi Arthur

> If you turn this host-side s-curve code into a library, this can be used in 3D printing software like Slic3r and laser software like Visicut, with great benefit, by the way.

Note that this is still work in progress. Single moves work, but multi-move optimization is unfinished. I want the true 3rd order optimum (i.e. with acceleration != 0 in junctions) and this is a tough nut to crack. There are simplified approaches for OpenPnP's simple move patterns (and I will soon have a solution there), but a general solution (e.g. for 3D printing or even true 5-axis CNC) seems far away.

But it's all open source ;-) and mostly in one file. Tried to make it simple to port to C++.

>Note there's unit-testing code for Smoothie that ( I believe ) allows testing Smoothie's planner without a physical board,

Good to know. At the moment, the

testing focus is on the actual timing when run on the board with all the other stuff (interrupts, command processing, USB comm etc.) happening at the same time. So the board is needed, I think.

One thing I wanted to ask: how do you tune the config.txt planner_queue_size to the maximum?

I tried 64 (didn't boot), then 48 (seems to work). But these are just wild guesses. Any hints?

I used the mem console command:

Unused Heap: 864 bytes
Used Heap Size: 25472
Allocated: 20076, Free: 3900
Total Free RAM: 4764 bytes
Free AHB0: 9556, AHB1: 10440
Block size: 88 bytes, Tickinfo size: 280 bytes

But no idea what is "enough" free space.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAMHZkm5L3BvaFKL%3DAASXOb13%3D2PkZq5CYO-%3D6jYA9_F89qdJQA%40mail.gmail.com.

[Arthur Wolf]

On Sun, Sep 6, 2020 at 11:00 AM ma...@makr.zone <ma...@makr.zone> wrote:

Hi Arthur

> If you turn this host-side s-curve code into a library, this can be used in 3D printing software like Slic3r and laser software like Visicut, with great benefit, by the way.

Note that this is still work in progress. Single moves work, but multi-move optimization is unfinished. I want the true 3rd order optimum (i.e. with acceleration != 0 in junctions) and this is a tough nut to crack. There are simplified approaches for OpenPnP's simple move patterns (and I will soon have a solution there), but a general solution (e.g. for 3D printing or even true 5-axis CNC) seems far away.

But it's all open source ;-) and mostly in one file. Tried to make it simple to port to C++.

>Note there's unit-testing code for Smoothie that ( I believe ) allows testing Smoothie's planner without a physical board,

Good to know. At the moment, the

testing focus is on the actual timing when run on the board with all the other stuff (interrupts, command processing, USB comm etc.) happening at the same time. So the board is needed, I think.

One thing I wanted to ask: how do you tune the config.txt planner_queue_size to the maximum?

I tried 64 (didn't boot), then 48 (seems to work). But these are just wild guesses. Any hints?

You're doing it right. If it's too high you'll run out of RAM either at boot or when playing a file. If you don't, the size is safe, if you do, you need to reduce it.

The mem command doesn't really help there.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/bc3a2a1c-5cb2-0d31-e401-9839fe71e47d%40makr.zone.

--

勇気とユーモア

[Andreas Axelsson]

I have done a custom firmware for the CHMT36VA machine (it runs on an STM32F407) which implements jerk-limited motion (S-curve type). Synchronizing axis movement is normally quite hard, but since I only move in straight lines with zero velocity in start and stop it was quite easy. I just create a virtual axis of the hypotenuse of the movement in the different axis and then project the movement on each axis and generate step pulses that is in sync with the virtual axis.

Look at the blue liquid in the clips below as the head moves back to left side.

Original firmware:

https://youtu.be/TvhZLREQ0PU

Jerk-limited-firmware:

https://youtu.be/DskvMlGy1-g

[bert shivaan]

that looks great!!

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a23b4351-84dd-459e-8542-b2cae9d7b0f5n%40googlegroups.com.