@aitor said in SD card reader module:

Ok @droftarts, that explains why it didn't work

Do you plan to add it at some point? or is it totally ruled out?

It would be interesting for me to add it, there are still clients who tell me that they prefer to work like this

All the best

@dc42 will need to respond; I don't know if it's even possible. Add it to the firmware wishlist? Sorry, already is!

Ian

@deckingman Thanks for clarification.
i should learn english...

@wdenker said in Quad z independent motor movement.:

I would like to see a paramater added to G1 command for example G1 M5 Z10 which would say move motor 5 positive 10 and leave the remainder z motors stationary so that on bigger builds you can get the bed closer to level prior to running a G32 mechanically leveling the bed. This is critical for bigger dual gantry machines as if the one head corner is close and the opposite corner is 20 mm away the secondary head will crash into the bed before it can probe the other corner.

What you can do is what I did.

Each Z stepper has it's own endstop sensor.

With this you can home using G1 H1 moves as you would for X and Y.

I designed and printed adjustable mounts for the endstop sensors so I can tweak their position to get the bed very nearly level using the G1 H1 approach and then finish the leveling using G32.

Video showing both G1 H1 and G32 leveling operation

Frederick

@com3 here is how I have implemented it for the Bear Project. I am using Prusaslicer for this:

Everytime after a first layer finishes I am calling the system file "layer_change.g". This happens through the Before layer change G-code in Prusaslicer:

; Before layer change G-code ; called before the print advances to the next layer G92 E0.0 ; reset extruder position to 0 {if layer_z == layer_height+first_layer_height}M98 P"layer_change.g"{endif} ; execute layer_change.g ;[layer_z]

So whenever a print switches from 1st to 2nd layer "layer_change.g" is being called:

; layer_change.g ; system file, called on first layer change during a print from Prusaslicer to save applied babysteps to config-override.g ; requires modifications to layer change G-Code in Prusaslicer if move.axes[2].babystep !=0 ; if no babysteps are currently adjusted - exit routine echo {"OLD: " ^ sensors.probes[0].triggerHeight ^ " NEW: " ^ sensors.probes[0].triggerHeight + (move.axes[2].babystep * -1)} ; displays old and new Z probe trigger height G31 Z{sensors.probes[0].triggerHeight - move.axes[2].babystep} ; measures and applies new Z probe trigger height M500 P31 ; saves new Z probe trigger height to config-overide.g

This will add or substract any baby stepping adjustment to your current Z-Offset value and then stores it in "config-override.g" via M500 P31

Additionally I inlcuded the following in "cancel.g" and "stop.g":

M290 R0 S0 ; reset babystepping to 0 M501 ; load saved parameters from non-volatile memory (config-override.g)

This assures that if a print is cancelled or finished, babystepping is reset to 0 and the new value from "config-override.g" is being called.

Now I know this is a workaround more than anything and I would love for this to be implemented in the firmware itself. Our goal is to make 3D printing as easy as possible for everyone and in our opinion this means keeping users away from system, config and macro files for printers where a "out of the box" configuration is published. Ideally users should only have to interact with either the printer display or the webUI. Prusa does a great job with that and this is why so many people can just get started with their printers even though they have no experience at all.

I hope this helps to find your own workaround.

Here is another data point. A Diamond 3 or 5 colour hot end needs a PA value of around 0.5. My experimental 6 input hot end requires a PA value of less than 0.1. It's currently questionable if any PA is necessary with this hot end but certainly 0.2 is far too much. The major difference between a Diamond hot end and my version is that the Diamond has a straight section at the end of each filament path of 3mm at 0 4mm diameter. After the filaments have been combined, there is a further straight section of 2mm at 0 4mn diameter. So each filament path has a section at the end of 5mm in length at 0.4mm diameter. With my hot end, the filament paths are 1.8mm diameter all the way to the nozzle. The hole at the end of a standard E3D V6 nozzle is generally lass than 1mm (depending on diameter). The filament paths on my hot end are longer than a Diamond so it has a larger volume of molten plastic. I'll leave it to others to form their own conclusions as to the cause of pressure build up (I know what mine are).

@sputnikoc3d said in Filament Material Changes without Load - Unload ???:

@fcwilt

I'd have a manual button/macro I can hit that will toggle on/off my load / unload scripts when I change a filament via dwc tool drop down option ...

Exactly.

Frederick

I'll move to the wish list

@o_lampe ...sure, I just meant that the firmware has logic it can borrow from, but that it needs to optionally consider other interrupts.

@o_lampe said in Different idle factors for M906 motor currents?:

@deckingman
sure, but would UV switch to idle mode (because I switched to another tool) while XY are moving? I can set the current in the toolchanging macros, but what if it also switches to 30% of the already reduced current?

As I understand it (but I could be wrong), UV will not switch to idle mode while XY are moving because the timer starts when there are no moves (on any gantry). I believe that idle hold is switched off for all motors as soon as any one is commanded to move (but again, I could be wrong). I guess it would be easy enough to check. Set idle hold to low current so that you can easily move a gantry when it is enabled, wait for it to kick in, then do a (say ) G1 Zn and see if you can move XY or UV (i.e do they now have full current or reduced current?).

@engikeneer

I was a programmer for 30+ years.

Lots and lots of comments, more comments than code.

Frederick

@martinnyhc it's on my list to remove that restriction for simple filament present/absent sensors, but it probably won't happen in RRF 3.4.

Good morning,

Since I have seen this post, I would like to add my idea that I have had for a long time.

It would be to add a M291 S4 message that would give the option of "Yes" or "No" and on the other hand that you could add for example a C parameter, for example C "global.reply" and that this would make a: set global.reply = ("yes" or "no") or (true or false)

It would also be interesting that "this parameter C" in the formats S2 and S3 with X1 Y1 Z1 would save the value of these in the variable, I do not know if in this particular case, which has been requested to show more than one axis, maybe it should be something like this C"{global.xpos,global.ypos,global.zpos}" or maybe the ideal is to request them separately.

I think these options would open many possibilities to interact with the user.

Let's see what you think of my idea

Best regards

Sorry if something is not well understood, it is very difficult for me to write in English.

I have this issue too, but my work around is I have sub directories in the sys directory that have their own config.g and other sys files. When I want to switch configs, I have macros that run M505 "0:\sys\config1" or M505 "0:\sys\config2", etc. I have global variables that get reused in each, like probeLocation, but it gets redifined depending on which config.g is run.

You will also have to run this code block to check if the variable already exists and act accordingly... yeah, yeah I know, the elif is not necessary in this case, I just like being as explicit as possible
edit: converted code from text to embedded code block

;create local variable that is stored until the existence of a global variable is checked var probeLocationX = XX.XX var probeLocationY = YY.YY var probeLocationZ = ZZ.ZZ if exists(global.probeLocationX) == true set global.probeLocationX = {var.probeLocationX} set global.probeLocationY = {var.probeLocationY} set global.probeLocationZ = {var.probeLocationZ} elif exists(global.probeLocationX) == false global probeLocationX = {var.probeLocationX} global probeLocationY = {var.probeLocationY} global probeLocationZ = {var.probeLocationZ}

@oliof it's on the wish list but not a high priority. It needs a high sampling rate to give low latency. The LIS3DH should be OK for this if we switch to its 8-bit mode, which can sample at around 5kHz. Or we could stick with 1344Hz sampling and accept higher latency, and therefore reduced accuracy.

Bump

@dc42 could I ask you to take a look at this please?

@o_lampe watercooling the heatsink would make little difference in my opinion. As the magnum already had very low thermal transfer.

So that's why I thought the speed could just dynamically while the temperature is decreasing and increasing.

It also cools a lot quicker while extruding, since new filament will absorb the heat

@dc42 fair point, and I guess the proper answer is to get the wire lengths right and use strain relief next time! 😛

G29 with no S parameter now runs file sys/mesh.g if it exists; otherwise it behaves like G29 S0 as before

At its most basic mesh.g would need to contain G29 S0 to initiate a mesh compensation probing routine. As long as the probe and mesh grid configuration are already in config.g. Beyond that you can get as fancy as you want. Preheat, homing, special probe configuration, speed settings, etc.

; Macro to run a mesh bed compensation routine (G29) ; M291 P"Grid bed compensation map will be cleared and re-calculated. Ok or Cancel?" R"WARNING. This will take about 30 minutes." S3 ; User must click OK or cancel. ; Preheat to probing temps M291 P"Preheating to bed to 60 and nozzle to 210 for accurate probing" R"Proceed?" S3 T0 ; Activate first tool M190 S65 ; Set bed to 65 and wait ;M109 S210 ; Set nozzle to 210 and wait. Used only for stall detection probing. ; Clear current mesh compensation map and disable compensation. G28 ; Home all M561 ; Disable any current bed compensation ; Set lower speeds for Z homing and lower Z motor current M98 P"ZSpeedsSlow.g" M98 P"CurrentsHoming.g" ; Drop motor current to prevent damage in case of head crash M98 P"0:/macros/musical tunes/GetAttention.g" ; Tone to get user attention M291 P"Running mesh grid compensation probing cycle. Do not disturb the printer." M558 H1.5 ; lower dive height G29 S0 ; Run mesh compensation M98 P"0:/macros/musical tunes/GetAttention.g" ; Tone to get user attention M558 H3 ; return dive height ; Turn off heaters M140 S0 ; Set bed to 0 and release M104 S0 ; turn off hot end heater M98 P"ZSpeedsNormal.g" M98 P"CurrentsNormal.g" M291 P"Homing" G28 ; Home all M84 ; turn off the motors M291 P"Check heightmap for results." R"Probing complete!" S3

@phaedrux
That's a workaround I can live with. Thanks!
If the current reduction happens while the extruder is accelerating to retraction speed, it's fast enough.
What does @dc42 think about it?