@Phaedrux, thanks, exactly what I needed!
Posts made by DeltaCon
-
RE: Move delta motors independently
-
Move delta motors independently
I am picking up on 3d printing after a long pause. I have some trouble getting my prints neat. For troubleshooting purposes, I am trying to think up a macro that moves my carriages up and down a few times one tower after another. I thought I once read about a command in RRF that allows that, but can't seem to find it. Am I mistaken or just not looking good enough?
-
RE: Well this is something I haven't seen before
An entirely different approach to think about it:
Is it a single wall print with something like a gyroid infill? -
RE: Duet Web Control 3.1.1 - Not accessible from all devices
Are you SURE thhey are on the same network? I don't think so... You probably are using a router as accespoint / Switch, and it happens to DHCP in the same segment as your main router.
-
RE: Duet Maestoro cannot connect to the Duet web control.
Seems obvious that 2 devices in unequal network segments cannot reach eachother.
Are you convinced they are connected to the same router / network? It is not normal that devices in the same network get IP addresses through dhcp that are not in the same segments. -
RE: Baby Stepping.. can it, or can it not be permanent?
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
Let's go the whole hog. Why stop with having a button to make baby stepping permanent instead of editing one value in config.g? Let's have another button that will set the steps per mm for extruders after we've calibrated them - one button for each extruder ideally. Then another button when we tune firmware retraction to save us editing config.g for that. The same for pressure advance and all the other things we have to tune.
Most things you mention are set and forget type of settings. Nozzle offset is not, it needs to be tuned from roll to roll, or evan after many other changes.
With enough buttons, we need never open config.g at all.
That's basically the idea of having a GUI, isn't it?
Look people, it is just not worth any more fuzz. It is certainly no dealbreaker for me. I did not invent the subject. I just think it is a plausible feature that got fired down with not enough valid arguments.
-
RE: Baby Stepping.. can it, or can it not be permanent?
@bot said in Baby Stepping.. can it, or can it not be permanent?:
I wonder how much of the precious memory on the duets are used for features that are catering to people whose printers are so poorly built that they need to calibrate it every single time they print. How much of the development time put into RRF was for such features?
Babystepping works as it does now. Config-override exists for you to save settings, but not babystepping. Figure out a way to save your babystepping values with that you have now!
It's so frustrating that some of us jump through hoops, spend tens of thousands of dollars or euros, build a machine that is rock solid, but yet we have to deal with the onslaught of features and feature requests from people who can't be bothered to edit one line in one file?
We should not cater primarily to the lazy folks who can't be bothered to perform extremely simple actions.
A little respect please... Not anyone uses their machinery the exact same way you do so yes, other people have to be catered too. The suggested option is a nice one, even if you do not understand that. RepRap is supposed to be the most userfriendly firmware, no?
-
RE: Baby Stepping.. can it, or can it not be permanent?
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
Scenario 1. With baby stepping as is (non permanent), you start a print, then adjust baby stepping. Repeat for the next print.
Only if you are homing again you will have to readjust. Making it permanent you do NOT have to readjust.
Scenario 2. With "permanent" baby stepping, you start a print, then adjust baby stepping, then save it. But you still repeat that process for the next print because you say "I find myself babystepping down a bit for each print........"
I find myself babystepping down for each print, because I cannot make it permanent. You have it the wrong way.
So all you are doing in scenario 2 is saving the value that you are going to change anyway next time you do a print. Why?
No, I do NOT need to change anyway if my value gets permanent.
I think you need to look at it not as permanent babystepping, but as an easy way to dial in the H value in config.g. Nothing is easier then looking at a result, adjusting, looking again, and when it is spot on, press the button and it is set. After pressing the button, babystepping is at 0 and no need for adjustment until you change material, adjust flowrate or esteps, or do something else that requires evaluation of your nozzle offset. -
RE: Baby Stepping.. can it, or can it not be permanent?
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
I'm just trying to understand why people want something that has to be changed regularly to be made to persist or be permanent.
I do see the value of the suggested feature. Especially for values that change regularly. I find myself babystepping down a bit for each print of the roll I am currently using. Yes, I need to compensate for that in the H parameter of G31 command, but call me lazy! (does everyone has to lookup if it needs to be added or subtracted?). What's wrong with a button that sets the default height compensation in config.g based on the currently set babystepping? I would like it for sure!
-
RE: Laser Works (but not from lightburn)
Tested the S1 parameter in M452 and that works. Thanks @bearer for showing me.
Extra questions for the experts:
What is a nice clean method for having a nice clean low-power dot for focussing purposes? Anyone have a ready to use macro for that?
And the second one is about the F parameter in M452. The specs of my lasermodule show a max PWM frequency of 20000Hz. Should I use that or is that some nonsense value? I see many people using different values here, but what values actualy make sense?
-
RE: Laser Works (but not from lightburn)
@bearer said in Laser Works (but not from lightburn):
my bad, marlin compat is a RRF thing https://duet3d.dozuki.com/Wiki/Gcode#Section_M555_Set_compatibility
Oh, okay, I'll try that.
Through the Lightburn forums I was also told that the next lightburn release will havean "inline" option in the Marlin profile that does exactly what we want:So that's great too!
and you're using https://duet3d.dozuki.com/Wiki/Gcode#Section_M452_Select_Laser_Printer_Mode ?
Hmm, I see where you are going with this... I omitted the S1 parameter in the M452.
That should do the trick... Thanks for this direction. There are so many thing to account for! -
RE: Laser Works (but not from lightburn)
@dc42 said in Laser Works (but not from lightburn):
Are you trying to connect to the Duet via USB, instead of uploading via HTTP and running the job from SD card?
Yes indeed I am. Reason for that is to be able to use Lightburn controls on my laptop beside the machine. I am not familiar enough with my machine yet to have it working "on it's own". And DWC has way to many laser-engraving-unrelated options. I would love a webcontrol that was more CNC related though. I also would love Lightburn to have ethernet connections But I am aware that Lightburn can save the gecode and I could upload it through DWC. Feels like more steps that necessary though.
-
RE: Laser Works (but not from lightburn)
@bearer said in Laser Works (but not from lightburn):
smoothie mode may require marlin compatability mode, and sticky S parameter should work with a recent firmware set to laser mode?
I can find no such Marlin Compatibility mode in the Lightburn device settings.
And the sticky S obviously does not work in RRF 3.11RC (unless it has to be enabled somehow? The laser only burns during the first move.; LightBurn 0.9.11 ; GRBL-M3 (1.1e or earlier) device profile, current position G00 G17 G40 G21 G54 G91 ; Cut @ 3000 mm/min, 10% power M9 M5 G0X3.64Y2.28 M3 G1X-0.71Y0.65S25.5F3000 G1X-0.65Y0.71 G1X-0.57Y0.77 G1X-0.5Y0.82 G1X-0.42Y0.88 etc...
-
RE: Laser Works (but not from lightburn)
Smoothieware profile refuses to connect to the board. No idea why, all other profiles I tried have no problem on the same baudrate.
Grbl only issues an S parameter when it changes (presumes it to be sticky)
-
Laser Works (but not from lightburn)
Looks like this question would be better placed in the lightburn forum, but my guess is the engraving duet users gather here. Duet is still pretty underrepresented in the lightburn forums...
I have my engraver setup working. That is, G1 Sxxx commands make the laser move and burn. The lightburn gcode output however switches on with M3 Sxxx and does not give Sxxx parameters in the G1 command. I know some people are using Duets AND lightburn to engrave. My question: how did theu dolve this?
Thanks!
-
RE: M950 and Pin Names
@dc42 said in M950 and Pin Names:
I can look into providing a variant of M3 that allows the laser to be turned on without movement.
I think that would be welcomed by a lot of diode laser module owners! (like me).
-
RE: Endstop on 2nd Y motor
@dc42 said in Endstop on 2nd Y motor:
... When you home Y, each switch will stop its own motor.
Okay, so in M574 the endstops pins must be defined in the order the motors were assigend in the M584. That seems an obvious thing to do, but I did not realise they would show up as one "virtual" endstop. I wil try. First I need to recrimp my endstop cables. In the factory ones I have most pins seem to make no contact...
Thanks! -
RE: Dual X endstop homing
@Boulet_Frites said in Dual X endstop homing:
Is Maestro compatible with RepRapFirmware 3 ?
Yes it is, I am running RRF 3.01 (RC11) on a Maestro.
I followed you advice and now the U axis is moving for homing but the motor is turning very slowly; not at the same rate than the X motor.
Check your Steps/mm for the E0 motor, it needs to be the same as your X motor of course.
I am doing the same thing, in RRF3, also on a Maestro, but with a double Y instead. I do not have that working completely either
-
Endstop on 2nd Y motor
I am configuring my new Maestro for my dedicated laser machine.
My table has a dual Y axis and I want independant homing. In RRF3 it is said that I do not need to configure a U axis and hide it, like it was previously.This is what I did:
; Drives M569 P0 S0 ; physical drive 0 goes backwards M569 P1 S0 ; physical drive 1 goes backwards M569 P2 S0 ; physical drive 2 goes backwards M569 P3 S1 ; physical drive 3 goes forwards M569 P4 S0 ; physical drive 4 goes backwards / 2nd Y motor M584 X0 Y1:4 Z2 E3 P3 ; set drive mapping / map 2nd Y motor to Y axis ; Endstops M574 X1 S1 P"xstop" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"ystop+e1stop" ; configure active-high endstop for low end on Y via pin ystop M574 Z2 S1 P"zstop" ; configure active-high endstop for low end on Z via pin zstop
DWC does not show the status of the second Y endstop:
And also M119 does not give any info on that endstop status.
What am I doing wrong?
Thanks! -
RE: Output pin floating after tool selection in laser mode
@radiomodell
Thanks, this is splendid! I mostly revert to https://reprap.org/wiki/G-code#M452:_Select_Laser_Printer_Mode for gcode reference, but it seems incomplete when it comes to lasering. I can use your info. thanks a lot!