Common changes:

  • Smooth motion when increasing feed value during printing process.
  • "Temperature lock during printing" feature implemented.
  • New "Temperature on/off" function during print added. Takes effect if you bring down the temperature under the minimum 120°C
  • Linear advance (M900 K or A D) feature.
  • If there are no known characters in the file or path, a message appears on the LCD screen.
  • Smooth jogging in X Y Z axes.
  • It is now possible to use SPACE character in file names.

CB2

  • New error detection implemeted for TMC2208 driver.
  • Overtemperature error message(predator v3.1t only).
  • Short-circuit error message(predator v3.1t only).

CB3

  • G2, G3 Controlled arc move implemented.
  • TMC2130 temperature preWARNING message and pause during print.
  • TMC2130 overtemperature error message.
  • TMC2130 short circuit error message.
  • The XY position changed in "Z-axis calibration".
  • The XY position changed in "Encoder calibration".
  • The date displaying is now fixed.
  • Support the standby temperature feautre of the next CW version.

January 7, 2019

Janos Janos
Admin
521 posts

21 replies


Does the old linear advance parameter still work? Has the actual implementation changed?

Please improve info in these changelogs, the description for each change needs more detail. I will of course test the firmware, but knowing what each change actually does (or is supposed to do) is helpful.

January 7, 2019

mroek mroek
Revered
509 posts

I've loaded the firmware now on the CB2. I really appreciate the improved jogging, as that is something I have asked for, but for X and Y I think it could have been even smoother (a bit softer starts and stops). For Z it is perfect now.

I haven't printed anything yet, but I still want to know more about the changes. I can see the temperature lock function, but what is the "temperature on/off" during print? And under what circumstances is "motion now smoother when increasing feed value"? What kind of motion (jerk?) , and what speeds?

And as mentioned. please say more about linear advance. You used the M900 command, which is what Marlin uses, but then you have different syntax? A, D or K? What does that actually mean?

January 8, 2019

mroek mroek
Revered
509 posts

Hi mroek,

The old linear advance is still there, implementation was not changed.

The new one is using M900 because it is acting the same way as the Marlin's linear advance: It increases the acceleration and deceleration values for the extruder, according to the XY movement acceleration/deceleration.
For normal usage "M900 K.." is advised, setting the K-factor value.
"M900 A... D..." is non-standard, and is for experimental usages. "A" and "D" stand for acceleration and decelerations, so you can set different factors for acceleration and deceleration.

I'd recommend using the "M900 K.." for linear advance as it is more compatible with other printers and firmware.
Mixing the old and new linear advance is not recommended. You can try it, but we haven't tested it yet.

Temperature can be turned off during print by decreasing the temperature below the minimum, and then "--" will appear there. It can be turned back on by increasing the temperature.

"Motion smoother when increasing feed" is happening when during printing you increase print speed. The faster printing is now more smooth than in previous versions of the firmware, even with max speedup.

Regards,
Norbert

January 8, 2019

NorbertF NorbertF
Admin
132 posts

Norbert, thanks for the explanation.

I did a small test on my machine with the new M900, and it appears a K value of 9 gives me the best result. With the M1210 implementation, the scale is different, and a value of 0.45 looks about right on my machine.

January 9, 2019

mroek mroek
Revered
509 posts

Yeah, for me K10 was also good with PLA at 215 degrees.

The two implementations work on very different principles, and "K" is just a constant factor that you give into the agorithm.
I saw that in Marlin in linear advance 1.5 they modified it to work more like a standard unit.
IMHO we should also modify ours to use that so we can be fully compatible.

Until then we can play around with this one, and start to integrate into CraftWare as well.

Regards,
Norbert

January 10, 2019

NorbertF NorbertF
Admin
132 posts

Yes, I also wondered why you opted to use M900, and then don't scale to values similar to what the newest Marlin uses. I agree you probably should make it more compatible with Marlin, which should be quick and easy.

Do you believe this implementation will give better results than the old one? In the "synthetic" test used by Marlin (I adapted that to test also with M1210), both implementations can get a near perfect result. However, in a real world print, they may well differ.

January 10, 2019

mroek mroek
Revered
509 posts

I'll be nagging the firmware guys to make M900 fully compatible with Marlin's K-values. :)

I don't know if this implementation is better than the other. Marlin's test is too simple with its straight lines. Psanyi's K-factor test gcode is also a nice thing, but that focuses on one shape as well.
Maybe if there would be a complex test gcode generated to find out the effect in all kinds of situations, that could help seeing what is what.

Using the Marlin's way is maybe good because it is used now in most printers. Of course making a way better stuff would be better, but first be compatible.

One thing is sure: The physical stuff is way more complex than the linear advance algorithms that try to negate it, so there is surely room for improvement.
There are already discussions about this, for example:
Linear Advance 2.0 discussion for Marlin

January 15, 2019

NorbertF NorbertF
Admin
132 posts

Did something else happen to the kinematics in this firmware?

I am not happy with how the printer moves when it is printing small circles at normal speeds. Since circles are comprised of a gazillion small straight segments, it sounds (and feels) to me like the printer is vibrating quite a lot.

Here's a short video that clearly showcases the issue:



It is entirely possible that this is not new, but I feel strongly that this needs to be addressed. My cheap Wanhao printer is a lot smoother than this. In the worst section in the video, the printer is really resonating and vibrating.

To make this easier for you to investigate, here's a link to the G-code from the above video. It runs for a couple of minutes, so it's a quick test.

Please note that while the extruder is running in this file, it has been designed to NOT actually print anything (it even starts running 1.2 mm above the build plate). Fans are turned off (to not muddy the sound), and nothing is heated. So in other words, this file is designed to be used without filament loaded in the printer. If filament is loaded, the extruder will just chew on the filament (and skip continuously).

January 20, 2019

mroek mroek
Revered
509 posts

Agreed - doesn't sound right.

January 20, 2019

ruggie ruggie
Friendly
124 posts

Those are sure small, but "circles" is a matter of opinion :-) They are 32 sided polygons in fact, meaning there is a turn of 11.25 degrees at every corner, so the head spends most of it's time accelerating and decelerating because it has to satisfy the F parameter in the M1203 command.

New firmware released: CBP/CB2: 12290 and CB3: 15705

And the maximum turn, where there is no acceleration is this:

angle = acos(1-0.5*(minF/F)*(minF/F))

For the F3600 speed and the default F240 parameter the maximum turn is 3.82 degrees, that is 95 sides minimum.

You can try M1203 F900, that gives 25 sides minimum. Or you can try M1203 F3600 for giggles :-)

I use 180 sides usually.

January 21, 2019

psanyi psanyi
Exalted
923 posts

Thanks for the explanation, psanyi. I agree that they are not "circles", but it's what the slicer gave me (in this case S3D).

Running with M1203 F900 it definitely goes smoother in the circles, but it jerks more violently when it moves between circles. At M1203 F3600 it does become even smoother, but the very small moves between circles then jerks even worse.

January 21, 2019

mroek mroek
Revered
509 posts

mroek wrote:Running with M1203 F900 it definitely goes smoother in the circles, but it jerks more violently when it moves between circles. At M1203 F3600 it does become even smoother, but the very small moves between circles then jerks even worse.

Yes, unfortunately it is a tradeoff. The "giggles" part was just for test, that switches off acceleration under F3600. Maybe your Wanhao uses some different rule for corners, I do not know. The CraftBot uses this "speed vector difference" limit, but one can imagine a other rules for how much to slow down for different turn angles.

I've recently switched to M1203 F600 after some testing. If you increase that F you get more noise and ringing at corners, but less problems with the varying extrusion speed and the total print time decreases slightly.

23 hours, 5 minutes ago

psanyi psanyi
Exalted
923 posts

I still don't understand why acceleration and deceleration makes for more rough movements in my "circles".

If the minfeed is at the default of 240, it means that the printer tries to accelerate and decelerate at each of those polygon segments, and given that they are very short, I can easily imagine that it doesn't really manage to actually do any acceleration or deceleration, but why should that cause it to become so extremely jerky?

Upping the minfeed value allows it to just change direction without trying to do any acceleration or deceleration, which in theory should make it jerk more. However, it does the opposite, so something seems off with the acceleration and deceleration methodology.

The only way to get "circles" better is to increase the minfeed, but that makes the small jumps between the circles a lot more more jerky. Those are travel moves, so reducing travel speed in the slicer might fix that, but that will make many prints take a lot more time.

I don't know exactly how the Wanhao does this, it is running the original firmware, which is a Repetier variant. I just know it behaves a lot better than the CB.

22 hours, 23 minutes ago

mroek mroek
Revered
509 posts

I did some more testing, and by lowering the acceleration values, it will also become significantly smoother, even if the minfeed is kept at 240. For example:

M1203 A1000 D1000 F240

However, that will also slow down prints in general, so it's not really a good solution.

I am still not understanding why the default acceleration values gives that extremely rough movement compared to increasing minfeed so that acceleration doesn't kick in at all. That should in theory make it even worse, I'd think. Is it possible that something goes wrong with the calculations, so it instead ends up with absurd values?

20 hours, 57 minutes ago

mroek mroek
Revered
509 posts

mroek wrote:I can easily imagine that it doesn't really manage to actually do any acceleration or deceleration, but why should that cause it to become so extremely jerky

Because it accelerates to the midpoint of the segments with 0.2g, then decelerates with 0.2g to the next corner. And as it does this at regular intervals, you can run into resonances. It tugs the head back and forth all the time.

I've checked this on my own printer whith a logic analyzer attached to the stepper controls and I'm sure there is no other funny business aside from this triangle pattern in the acceleration.

20 hours, 56 minutes ago

psanyi psanyi
Exalted
923 posts

Ok, I believe you. But then I think perhaps that there should be some minimum segment length for acceleration to be applied. In other words, for segments shorter than this set length, the firmware should not even try to apply acceleration.

20 hours, 49 minutes ago

mroek mroek
Revered
509 posts

Yes ,I think this acceleration part need some upgrade too. I like this discussion from the TinyG CNC controller github page.

20 hours, 37 minutes ago

psanyi psanyi
Exalted
923 posts

That looked like a well executed strategy. It would be very nice if CU could implement something similar, but in the mean time, I think that adding a limit (can probably even be hardcoded) to how short segments will have acceleration applied would be a simple and quick fix for the issue I'm complaining about here.

20 hours, 16 minutes ago

mroek mroek
Revered
509 posts

Sure, but as I've recently been kicked out even from the Github repository, I cannot help you with that. Maybe NorbertF relays it to the current developer(s).

19 hours, 24 minutes ago

psanyi psanyi
Exalted
923 posts

@NorbertF: Can you please reply here (so we know you're reading), and also give a shout out to the FW developers that this issue needs some quick TLC?

And at the same time, could you ask to have a tiny bit softer acceleration added to jogging in X and Y? Z is perfect now, but X and Y could use a tiny bit less jerk when jogging.

19 hours, 18 minutes ago

mroek mroek
Revered
509 posts

Hi,

Sorry for not replying, I'll get through this more intensively, now I just read through quickly at the end of day. Work, work.. :)

But until then very short answer: I'll definitely talk about all these with the FW guys, because now I'm sitting in the very same area, few steps away.

Regards,
Norbert

17 hours, 5 minutes ago

NorbertF NorbertF
Admin
132 posts
To start a discussion or reply to a post please Login or Create an account.