Simple Macro for setting Z offset ... Needs work

[Gary Schwartz]

I'm not suggesting that this is THE answer to the Z positioning & bed leveling efforts underway.  I believe that if two problems can be solved, life will be improved for M2 users.

The series of commands works like a champ when I step thru them manually. 

And the macro has the advantages of: * No need for adjusting Z endstop.  In fact, no need for Z endstop other than preventing crashes.  * Can be tweaked to whatever accuracy user desires. (Hopes for?)

Problem #1  Macro buttons don't respond.  Probably my error that I'm unable to identify in Creator's manual.

Problem #2  Issuing "G92 Z0" does set current Z position to zero, but that apparently is different from Z Home. 

If I have the nozzle .05 mm above bed, issue "G92 Z0"  M114 will report that Z is at 0.00.  But if I then issue G28, the Z motor sends the carriage to the Z endstop.  Not good because I have Z endstop located a tad above the nozzle tip in order to prevent the endstop from interfering with the macro.  Maybe configuration.h setting that disallows movement in negative zone needs to be set.

[Toby]

I think your idea works if you change the G28 in your start gcode to G28 X0 Y0, so you don't get the home in z.  Presumably when the main g-code starts up it positions the nozzle according to an absolute move in x,y and z.  So you're ok having set the z=0 where you want it.  If it homes again (which I seriously doubt) then all bets are off.

The thing I don't like about this is that now the .fff file and the g-code for printing the model are not portable.   Using them depends on remembering that you have to do this manual set up positioning the bed where you want it right before you print.  If you forget I guess the worst that would happen is you start printing in air, but stuff like that makes me nervous anyway.  

[Gary Schwartz]

"if you change the G28 in your start gcode to G28 X0 Y0"  Aha.  The start code in Creator "Script" tab does need to be changed.  Thank you.

"main g-code"  I assume this is the code executed when I tell printer to begin printing the sliced model ... correct?

I see two scenarios: 1- My first print of the day:  I always check/set Z offset shortly before launching the print, so I'll run the macros ... if I can get them to work.

2- Subsequent prints: I always check Z offset prior to printing.  I often find that the added spritz of hair spray, or other stuff I do caused a change.

You're right; I do this manual setup prior to every print.  It'll be more time-efficient, accurate & consistent than my present method that involves adjusting the Z stop switch.  It should do until an automatic method is developed.

Two questions: * Did I miss the intent of any part of your post?  * Do you know why my macro buttons don't respond?

[Gary Schwartz]

Scratch the second question; it's answered in another post.​

      Gary
Make Better Things
Make Things Better

 

 

 

 

--
You received this message because you are subscribed to a topic in the Google Groups "MakerGear - Make Today, Change Tomorrow" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/makergear/rutuMKBK00I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to makergear+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Toby]

By "main g-code" I meant the g-code that goes in between the Start g-code and the End G-code in creator.  In other words, it's what creator makes when it slices the object, but before it has added whatever you put in the start g-code or in the end g-code.

The reason this matters is because it's sort of a black box.  We can see what the start code does, and then this gets handed off to what I'm calling the "main g-code"  My assumption is that the first thing it does then is perform an absolute position of the bed/nozzle to begin laying down filament.  That's the only way that makes sense to me.  In which case having set z=0 with your macro method, you should be ok.  Its just a theoretical possibility that someone's slicer could stick a G28 inside that black box and ruin all our schemes.  But if you watch the way the print starts it's pretty clear creator isn't doing that.

The other thing I was trying to say is just that if you change the start G-code this way, then you've created a situation that is unique to your methods.  For example, you might save the .fff file because it also contains some great settings for some particular material you've been working with, and then give it to someone else who's also working with that material.  They won't know what's going on with your start G-code, and probably won't even look at it.  But then if they print with it they'll be in for a surprise.

This is a pretty obscure point though. It's a reflex reaction on my part from my past life as a software developer.  You should just ignore it and move forward.  I think your method will work and I'd be very interested to hear how it goes if/when you try it.

[Dale Reed]

So let's tell the S3D Creator guys that we need a place for MY-machine-specific g-code (configurable by user) for initialization, and maybe for end of print, that's NOT saved in the .fff file.  They would have to put it in the .gcode file, of course, so you could print from SD card.  But perhaps they could keep it out of the .factory file so that those can be shared.

I have to think through the user workflow a bit to determine at what points some my-machine-specific code might be needed.  And we'll need to know exactly what Creator does sequence-wise with the start g-code, "main" g-code, end g-code, etc. with other options checked/unchecked for things like homing, waiting for temperatures to stabilize, etc.  We can probably figure it out through examination of files created, but it would be nice to have a sequence diagram of some kind.  (I think better in pictures.)

I also think better at times other than Saturday evening!  Brain is elsewhere.

Dale

[Toby]

On Saturday, February 22, 2014 8:30:26 PM UTC-6, Dale Reed wrote:

So let's tell the S3D Creator guys that we need a place for MY-machine-specific g-code (configurable by user) for initialization, and maybe for end of print, that's NOT saved in the .fff file.  They would have to put it in the .gcode file, of course, so you could print from SD card.  But perhaps they could keep it out of the .factory file so that those can be shared.

I think that makes sense.  The start and end g-codes aren't related to what you're doing with the other parameters used to slice.  They aren't part of the preview and somehow don't belong in that step.  On the other hand, the layer-change g-code does belong there. 

This would mean a change in workflow within creator.  First you slice with parameters and preview till you're happy, then have a "final g-code generation" step, on a new screen, where your start and end g-codes are added.  The start and end g-codes would have to be saved in a different file from the .fff file, leading to more things to manage in exchange for more portability and (to me) a more logical sequence for constructing the final .gcode file.

[Gary Schwartz]

Dale,

"And we'll need to know exactly what Creator does sequence-wise with the start g-code, "main" g-code, end g-code, etc. with other options checked/unchecked for things like homing, waiting for temperatures to stabilize, etc.  We can probably figure it out through examination of files created, but it would be nice to have a sequence diagram of some kind.  

Absolutely!  I think we're owed information that shows how our selections affect what our machines do, and what we can do to tailor to our needs.  Creator's creators would benefit from our work.

(I think better in pictures.)  Me too ... big time.

Doing this would be a step toward compensating for the long-promised, yet-to-be-delivered, Users Manual.  I think some encouragement by Rick is in order ... we bought the software from him.