Abilty to graph additional metrics, specificly flow rate and speed.

[joecasa]

I think it would be very useful to be able to chart arbitrary values with basic custom annotations. For instance, I think the maximum flow rate of my printer is 16 mm3/s. A plot with both flow rate and speed on the y axis and time on the x axis with a dashed horizontal threshold marker at 16mm3/s would help me to see if print speed is causing under extrusions.

[Biorn1950]

Hello,

From my experience he best and certainly only way to see the impact of the flow rate is to use the tools in the slicer. SuperSlicer is IMO a good one to analyse flow impact.

[StuSerious]

hey there @joecasa!

adding graphs to plot speed and flow would definitely be cool!

I'll take this up with the team and get back to you!

~S

[joecasa]

thanks for taking a look at my request! i figured it was the kind of thing that could be added pretty easily and would provide a lot of utility to folks who are trying to optimize their prints. in regards to what @Biorn1950 said:

Hello,

From my experience he best and certainly only way to see the impact of the flow rate is to use the tools in the slicer. SuperSlicer is IMO a good one to analyse flow impact.

it's true that some slicers can provide this information but a lot of them don't. plus, i think it would be very handy to be able to watch the impact live as the part is printed rather than trying to do forensics on a part after it's printed. finally, it would also be a unique feature that could set fluidd apart from the other UI options out there.

[Biorn1950]

@StuSerious this is completely useless since we don't have a real-time report and we cache the data for 1 seconde. So you'll just get incomplete data. and faster you'll print more error you'll get.

@joecasa if you want to see better estimate data you can use this new tool which the math are based on klipper

https://github.com/Annex-Engineering/klipper_estimator

[joecasa]

One second lag is just fine! It doesn't need to be instantaneous.

On Mon, Jan 31, 2022, 1:47 PM Biorn1950 @.***> wrote:

@StuSerious https://github.com/StuSerious this is completely useless since we don't have a real-time report and we cache the data for 1 seconde. So you'll just get incomplete data. and faster you'll print more error you'll get.

— Reply to this email directly, view it on GitHub https://github.com/fluidd-core/fluidd/issues/454#issuecomment-1026194615, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOJ5V7T4GFURF7DUUFKQLTUY3YOLANCNFSM5JLOLMHQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[Biorn1950]

tbh, I still don't understand how dealing with wrong data could help to improve the print. You won't have the good/real speed and flow. never

[Cimsweend6]

i second this. ended up signing up to github just to put my name on this "request list" x)

the more accurate you can present a graph the better. it's the peaks im (we´re) looking for. if the graph leaves them out it might not answer why the extruder is skipping. i for exmple ended up here because my printer can do 25mm3/s flow when going steady, but somehow skips steps in the extruder on much lower meby due to PA or something, would need to se exactly if there is a peak in "input flowrate" to the stepper.

[invidtiv]

It would be great to have those graphs, even if they only show up after printing, and not realtime, this would help diagnose quite some issues especially after a failled print. The slicer approach is diferent than raw data analysis.

[matmen]

A live view definitely is possible here, with an update rate of 250ms. Looking at my PA smooth time (40ms) this probably won't easily show problems with PA, especially because the data seems to be a bit noisy:

Unfortunately, I don't think a higher data rate is possible as of now (Klipper limitation). Over all the graph might be able to help though.. I'll take a look at the noise/variation and a clean implementation in the next couple days.

Edit: Instead of calculating the extruder velocity ourselves, we can use Klipper's motion_report extruder velocity, which delivers noiseless measurements: The data rate limitation still remains, however. Also, I'm not sure if this would show short, high velocity moves or just the velocity at time of sampling. My previous approach would also show these because it was using the absolute extruder position.

[matmen]

I have tested this for the last two days, but neither approach seems to be delivering the resolution I would want (short, fast bursts don't show up reliably). Overall I think this is a useful feature, though, so I am going to implement this using live_extruder_velocity (smoother data).

[joecasa]

Awesome! Thank you so much for working on this!

On Sat, Jul 23, 2022, 7:09 AM Mathis Mensing @.***> wrote:

I have tested this for the last two days, but neither approach seems to be delivering the resolution I would want (short, fast bursts don't show up reliably). Overall I think this is a useful feature, though, so I am going to implement this using live_extruder_velocity (smoother data).

— Reply to this email directly, view it on GitHub https://github.com/fluidd-core/fluidd/issues/454#issuecomment-1193123128, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOJ5VZM7BEGIVAXBOAYFPLVVPVG3ANCNFSM5JLOLMHQ . You are receiving this because you were mentioned.Message ID: @.***>

[matmen]

We're considering adding a diagnostics page this would then live on - are there any other stats that would make sense on there? The charts can be zoomed and panned just like the temp charts. cc @pedrolamas @BastelKlug

[pedrolamas]

Looking good!! 🙂

[joecasa]

I think that it would be ideal if the user could plot speed and flow on the same graph. That way you don't have to guess if two events line up.

Let me start by saying that I don't know enough about how any of this is written to understand how big of an ask the following suggestions are. Sometimes things like this are real easy, and other times virtually impossible. I'm just suggesting this stuff in hopes that it's the former.

Regarding extra things to plot, I think it would be incredible if you could flip a switch and then see the gcode line that was active at the time where the cursor is hovering over the graph. Then you could see what caused the event. I say you need to flip a switch for it because you'd probably have to load the whole gcode file (just like when you watch the live gcode viewer). I don't think you'd have to have the whole gcode line appear under the cursor (in the graph field). Instead, you could just have a text field under the plot that populates with the gcode command that corresponds to the cursor location where the user is hovering. I know that's a lot, but it would be super helpful.

Ideally, the graphing mechanism would be generic enough to allow the user to optionally plot any variable that klipper is currently tracking (flow rate, fan speed, video fps, whatever). That way the user can decide what's most relevant to the diagnosis at hand. If the sampling rate is trash, so what - just put a disclaimer in that says some data comes faster than others and that the user should keep that in mind. Maybe this would yield plots that aren't useful in every case - but at least the tools are there for people to use. Fidelity can come in due time.

In lieu of completely generic graphing, any available variable that could be used to help with tuning would be good. Things like corner speed, current acceleration (if its variable), retraction events, etc.

In the past, I've added static horizontal lines on graphs to make it obvious when the graphed value has exceeded a certain threshold. It would be nice if the user could plot a horizontal line to represent what they think is the current flow rate limit of thier setup. This would be a nice add, especially if it was also very generic.

On Sat, Jul 23, 2022, 12:15 PM Mathis Mensing @.***> wrote:

We're considering adding a diagnostics page this would then live on - are there any other stats that would make sense on there? cc @pedrolamas https://github.com/pedrolamas @BastelKlug https://github.com/BastelKlug [image: image] https://user-images.githubusercontent.com/25269274/180617761-05e123e5-f9bf-4f6f-a6e3-1fa31880ce32.png

— Reply to this email directly, view it on GitHub https://github.com/fluidd-core/fluidd/issues/454#issuecomment-1193166819, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOJ5V3OU3CAG7CW66RZK6TVVQZDJANCNFSM5JLOLMHQ . You are receiving this because you were mentioned.Message ID: @.***>

[matmen]

Regarding extra things to plot, I think it would be incredible if you could flip a switch and then see the gcode line that was active at the time where the cursor is hovering over the graph. Then you could see what caused the event.

I'm not sure this would be a viable option, as logged points can either have one line associated, multiple lines associated or no lines associated. Another problem here would be time correlation, the motion reports come in every 250ms, no matter the state of the Gcode, and we don't know which Gcode is running at that moment (from what I can see). The Gcode preview just guesses based on the reported progress, and isn't always accurate. The only way I see that would make this possible is by using gcode_move events, but then we would be back to the same information the slicer would spit out (which can be viewed with any Gcode viewer).

Ideally, the graphing mechanism would be generic enough to allow the user to optionally plot any variable that klipper is currently tracking (flow rate, fan speed, video fps, whatever). That way the user can decide what's most relevant to the diagnosis at hand.

This makes sense, in theory we can graph anything that would be in Fluidd's state, but I think mostly values described in https://www.klipper3d.org/Status_Reference.html would be useful.

In the past, I've added static horizontal lines on graphs to make it obvious when the graphed value has exceeded a certain threshold. It would be nice if the user could plot a horizontal line to represent what they think is the current flow rate limit of thier setup. This would be a nice add, especially if it was also very generic.

This sounds like a good idea. I think having the axis editable would also be a good idea here, so you can set min/max values or format the axis yourself.

[matmen]

Also, please note that the recorded data isn't stored in Moonraker's database - it is specific to the browser session only (meaning that reloads of the page will clear the recorded history). I think writing to the DB every second (or 250ms even) isn't a good idea, especially when recording lots of data points.

[Cimsweend6]

to the diagnostics page i would say that all the printer does is of help to someone, individual stepper speed, what that sums up to in mm/s and mm3/s, rate of data transfeer maby? for 8-bit users? idk. all things that is known to be system bottlenecks and limits as to quality and speed.

and on the topic logging a graph for flowrate, as i said. the general, kind of average flowrate we can se in the slicer or as a number as the printer prints. what would be of help is a graph on the level of "virtual stepper motor", im no software guy but it seams pretty straight forward to just feed the g-code to a graph that does exactly what a stepper would do but instead of turning an axle it plots a graph. as i said, i have tried flow with bed down and on a large circle an get 25-30 mm3/s. so i slice a file that delivers say 18 max. and the stepper skipps away. i think there is peaks of flowrate in very short timeframes that just pushes the motor one step it can't go. maby pressure advance (0.5) pushes flow to peaks and therefor demands more than say 25-30 in a split second? idk. thats what i would like to se ^^.

[matmen]

to the diagnostics page i would say that all the printer does is of help to someone, individual stepper speed, what that sums up to in mm/s and mm3/s, rate of data transfeer maby? for 8-bit users? idk. all things that is known to be system bottlenecks and limits as to quality and speed.

With the suggestion of the charts being user configurable this would be no problem at all, I think mostly speed, flow, stalls as well as MCU stats would make sense for the usual diagnostics (though all properties of the state will be plottable).

what would be of help is a graph on the level of "virtual stepper motor", im no software guy but it seams pretty straight forward to just feed the g-code to a graph that does exactly what a stepper would do but instead of turning an axle it plots a graph

With the current state of Klipper, this isn't possible. We would need to re-implement all the Klipper algorithms which just doesn't make sense. AFAIK Klipper (or other parties) already supply debugging tools for this, and we will not be re-implementing those. If there was an API for this that would be great, but currently I'm afraid there isn't, and the 250ms max update rate of the motion report just won't show short high speed extrusions reliably for example.

[francisw]

Thank you for doing this - a feature I need right now!

Volunteering to Beta test for you if needed. Relative noob in 3D Printing, needing to push extrusion limits on modified FLSUN SR.