Jump to content

Das_Sams

Dormant
  • Posts

    5
  • Joined

  • Last visited

Personal Information

  • 3D printer
    Other
  • Country
    DE
  • Industry
    R&D / Exploration

Das_Sams's Achievements

0

Reputation

  1. Anyways, if there are printers out there which reset G92 when doing G28 it doesn't hurt to reset the offset made in the beginning at the end of the gcode.
  2. The definition does not imply this. Neither RepRap G-Code reference nor LinuxCNC G-Code reference nor Wikipedia mention any correlation of G28 and G92. And believe me, on a CNC-mill it would cause trouble. Having to rehome an axis does not necessary move your vice or workpiece on the table. Telling the machine were the work piece is on the table is what G92 was made for. What you store with G92 can be the result of an hour of measuring and sometimes even not be recovered after something is milled. I think it'd be a bad idea to change this in printers' firmwares. Someone could take a modern (fast enough) CNC-mill and put an extruder in a chuck. Don't brake this. We love standards. So the plugin has to deal with that. And this means the print file has to set the offset back at the end. Of cause this is not ideal as someone might interrupt the print. As we cannot change that, doing the G92 manual is better. People should be encouraged to do so. If you're to lazy to jog and always have the same offset, then a file with G28 X Y ; home X and Z G0 X-35 ; Change the value to your needs. Homing Z shouldn't crash the extruder on you bed. G28 Z ; home Z G92 -<_offset> ; where <_offset> is your desired offset. If 0 is not your home position change ; analogously. You can have both files on the SD. Today I got a new glass plate from China. I was printing on a small piece of junk glass before. I already had the next print which would have been to big for the junk glass on the printer. Well, when the print from yesterday was done I measured the new glass thickness, calculated the offset, swapped the glass, jogged to the calculated new offset, ran my one liner and started the next print. This is quick. No need to unmount the SD, mount it on the Desktop, change the file in an editor or worse reslice it, unmount the SD, mount it on the printer... Someone could just spontaneously decide to use painters tape (+0.1mm) or something else or the plywood carriage under the bed warps... and quickly need a new offset.
  3. G28 ;Home G1 Z15.0 F6000 ;Move the platform down 15mm ;Prime the extruder G92 E0 G1 F200 E3 G92 E0 Yes, but it only affects the extruder. Thanks for the plugin and for the bug. Without the plugin I would have used slic3r and the bug made me learn. I don't know how long it would have taken for me to get the idea to adopt the G92 from the mill to the 3d printer otherwise. BTW. I tried G92.2 on my printer but it was ignored. If you have an account at the reprap wiki mentioned above, please update repetier from unknown to no. It's the default FW on an Anet A8 (clone). I guess it's repetier as repetier host for windoze was supplied on a CD. No, as you see. The printer is homed at the beginning of every print. Also it's not desirable to loose all the offsets with homing. There are several reasons for homing, like lost steps for various reasons (collision, emergency stop with uncontrolled deceleration) or complete position loss on a blown fuse on the 3~ (G-Code is not only for 3d printers). In lot's of these cases I don't want to measure the position of my machine vice in all three axes again. On the 3d Printer you loose steps at the end of any print cause the steppers don't hold against ripping 300cm² PLA off the bed. BTW.: The offset could be done in the start code with G92 -<offset> after homing BUT CAVEAT: The home position might be not 0. So #<_offset> = 1.225 G28 G0 Z0 G92 [0-<_offset>] would be better - in the hope there is no collision when doing this move. Well if that would be the case you'd have to do something manual anyways. For the End code there would be something like G0 Z [240-<_offset>] ; highest position officially supported by Anet A8 is 240 see note G92 Z 240 In this specific case we would get a collision which would need a realignment of both Z axis motors as the A8 does not have the total 240mm space the vendors claim. But that's a little off topic - just in case someone copies here. A great drawback is that it's a really time consuming thing to go up to the maximum and down at the end and begin of any program. In this case we would have an variable for the offset. Well. I have not tested it and I've no idea which printer firmwares have vars implemented. If not they have to be calculated by the plugin and the values put in the code. It's all painfull. I will stay with my workaround. For beginners or printers w/o display it's still needed. goede succes
  4. I've a workaround now and I like it. I stop using Z-offsets in Cura and slic3r. I took them out from all my gcodes generated by Cura with an editor. The slic3r gcodes have to be made new. What I do instead: I made a file "Z-offset.gcode". It contains only one line: G92 Z0 My printer shows absolute Z values in the display (Repetier firmware). So I can just jog to the Z position I want as offset an then "print" the Z-offset file. That keep's the offset until I use it again or switch the printer off or reset it. The axis can be homed afterwards the offset stays. (Take care about the 0.025mm Steps! My Display shows the Z values in .1 Steps but one button press moves .025mm so I have to stop pushing it at the first time 1.0 shows up when I jog up and press another 3 times when it shows up when I jog down and want 1.000 offset. Just imagine it goes 0.900 -> 0.925 -> 0.950 -> 0.975 -> 1.000 or down 1.100 -> 1.075 -> 1.050 -> 1.025 -> 1.000 ) I think that's cool: It's more flexible as slic3r's method, where you've to create the file new if you need a new offset or write a script to change all Z values in gcode. It's safer as Cura's method can be because if I (interrupt (a Cura print with offset) without reseting the printer) it would not be taken out and the next print trial would get a double offset, even if it would/will be fixed as supposed. It's fast when at the printer and I change something with the bed (Glass, Tape, Plywood subconstruction humidity change...). It's independent: No need to take the SD back to the computer. No plugin needed. Another hint: Make the SD-Card empty and then put the Z-offset.gcode file on it. This way you have it in the first line in the list of printable files. My Printer seems to have no collation. What's in the FAT first comes first. If your's sorts by alphabet or whatever use filename suiting for you. So Cura developers, documenters, tutorial writers: If you fix the Z-offset Plugin or in China a bag of rice tips over. I don't care. Well, it should be done - makes it clean. You can use my idea in Tutorials and documentations. Makes life more easy, especially if you have a cheap printer which needs to be calibrated more often. Also moving my Z-Axis switch sucks. It just has long holes. If I would have to adjust something with long holes and just want to move it some hundreds of a mm at a big machine I use a plastic hammer, but here even this is not really an option.
  5. hello, I noticed when I print a print with Z-axis offset a 2nd time the offset is incremented. I have to reset the printer for a 2nd print (or change the gcode manually before I put it on the printer). Then I had a look at the gcode. There was no G92 in the end. G92.2 would be the correct code to erase all offsets BUT it's not implemented in most firmwares* so it must be done with a line at the gcode file's end like this: G92 <real position> where <real position> is the last Z value used for a move + offset I'm using Cura 3.6 AppImage with the Z offset plugin. I know the G92 command and it's subcommands from CNC-milling where you usually set it by hand after measuring before you start the program. It's in general a good idea to use G92 (vs. slic3r, which changes all the Z values) because I can modify it quick on any computer near the printer with an editor and do not need to walk (30m through the rain) to go to the computer where cura runs (ssh -Y is not an option as cura requires OpenGL). * see https://reprap.org/wiki/G-code#G92.x:_Reset_Coordinate_System_Offsets_.28CNC_specific.29 :-) Das_Sams
×
×
  • Create New...