.83 Repetier Problem

[MSURunner]

I'm having a very unfortunate bit of luck with the .83 Repetier that I'm hoping someone's already experienced and solved before I dig through the differences in .80 and .83. When the Rostock homes before a print (as per g-code), it generates a z value 10x's the size of the actual z. Rehoming before printing a file (through the UI) generates the correct value. Thoughts?

[Lochemage]

I'm running .83 and have not seen this problem. All I can suggest right now is to make sure that BOTH your EEPROM "xyz max length" values are set to the proper numbers, AND the height value is set properly in the "Printer Settings" under the "Dimensions" task (Note, the dimension value won't actually change unless you click outside of the edit box before clicking apply).

[MSURunner]

Thanks for the reply, but I now have a bigger problem... It had worked briefly with switching back to .80 Repetier, now it no longer works with any of them. It's the damnedest thing and I have absolutely no explanation for it. It will home with the correct value of 373.2, with both the EEPROM set to 0 and 1 (deactivated and active), but the minute it gets a G28 in actual code (code that I have printed ON THIS PRINTER BEFORE), it ignores the decimal point and assumes it's now 3732.0 mm tall. I've tried downloading and redownloading and re-redownloading .80 and .83 and there seems to be no difference. Just flat out confused as hell right now... I'll probably make a video tomorrow before class starts to showcase the problem. There just seems to be absolutely no logical explanation for it other than Johan must have a dead grandmother who's spirit I've offended to the point of sending me to Rostock Purgatory.

[626Pilot]

Try 0.9.

[johnoly99]

Hey MSU,


That's entirely odd! Can you post the gcode here just in case, maybe there's some hidden character somewhere causing the issues.


Also, here's what I'd do to try and clear up any questionable firmware bug that may have inadvertantly been uploaded.

Open up arduino, go to file>examples>eeprom>eeprom_clear and that should open up a sketch in a new window. Upload that to your rambo board. This is like a 'hard' reset of any eeprom memory or firmware, and should erase any trace on the board. Then, re-load a fresh copy of the firmware. If it still has the bug, i'd be willing to bet it's in the gcode file somewhere, and would try re-slicing it to be sure


Let me know,

John

[MSURunner]

Alright so I cleared the EEPROM and uploaded a new .83 Repetier without making a single change for z-height or anything, bone stock .83 Repetier. The problem persists. I have uploaded the G-code file and a video documenting exactly what the problem is, just to clear up any confusion on what exactly is going on, in the attached Archive.zip file. Again, the g-code had printed before, now it won't. I haven't made any hardware changes from the time of working to now, double checked my wires (not that that SHOULD make a difference when you watch the video), and I'm still just lost... The video is of the .83 Repetier that I had loaded before the EEPROM clear, however, the behavior is the exact same, so I think it's still the best means of diagnostics I can give you guys... I'm just flat out LOST...


626Pilot, I've tried .83 and even the "stable" .80 that I had been running prior to switch to .83. So while I COULD try .90, I don't think it's going to make a lick of difference, because as you can see in the video, it's doing something that is entirely outside of explanation and I'm betting very good money it's not firmware related... But, if you check out the video and still think it's a firmware issue, I'm willing to try it. Worst case scenario, it tries to bore to China again...

[Eaglezsoar]

This is probably a stupid question but I will ask it anyway.
Could it be a problem with the host software?
Has the host remained the same throughout all of the firmware changes?

[MSURunner]

Not a stupid question. It's actually running through the LCD panel the entire time, so the "host," if you will, has remained the same. Good thought though. I haven't tried to print via USB, but the error is such that I don't think it'd make a difference. If you get a chance to check the video out, and think it's a host issue, I'd be willing to try USB printing...

[Eaglezsoar]

Not a stupid question. It's actually running through the LCD panel the entire time, so the "host," if you will, has remained the same. Good thought though. I haven't tried to print via USB, but the error is such that I don't think it'd make a difference. If you get a chance to check the video out, and think it's a host issue, I'd be willing to try USB printing...

After watching the video, printing through USB should not change anything. No ideas, I really thought that John's clearing of Eprom would have fixed it.

[MSURunner]

Thanks, I was hoping so too, but yeah, soooooo confusing, right?

[Lochemage]

If it's happening in the LCD control, then it has to either be the firmware or the EEPROM values.

In the Repetier firmware, make sure X_MAX_LENGTH, Y_MAX_LENGTH, and Z_MAX_LENGTH are set properly to the height of your Z axis (this is the distance from your nozzle to the platform when it is in home position, NOT the distance of your towers).

In EEPROM, the same values are overridden as "x max length" etc.

Note that if your firmware has EEPROM_MODE set to 0, your EEPROM values will not be used.

[geneb]

I suspect I know what your issue is.

Can you paste in what you've got in Cura for the "start.gcode" info under the Start/End GCode tab?

tnx.

[MSURunner]

Yep, I've checked those, and as the video shows, it generates the correct value when homing from the LCD panel (as in a plain ol' G28 command) but if the G28 is in a string of g-code (kinda necessary for Rostock to have at the beginning of a file), it ignores the decimal point and shoots off to China. It does this with both the EEPROM active and deactivated.

[MSURunner]

Geneb, I can, but the file attempted in the video is from a KS slice...

Cura Pre/Post
;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
G21 ;metric values
G90 ;absolute positioning
G92 E0 ;zero the extruded length
M107 ;start with the fan off
G28 ;move Z to min endstops
G1 Z0 Y-80.0 F{travel_speed} ;move the platform down to just above deck
G1 Z0 F5000 ;move platform down to deck
G92 E0 ;zero the extruded length
G1 F{travel_speed}
M117 Printing...

--------------------------------

;End GCode
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off (if you have it)
G92 E0 ;zero the extruded length
G1 E-1 F300 ;retract the filament a bit before lifting the nozzle, to release some of the pressure
G28




KS Pre/Post
T<EXT+0>
M104 S<TEMP>
M190 S<BEDTEMP>
M109 S<TEMP>
G28
G90
G92 E0
G1 Z1.0 Y-80.0 F9000 ;move the platform down to just above deck
G1 Z0 F5000 ;move platform down to deck
G1 E3 ;prime extruder
G92 E0 ;zero the extruded length

--------------------------------
G1 X70 Y0 F5000
G28
M104 S0
M140 S0

M84

[geneb]

In Cura, comment out all of it except the "G28" and try running the job. My Cura start is G28 plus M42 P6 S255 to turn on my PEEK fan.

g.

[MSURunner]

Okay, but the error was achieved with a KISSlicer sliced g-code file. The error is completely independent of slicer AND it's a g-code file that has successfully printed on this very machine before... I mean, I can try it, but I'm failing to comprehend what we are testing for as far as error resolution with using a different slicer... For that matter, wouldn't it be better to simply open notepad and create a two line g-code file of my own with a simple g28, g1 z200?

[geneb]

Here's my KS prefix:

M140 S<BED>
G28
M42 P6 S255

Crack open Repetier and issue a G28 followed by a G0 Z200 and see what happens.

g.

[MSURunner]

Alright, so I didn't change the KS prefix, but I did go to notepad to create a .g file with exactly as I described:

G28
G0 Z200

The problem persists. It's definitely not a slicer error. It doesn't appear to be a firmware error as we have cleared the EEPROM, and re-flashed several different (and unaltered) firmware versions, AND UI generated G28's create the correct value. The error must, then, be some sort of physical/processing error if I'm correct. My issue I'm trying to figure out lies in WHAT that could be. It was literally working perfectly fine one second then not the next, which to my logic would rule out any wire routing/interference issues that some could offer up. Thoughts?

[626Pilot]

The LCD is telling you your Z height, but AFAIK you have not confirmed this so we don't know if it's really a bad Z value or some glitch in the number formatting for the LCD. It's probably not that, but let's check that and a few other things to exclude them from the list.

For this part we're NOT going to use the SD card. Turn on the printer, connect in Repetier and just send it G28 by itself. Then look at the Z value in Repetier. What does it say there, and does that value agree with the LCD? For this part Repetier will assume the value in the printer setup dialog, so we have to get it to move so that it will get the true coordinates over serial.

Type G1 Z300 F500, get ready to hit the reset switch, and send the command. Does it move up, or down? If it moves down, does it stop after a few inches or does it want to crash into the bed? If it moved to the right position, what does it say Z is in Repetier and on the LCD?

After you do these things we should have a better idea of where the problem is.

[MSURunner]

It does really have a bad z value. There's some scarring on the deck to prove it

Perhaps I'm the only one to have encountered this, but the Mac side of Repetier doesn't want to send typed commands for me and my machine. I can press the Home All and it homes and the physical move buttons work, however typing in "G28" and pressing send doesn't work. You'll have to give me a second to download it on the Windows side of the machine...

[dpmacri]

It does really have a bad z value. There's some scarring on the deck to prove it

Perhaps I'm the only one to have encountered this, but the Mac side of Repetier doesn't want to send typed commands for me and my machine. I can press the Home All and it homes and the physical move buttons work, however typing in "G28" and pressing send doesn't work. You'll have to give me a second to download it on the Windows side of the machine...

I use the Mac version of Repetier Host (v. 0.56) exclusively and haven't had these problems. However, I'm still on the 0.80 firmware that was called "Repetier MAX". I've been meaning to upgrade but just haven't gotten around to it

[MSURunner]

Alright, so here's what happens when I send a G28 from RH (Windows side, I'll fool around with the Mac side later if I get this working).

[MSURunner]

No other ideas boys (and girls)?

[dpmacri]

I watched your little video and then tried out my machine. I had never paid attention to the LCD screen during a G28 before, but it does exactly what you describe. While the axes are moving up (assuming it wasn't already at the home position), the Z value reported is 10x what I have my Z height set to. I think that's probably by design -- assume that the build didn't somehow get off by 10x and try moving there. The end stops will kick in and then the firmware uses the "recorded" height.

So at this point, I'm curious what your problem actually is. Does the printer function correctly except that you don't like the Z value being shown during homing?

[MSURunner]

No, it doesn't reset it's height after receiving a G28 when in code. It resets itself if it's given JUST a G28, but if there's more than just the G28, it bores to China. Check out that first video...