Posts made by TickTock

OK, thanks. I went back and looked again. There is nothing on my version (1.20beta4). I guess I need to update to the latest.

When my prior print finished and I started the next print, I couldn't remember if I had uploaded the lastest or not. It would be helpful if, after selecting the gcode, it also included the date the file was edited or uploaded.

Thanks. I am calling it explicitly with M98 and can change to end2 there but that requires editing the slicer profile so having the ability to add check boxes would be a nice feature for lazy people like me.

BTW: M0 H1 doesn't seem to work for me (why I'm using M98 instead). Even with the H1 card, the heaters are turned off when M0 H1 is called (same end.g code in the stop.g file). M98 Pend.g leaves the heaters on. Operator error or bug?

I usually shut down the print bed and extruder in my end.g file for safety. However, fairly frequently I am in a rapid turn-around mode such as where I am fitting a profile to an existing object (5 minute print, tweak and repeat). My print bed is 1/4" aluminum plate and is very slow to stabilize so I change my end to keep the bed hot and lower the extruder to just below the point where it drips. Is there a way that I can add a check box to the machine control to tell it to use end2.g instead of end.g so I can easily swap modes? Is there a better way to do what I am doing?

It would be nice to be able to see which macros have been executed and in what order in the Gcode Console. Just a note: "M98 MacroName" or similar.

Unlikely. The impedance of the coax won't match where you solder it to the antenna so you would lose lots of the TX energy before it even entered the coax

OK. Going to 1.21 solved my problems. The G10 command worked fine once I updated (same commands would not work on 1.20). For my machine with a 200x200mm bed the following now work to mirror:
M579 X-1
G10 L2 P1 X200

Undo with:
M579 X1
G10 L2 P1 X0

OK. I see the G53-59 are only supported in 1.21 and later so it looks like I need to update my firmware before proceeding (my duet is still running 1.20).

I tried the G10 (not M10 - typo in my prior post) but didn't have the L2 parameter. What does that do? (not in the duet gcode documentation)

Hmm. Cannot seem to make it work with G92, M206, or M10. The M579 works great but I cannot get it to accept the offset to bring positive coordinates back onto the bed. I guess I'll reconfigure the machine like you suggested making X0 Y0 in the center.

Looks like I am on 1.20.

@dc42:

You can scale and mirror each axis using the M579 command. A negative scale factor mirrors the axis. It's easiest if you define X0 Y0 as the centre of the bed if you are going to do this.

Nice! I think I can work with this. Too bad it doesn't include the I,J,&K options like G51 (which you use to set the center of rotation/scale) but between this and G92 or perhaps M206 I should be able to make it work. Thanks!

@Danal:

"Work Coordinate" systems, by NIST G-Code standard, offset the "control point" from "machine" coordinates. They do not (can not) mirror, or reverse, an axis. If you have other uses for these offsets, they've been partially in Duet3D/RepRap for some time, and are fully implemented to NIST standard in R1.21 (just released a few days ago).

As mentioned by someone else above, the same M codes that are used to originally configure the machine can easily reverse an axis. Depending on a bunch of things, you may need limit switches physically at each end of the axis. If you have "normally closed" limits, wire them in series. If you have "normally open" wire them in parallel.

Wow. Really? So they eliminated G51 but did not provide an alternative method to scale axes? My 20 year old machine can scale, rotate, translate with two modal commands at the top of the gcode. Very handy for fixturing (and mirroring). Well.. I guess thank goodness for open source. Just means this is going to take more effort than I thought.

I make a lot of parts in both left and right hand versions. I am tiring of always slicing both variants. On my big machine (Cincinnati Arrow 500), I can issue G50/G51 commands to rotate, scale, mirror the coordinate system to (among other things) create mirrored image parts. Neither of these appear to be supported by RepRap but I do see G54-G59 as selecting different coordinate systems so I suspect I can use those. How does one go about creating a Coordinate System 2 in which, say, the X axis is mirrored? I cannot find a "set up coordinate system" command (at least no using the search feature on the Duet gcode wiki)

Whenever I try to set the bed PID parameters I get an error response which sounds like it thinks I am sending an M305 command instead of M304:

M304 P100 I50 D150
Error: M304: Invalid bed heater index '100

Well, no luck with the repeater yet. I didn't do a whole lot of debug - just went through the quick start routine. It actually made things worse. The Duet couldn't connect at all if the WR810N was nearby. I can try setting it up as a router instead since I have ports available but at this point I think I will try the board swap.

That does look almost there. A couple things stand out, though. Output range is only 1/6 to 5/6 of the Vref so we lose a third of the useful range (almost all uC I've looked at have this limitation). Also, the DNL is not exactly stellar at +/- 2.5 DNL. I think for this application DNL is particularly important as it will result in visible distortion in faces. So I've been thinking a smaller uC - maybe even 8bit (it doesn't have much to do anyway) and use dedicated DACs such at MCP4921. These DACs have built in near-rail buffers so can probably drive the galvo controller directly.

@dc42:

Can you tell me more about how laser SLA printers are driven? Do you need an RPi or similar Linux-based SBC to process the sections of the model? If so then some parts of the Duet would be redundant, e.g. the network interface, probably the SD card, and most of the stepper drivers. In which case, this would best be done using a less expensive board, based on e.g. a SAM4S microcontroller and a single TMC2208 stepper driver (or perhaps TMC2660 for larger SLA printers). It could run a cut-down version of RepRapFirmware.

On my SLA printer (Peopoly MOAI - a phenomenal printer for the $$$, BTW), I generate gcode using Cura. The slicer appears to work very similarly to an FDM slicer - just finer resolution. It slices into perimeters and infill. Laser power is kept constant and curing time modulated by the speed that it is scanned. So I think the Duet could be used as-is if we could convert the step&direction to 0-5V analog voltages with about 12bit resolution. The easiest is to have one board which is placed twice - once for X and again for Y. We would have to added a calibration and a transform into the software, though, with this option, to correct for curvature, rotation, gain & offset. If we wanted to minimize the impact to that, a more elegant solution would be a single board which accumulates step&dir for both X & Y, and does the transform there before sending out to dual DACs. Would not need any significant compute power - the challenge is getting a rail to rail 12bit DAC. I have not found and PIC or AVR that can do that. Most are only 10bit and their output drivers can only get to around VDD-1 reliably so I think we are looking at a dedicated DAC.