Do we know what release will have variable support?

I've been getting into customizing various aspects of my printer, and in a few scenarios variables are pretty much mandatory.

Are we looking at 3.2, 3.3, something even further out?

@dc42 I don't know how you keep your cool, You must have the patients of a saint.

As a developer, I'd most likely end up in a physical altercation, if I had to deal with some of the garbage people regularly throw your way.

1. Home the axis using kown safe values.
2. move to the other extreme of the axis using kown safe values.
3. Using experimental values to move back close to the home position, but not all the way back (say 10 to 20mm shy)
4. use the known safe settings again to go home.
5. check the endstop status to see if you are homed.

if you are, you can increase your settings and run the test again. If you aren't then you missed steps, so cut the current values down by whatever safety margin you want and you will have your maximums.

make sure you run each test several times before moving on to higher values.

Here is an example i used for a core xy machine.

G21
G90
M82
; move to position slowly
M201 X250 Y250 Z100 E1500        ; Accelerations (mm/s^2)
M203 X6000 Y6000 Z900 E3600      ; Maximum speeds (mm/min)
M566 X200 Y200 Z100 E1500        ; Maximum jerk speeds mm/minute
G28 XY
G4 S2
G1 X280 Y280 F3000
G4 S2
M400

; rapid back fast
M201 X4500 Y4500 Z100 E1500        ;accel
M203 X24000 Y24000 Z900 E3600    ;speed
M566 X1500 Y1500 Z100 E1500        ;jerk
G1 X10 Y10 F13500
G4 S2
M400

; go home again slow
M201 X250 Y250 Z100 E1500        ; Accelerations (mm/s^2)
M203 X6000 Y6000 Z900 E3600      ; Maximum speeds (mm/min)
M566 X200 Y200 Z100 E1500        ; Maximum jerk speeds mm/minute
G1 X0 Y0 F3000
G4 S2
M400
M119

@gloomyandy said in no keep alive support?:

I'm not sure if DWC makes use of this feature but I suspect it may for some of the more frequent operations.

DWC/Chrome is asking for it. request header "Connection: keep-alive"
however the server always responds with a response header "Connection: close".

I have yet to see it allow keep-alive.

(for more details see: https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L448).

If i read that properly the code already has everything it needs to handle persistent connections, as it's inspecting the request headers in HttpResponder::SendJsonResponse

see line 986 through 999
https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L986

however when HttpResponder::SendJsonResponse calls HttpResponder::GetJsonResponse the first thing it does it set keepOpen = false;

https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L450

so the if statement that starts on 987 never gets run.

assuming i'm reading this properly, I haven't worked with c/c++ in almost 20 years.

@deckingman said in Whats does the roadmap look like for variables?:

@pixelpieper This isn't a matter of which new features should take priority. This is a case of restoring basic functionality that already exists in version 2 firmware to version 3 firmware before adding new features.

I'm a developer by trade i think you need to consider a few things!

• Just because a piece of software functionality worked on one piece of hardware doesn't mean it will work on another with different architecture.
• I'd be willing to bet their are substantially more v2 boards in the wild than v3, so the wants and needs of v2 users will most likely take precedence.
• Some of the new features might make it easier to fix outstanding issues. On several occasions i have done this, mainly because it involved rewriting a sub system from scratch.
• From what I can tell, your use case is very much and edge case, so you should expect issues imo.

@gloomyandy said in Simple way to set Acceleration and Jerk?:

Will the motor basically start at the jerk speed and then use the acceleration values to increase speed from that point to the target or is it more complex than that?

@dc42 might be able to give a better answer, but I would say the above is a good straightforward way of looking at it.

If using a CoreXY type design would it make sense to perform the tests using diagonal moves (which just use a single motor)?

Imo, yes, that's what i did in the script above for my Core-XY.

@deckingman said in Whats does the roadmap look like for variables?:

I'll bear that in mind but I suspect anyone who bought the latest generation of a product such as a 'phone would be somewhat miffed if many of the bundled apps (which worked on the previous version and are still bundled with the new version), didn't work.

The underlying hardware architecture for phones hasn't changed in a long time though. I think almost every phone on the market is based on ARM. If the next generation was x86 based, people would go mad because all kinds of things would break.

If people don't want to deal with issue, then they shouldn't be an early adopter. Doesn't matter if it's phones, sbcs, tvs, cars etc.

@CaLviNx said in Whats does the roadmap look like for variables?:

As a user I expect the "evolution" equipment (that I have paid for) to "fit for purpose" its not as if the end user is forcing the supplier into supply, but the supplier does use the "evolution" features to entice existing (and new) users into making a purchase.

No one is forcing you to buy it, and it's on you if you fall for a sales pitch, or can't control your consumerism!

For reference here's Marlin's equivalent to Klipper's touch mode.

https://www.youtube.com/watch?v=95N2E6JVW2s

I've not looked into it, but i know one member of the RailCore Community has, and he felt to properly/safely handle touch mode, error/alarm handling as it relates to probing would need to be reworked.

@Phaedrux said in Mesh probe movement optimization:

180mm/min is about the limit for the BLtouch. It's pretty sensitive to speed.

I was able to get up to 300, but above ~220-240 repeatability started to suffer. If memory serves above 270 I had to start increasing the drop height or I'd get

Error: Z probe already triggered at start of probing move 

errors.

@dc42 said in Mesh probe movement optimization:

@DanS79, I think the real reason for Z probing being so slow for you is that your probing speed of 180mm/min is so low. Does it need to be that low? Have you calculated the contributions to the probing time of the probing movement, the Z raise movement, and the XY movement?

This is the default railcore config, and it would take roughly an hour and 40 minutes to finish generating the mesh for the M557 i posted above.

M558 P9 X0 Y0 Z1 H5 F50 T6000 A5 S0.02  

I didn't run every possible permutation, but I decreased the drop height and increased the travel speed between points and the probing speed till I started to see a degradation in repeatability. 180 seemed to be a good compromise between speed and me worrying about crashing the machine.

@Phaedrux said in Mesh probe movement optimization:

@DanS79 said in Mesh probe movement optimization:

Something like Klipper touch mode would be a nice feature to add that would speed up probing regardless of how many points are being probed.

There actually was a post a while ago about getting that touch mode setup.

https://forum.duet3d.com/topic/14544/guide-to-marlin-s-fast-bltouch-probing-feature-on-duet?_=1615322157391

I'm aware of that thread. However @dc42's post made it sound like it wasn't advisable.

@Phaedrux said in Mesh probe movement optimization:

@DanS79 well dive speed is a bit tricky because you're then affecting accuracy. Reducing dive height to the minimum and only probing at a density that actually matters would help more. The BLtouch is pretty sensitive to dive speed. Other probe types may be less. Even so, the faster you go, the harder it is to be accurate.

I've done several rounds of benchmark and found i could go as high as 300 without losing accuracy. Though at that speed it's frightening to watch. Dive height is about as low as i can go without risking the probe not deploying in time.

Something like Klipper touch mode would be a nice feature to add that would speed up probing regardless of how many points are being probed.

It would be really nice if something could be done to speed up probing.

for example,

If I generate this mesh

M557 X10:290 Y45:290 P21:21

with these settings

M201 X4500 Y4500 Z250 E1500                           ; Accelerations (mm/s^2)
M203 X24000 Y24000 Z1500 E3600                        ; Maximum speeds (mm/min)
M566 X1500 Y1500 Z120 E1500                           ; Maximum jerk speeds mm/minute
M558 P9 X0 Y0 Z1 H2.5 F180 T12000 A5 S0.02

It will take 16 minutes and 38 seconds to complete.

A substantial portion of that time is waiting on the Z moves. Upping the M558 Feed Rate above what it already is, doesn't accomplish much as it's already well into the realm of diminishing returns.

Keep in mind that this is a mechanical, fluid dynamic, and thermal dynamic problem.

If you increase extrusion rate, then one one or more of the following needs to change.

• increase the hot end temperature
• lower the part cooling fan speed
• increase the nozzle diameter

the extrusion/flow rate multiplier (slicers have various names for it) is nothing more than a fudge factor that allows you to make a tweak without changing one of the above.

Calculating your e steps at 1 mm/s will minimize the the fluid dynamic and thermal dynamic variables at play.

If you want to completely remove fluid dynamic and thermal dynamic variables, disconnect the extruder from the hotend. That way the only thing you're dealing with are mechanical variables.

@Oliver_Briggs

Did you try the the resistor that comes with the daughter board?

@deckingman said in Easier to use Software:

@DanS79 said in Easier to use Software:

............. The ones that complain the loudest are usually the ones that want to be on the bleeding edge.

Yes this accusation keeps getting levelled at me - basically it's all my fault for having a complex machine.

If I was referencing to you specifically, I would just call you out by name.

@zapta said in Easier to use Software:

I believe that one good strategy is to separate between a stable version, even if it's a year old, and a bleeding edge one that covers the big leap from a stable 2.x to a stable 3.x.

It will provide latest and greatest to users that want and can take risks, a pool of testers for the developers, and stability for the users that need it. It will also reduces the pressure on the developers to get it right and fast, and will bring peace and harmony to the Duet community.

My 2c.

This will work for some people, but as a developer I can tell you it almost never works with those that complain the loudest. The ones that complain the loudest are usually the ones that want to be on the bleeding edge.