That's easy enough to say, the change lists are sometimes quite long. Unless you have something in mind or it happens to pop in your head while "browsing" through those lists that something might affect you...
Basically, you don't know, what you don't know.
In any case, your pointer was right and I was able to sort it out.
Thanks!
OK, I think I found more stuff wrong in the way I'm doing things. My slicer is set up to move the head to where I want it after a print, then I turn off the steppers. I found that turning off the steppers is causing the issue.
What I will do is remove the ending moves from my slicer and let stop.g do it.
Still not sure why I did not see this in 3.4
So far about every update exposes an issue, so far it has been things I have set up that are not quiet right.
So now 4 printers later and numerous clean ups ( each new printer started with the previous printers files ), I think my scripts and setups are zeroing in on being right.
Thanks
Joel
There is a G1 move at line 7 but I thought stop.g was only called when you cancel a print, not at the end of a print.
This is a new behavior for 3.5.1.
OK - I renamed my stop.g to something else and the error went away. I'm not sure how to fix this. Why is this now being called at the end of a print when in 3.4.x it seemed not to be ( never saw this error before )?
Hi,
I'm getting this error at the end of every print,
Error: in file macro line 7: G1: insufficient axes homed
I am not sure where it is coming from. I made a very simple gcode file,
G90
G1 Z10 X175 Y175 F6000
M84
It does its thing and then gives me the same error.
Any ideas where I should look?
Thanks
Joel
I think I found my issue,
In my Z-offset routine, when I was restoring the probe type, I did not restore the Z trigger height.
Once I fixed the G31 command, the height map works as expected.
OK, but it still leaves open what changed? Is there an issue with file handling?
I was cleaning up my config.g file and going through it. It brought a question to mind that when I changed something, the height map started working, but I'm not sure why.
In my config file, there is a line G31 P500 X0 Y0 Z-.45 . This setup the offsets for the probe
At the end of my config file there is a G10 X0 Y0 Z0 which I thought was another tool offset, how does it relate to G31? When I do my Z-offset macro, it adds a line to config-override that is a G10 P0 Z xxxx. I thought this was an adjustment to the offset in the G31 Z-.45 offset.
When I commented out the G10 X0 Y0 Z0 in my config.g the height map was still broken. When I changed it G10 X0 Y0 Z-.45 ( to match the G31 setting ), the heightmap started working.
What should I be doing here?
I still don't know how to do the insert gcode thing, so I will attach my config.g as a file
Thanks
Joel
I took it out of the Z-home, because I believe that is true. But for Z-offset, config-override gets updated, so won't it need to be read again?
In my z-offset macro I added a delay between M500 and M501, and now it does not get stuck busy.
This is a change in behavior for 3.5.1, in 3.4.x, this was not an issue.
I tried something,
I commented out the M501 from my z-offset macro, everything worked fine. I then ran M501 from the console and everything still worked OK. I uncommented M501 in my z-offset macro, the machine stayed busy again.
I used to have an M501 in my Z-home macro, did the same thing there ( stayed busy ).
Hi,
I did do some more playing and it seems to happen when I use my Z offset macro.
Sometimes calling M122 resets the machine. This morning I was able to get some output.
I can't connect via USB, the controller is unresponsive using the web interface and at the PanelDue.
Hi,
I just updated to 3.5.1 and find that when M501 is called, my printer stays busy and won't respond to any more commands.
Bug?
Joel
Yes, it is a tap probe, I lower the nozzle until it just touches the bed, then lower until it triggers.
What's the tag that inserts a code block so it easier to read? I post some of the shorter ones now.
If something changes I run my Z offset macro which adds or subtracts a bit an gets placed in config-override.g
; Probed tool offsets
G10 P0 Z0.04
my z home macro is,
G91 ; relative positioning
G1 H2 Z10 F4000 ; lift Z relative to current position
G90 ; absolute positioning
G1 X175 Y175 F10000 ; go to first probe point
;G90 ; absolute positioning
;G1 X175 Y175 F4000 ; go to first bed probe point and home Z
G91 ; set relative move
G1 Z-999 H1 F500 ; quickly home Z
G1 z5 ; Lift z for final probe
G30 ; home Z by probing the bed
G90
G1 X5 Y5 F10000
G1 Z10 F2000
M501
my z offset macro is,
T0
M291 P"Press ""OK"" if you would you like to calibrate the Z-offset for this Tool Cartridge." R"Calibrate Z-Offset" S3
M291 P"Homing, please wait..." R"Calibrate Z-Offset" S1
M208 Z-2 S1 ; allow movement below Z0
G1 X175 Y175 Z8 F4000 ; move to center of bed
M558 P0
G30 S-2
M208 Z-.5 S1 ; allow slight - Z so zoffset can work
G1 Z10 ; drop build plate
G1 X10 Y10 F4000
M558 P1 C"!^io4.in" H5 F500 T10000 ; restore probe type
G31 P500 X0 Y0
M291 P"Z-offset calibration complete! " R"Calibrate Z-Offset" S1 T3
M500 ; save results
M501 ; load new data
Hi,
So I do have this,
M558 P5 C"!^io4.in" H5 F120 T12000
G31 P500 X0 Y0 Z-.45
M557 X20:330 Y20:330 S77.5
The tool offset is actually very accurate. changes ever so slightly when I change nozzles. For now I'm not using mesh and just do a new Z offset if I change nozzles.
After sorting some things out ( thanks for the help ) after reconfiguring my Voron 2.4, I am having height map issues. First problem was very big deviations which I knew were not real, slowed down the Z probe and that was solved. Now the deviation looks good ( not much ), but the map gets pushed down below the table.
What I usually do,
Turn on machine and home all axis.
bed level till below .01mm
rehome Z
check/set Z offset
mesh level
This is what I get. what could be causing this offset?
Thanks
I think I'm actually OK with it working the way it does. I moved my build surface back so the far edge is at the end stop. I then gave myself some overhang at the front. Now when I start a print I move the nozzle off the build surface at the front and prime. When I start the print, any ooz gets sliced off.
Thanks For the help
OK,
So I was thinking about it wrong.
What I needed to do was set M208 Y358, not -10.
Now 0,0 is where I want. Is there a way to set the actual travel limit so that the nozzle will stop at Y350 and not be able to go to Y360. It will do that in the slicer but is there a way to do it in the controller. Say I'm at Y0 and I hit move Y 100mm 4 times, I want it to stop at 350, still on the build bed, not stop at 360, the limit switch.
It's the Y axis that is off, but your comment applies either way.
Conceptually to treat the physical 0,0 as 0,-10 is broken. There should be a way to shift the origin so that 0,0 is physically 0,0. when the print nozzle is at the corner of the board that is really 0,0, the display should not read 0,-10.
It seems that G10 should do exactly this, is seems to for the Z axis, why is is not working for the Y axis?
Thanks
Hi,
I'm trying to reconfigure my Voron 2.4. My X limit switch is fine, mechanically it just lined up right. My Y limit switch however is behind where the nozzle would be on the build surface, about 10mm.
One thread said M201 S1 for far limit switches, but M201 anything seems to have nothing to do with it. One link on how to center the work plane goes to the old doc sight.
I read the various threads and nothing really seemed to be the right answer. I played with M208, that place my origin at not 0,0, it becomes 0,-10.
I thought G10 was exactly what I would want, seems to do the right thing with the Z axis. with the Y axis, it does nothing.
G10 P0 Y10 or G10 P0 Y-10 made no change.
Seems like this should be a stupid simple task, or maybe I'm just stupid.
Both my limit switches are far switches, 0,0 is front left.
How do I fix this?
@jay_s_uk
Hi,
Did the StealthBurner tool board come to fruition?