Posts made by DanS79

I still think it would be really nice to have.

If it existed, it would already be in the start-up gcode of every print i do.

@jens55 said in Meta commands:

To skip an iteration ???? Where did you see this in the documentation ???
I look at 'continue' as a command that strictly exists as a means to improve readability of the code since the command itself seems to do diddly squat and can be left out.

To be clear it doesn't skip an iteration, it skips everything after the continue statement in the current iteration. It goes back to the top of the looping structure and starts the next iteration. Every programming language I can think of works this way.

@alankilian said in Meta commands:

@jens55 said in Meta commands:

nested loops will be a nightmare.

Why?

Each loop gets its own iterator (which is what iterators ARE) so everything works out.

They are all called iterations.

If use want to use multiple of them to set a variable, the code would be very hard to read (assuming scoping even allows you to access all of them).

The following would be real confusing to follow if you replaced a, b, and c with iterations .

var x = 0
var a = 0
var b = 0
var c = 0
while a < 10
    set var.b = 0
    while b < 20
        set var.c = 0
        while c < 40
            set var.x = (a * b) - c
            set var.c = c + 1
         set var.b = b + 1
    set var.a = a + 1

@jens55

It's just a guess, but since no commands are being run when the if statement fails interations might not get incremented (maybe a bug).

As a developer I'm not sure i like the concept of an iterations variable.

the documentation says this about it.
iterations - The number of completed iterations of the innermost loop

If you have nested looping structures it could get difficult to follow the code.

if i have all the syntax correct, something like this is more standard in the software development world.

var cnt = 0
while cnt < 10
    set var.cnt = cnt + 1
    m118 s"hello world"
    g4 s2

@phaedrux

stls and f3d files are available on my blog post about the case under reference.

@stuartofmt said in gLapse: a time lapse application:

@kb58 said in gLapse: a time lapse application:

..... yeah I can see how a dedicated camera and interface would be better.....

These programs evolved to satisfy needs such as: monitoring and taking timelapse from, often, lengthy prints; not needing to be there to start taking the time-lapse; optionally parking the hotend for each image; capturing from more than one printer at a time; etc. etc.

Not to mention way cheaper in absolute terms and not tying up your smartphone

I agree with all of this.

The only thing I'd add is that imo going with a Pi and a pi camera module gives you a lot more freedom freedom than off the shelf webcams and phones. You can customize the hardware and software to your heart's content. For example you could rig up a NoIR module and an IR light source and shoot in a lights out environment. for stills you have a lot of output options (jpeg, png, gif, bmp, yuv, rgb, rgba, bgr,bgra). the amount of customizations available is truly extensive.

This is my pi zero w and hq camera module in a custom 3d printed case of my design. all i have to do is plug in an external wifi (onboard one is not good) or ethernet adapter, and give it power.

@pcr

I've never used duetlapse3 so take all the following with a grain of salt.

duetlapse3 supports Raspberry pi camera modules, and web cams, gLapse only supports pi camera modules.

duetlapse3 is using ffmpeg and libx264 on the pi to generate the video (if you want it to). That's cpu based encoding and thus would murder lower end Pi (like a zero ) if you tried to encode a 4k video. gLapse expects you to generate the video yourself on a more powerful machine. duetlapse3 is simpler if you don't know anything about encoding video, gLapse ultimately gives you more flexibility but you need to know more.

duetlapse3 requires RRF V3+, gLapse will work with version 2 or 3 in standalone mode. I will eventually add support for v3 fronted with an sbc.

duetlapse3 captures images based on time, layer change, or pause. gLapse just looks for specific M-codes to tell it what to do.

Those are probably the major differences.

eventually I plan to write an app that combines gLapse and my streaming app, so that you can do everything from a single application.

I've been working on this project off and on for a while, and I'm finally at a point where I can share it.

gLapse is a Python based timelapse application designed to run on a Raspberry Pi, fitted with an official camera module. It differs from most timelapse applications, in that it doesn't generate a video as its output. Instead, it stores a sequence of still images that can be downloaded and used to generate a video using a 3rd party application.

stills have a wider range of encoders and quality options available. They are only limited by the resolution of the sensor, and the storage capacity of the SD card used. In short, stills allow for higher resolution and higher quality video, but require the additional step of post processing in a 3rd party application.

Here is a sample 4k time lapse that was generated with stills captured with a Raspberry Pi Zero W equipped with an HQ camera module.
https://www.youtube.com/watch?v=bqkPgWrF3Eo

@dc42 What about M82? By default my slicer is in absolute mode, and thus i have to have an M82, and G92 E0 in my startup code.

Her is the first printing move from a sample file.

G1 F6000 X132.678 Y131.744 E0.0230

and here is the last one form the same file.

G1 X132.186 Y132.177 E784.9001

I'm working on something that requires momentarily circumventing the print process, before resuming after the task is complete.

Does G60 store the extruder position in addition to the normal axis information?

I did some testing last night, and it didn't seem to be the case, but it might just be that I need to add in additional retraction etc to my senario.

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.