Marlin: Bringing up UBL on a new printer...
See also #4953
Is anyone Available to assist? Marlin RCBugfix - Bilinear Leveling. it doesnt seem to correctly interpret the data from probing. and at points nearly crashes to the bed while printing
The Probing is done successfully with all the points i have tried between a total of 16 points all the way to 81 total points. all with the same effect.
It is almost like it is not correctly Implementing the data it collected to move the z axis appropriately. Or not using the data at all ( i watch the z axis and it seems to move slightly. so it not using it might be out)
I am using a BLTouch as a Probe and for the board i am using an AzteegX3( great board very nice)
here is the "config.h" file
http://pastebin.com/i5Q7hgxe
WOOKIE111
All 149 comments
RC7 or RCBugFix?
I'm trying to track down current issues with probing and leveling. I hope to have some clues soon.
thinkyhead
on 4 Oct 2016
Sorry i had thought RC Bugfix was called RC7 bugfix.
To Clarify it IS The Bugfix branch.
WOOKIE111
on 4 Oct 2016
I have the same issue. Also with the current commit https://github.com/MarlinFirmware/Marlin/commit/00261cbfcb42aa9e39995940d16e0f3a505a7fa7 this problem is still existing. Also I believe #4961 could be the same problem.
oxivanisher
on 7 Oct 2016
@WOOKIE111 @oxivanisher
What kind of machines are you on? Are you running Delta's ?
Roxy-3D
on 8 Oct 2016
@roxy-3d
I have a large Cartesian called the herculien
Gantry style like an UM
Large build area.
WOOKIE111
on 8 Oct 2016
Large build area.
Can you easily get good adhesion across the entire (and full) bed? If you have a large build area, you need to use some flavor of Mesh Bed Leveling. It turns out https://github.com/MarlinFirmware/Marlin/tree/devel-ubl is at a point where you are going to nod your head up and down.
(Bi-linear implies you are doing some type of Mesh leveling anyway.... Please give the UBL code a try. There is a little bit of a learning curve if you want to be an expert. But if you just want complete control of how your nozzle puts down the first layer, that is only 3 or 4 GCode commands to get the Whole Mesh defined. I'll coach you the whole way through the process.)
Roxy-3D
on 8 Oct 2016
@Roxy-3D Yes. if i go and use that branch i will definately need assistance
so this branch is good for a warped bed? the bed is in areas 0.5mm out... and in others inches away it can be almost 0.5 the other way.
( its the aluminum causing the warp it came pre bent from the metal supply 1/4inch Aluminum)
WOOKIE111
on 8 Oct 2016
@Roxy-3D
Yes, I am on a delta. (Kossel XL). And I am suffering the same problem as Wookie111 does with a slightly warped bed.
oxivanisher
on 8 Oct 2016
so this branch is good for a warped bed? the bed is in areas 0.5mm out... and in others inches away it can be almost 0.5 the other way.
Yes, I've got a piece of glass that has 1.25 mm up and down differences. I can get a perfect first layer every time across the entire bed. I'm getting setup to bring the code up on Delta's next, but I haven't started that work yet. Right now it is working on Cartesian and CoreXY machines.
Roxy-3D
on 8 Oct 2016
I will put time on this later today, and I hope it is related to #4961 and some others. I expect it will be something transient and (I hope) obvious, but I need to go through and do a comprehensive bug scrub. I worked on bilinear bed leveling mid-week and it did seem to be applying the height adjustment, though I didn't get a chance to use the dial indicator to solidly confirm it.
I'll ask you guys for your log output later and I can pore over those for clues as well.
thinkyhead
on 8 Oct 2016
@roxy-3D does the ubl branch pull all the goodness from rcbugfix pretty often?
gcormier
on 8 Oct 2016
does the ubl branch pull all the goodness from rcbugfix pretty often?
It was current on July 4th, 2016. I'll probably do the work to get both branches back in sync when RC-7 gets retired and RC-8 starts. Right now, the most important thing the UBL branch is missing is the BLTOUCH stuff.
Roxy-3D
on 8 Oct 2016
Gotcha. I'm using bltouch so I'll have to hold off. Super interested though because my pei sheet is convex in the middle slightly.
gcormier
on 8 Oct 2016
@Roxy-3D is there a way to contact you outside of here for assistance with my migration to the UBL from bugfix?
WOOKIE111
on 20 Oct 2016
Yes. Send me a Private Message at www.3dprintboard.com User: Roxy
Roxy-3D
on 20 Oct 2016
@WOOKIE111 Do you have everything you need to keep making progress?
Gotcha. I'm using bltouch so I'll have to hold off. Super interested though because my pei sheet is convex in the middle slightly.
@gcormier I've got a machine with a BLTouch probe now. I'm going to start bringing up the UBL Bed Leveling System on it ASAP. I'm not sure how long it will take. One problem is it has a Graphics Display and I've never had to configure my build system for that. I think I might just dedicate a spare laptop to that machine so I don't have the u8graphics library messing things up for my other machines.
But the point is... There will be a BLTouch version of the Configuration.h very soon that you can use as a starting point. And even though I don't see much value to the graphics displays, it is good to do development on a machine with a graphics display because those things eat a lot of CPU cycles. If the code works there, it will work on the normal 20x4 LCD panels too.
Roxy-3D
on 22 Oct 2016
@Roxy-3D I Have a Bltouch as well. i have a copy of marlin that everything works as expected except for the Bilinear ( namesake of the thread) so i would assume copy settings over and badda bing badda boom right?
i hwoever looked over the UBL and i dont see the BLtouch Functionality. or atleast not the easy way. and im unsure how to do it otherwise. or which bed leveling options TO use. as there seemed to be about 4 in the UBL. in the beginning of that section anyways.
WOOKIE111
on 22 Oct 2016
i hwoever looked over the UBL and i dont see the BLtouch Functionality. or atleast not the easy way. and im unsure how to do it otherwise.
Yeah, that was my point. There will soon be a Configuration.h file for UBL that gets a BLTouch all setup. (The root of this problem is UBL forked from RCBugFix just before the simple and easy BLTouch support was added.)
or which bed leveling options TO use. as there seemed to be about 4 in the UBL. in the beginning of that section anyways.
Everything is built on a High Resolution Mesh. Probably that does everything you need.
Roxy-3D
on 22 Oct 2016
@Roxy-3D
So, I've abandoned the BLTouch as I was unable to get acceptable performance out of it. Variance of 0.1mm is unacceptable to me when my inductive probe is doing 0.01mm, an order of magnitude better. My bed is a MIC6 piece of Aluminum, so very very flat. The PEI on top, not quite so flat unfortunately. UBL will be interesting to me if you can manually edit it, as my inductive sensor will still pick up a perfectly flat bed underneath the surface of the PEI.
Please, let me know how your results with BLTouch are though.
gcormier
on 22 Oct 2016
I got a BLTouch but haven't had a chance to install it yet. @gcormier Is your BLTouch variance easily seen with M48? And neither slower probing nor double-touch probing makes much difference?
thinkyhead
on 22 Oct 2016
Correct - the newly min/max M48 additions highlight the issues quite nicely.
I believe I had my Z SLOW speed down to (ZHOMING / 5)... no changes.
(Also note, I'm not blaming Marlin in this case - this repeatability was consistent across RC6, RC7 and RCBugFix. I believe the BLTouch unit I have is faulty.)
gcormier
on 22 Oct 2016
@gcormier Yeah mine as well. that or they need to stop saying they have a repeatability of 0.0001 cause thats a bold lie. best i have got is 0.02 with an m48 but that was once only. other times has been as high as 0.3 ( yes im Jim Stone on G+ )
but in our cases. we cant use inductive probes we need a touching probes because we need to pickup the variance of a material on top ( mine being glass yours being pei.)
I think im just about done modifying UBL Marlin. i just need to add the BLTouch in the hardway ( servo and angles n stuff.)
i will let you know if accuracy some how magically improves. but i doubt it. because it isnt firmware problem, its a hardware problem.
but the interpretation ( thread name) IS firmware problem. as the BLTouch only can say ok that point was Xunits
WOOKIE111
on 22 Oct 2016
With no tuning or alterations... (Just using the factory supplied firmware image) M48 V4 in the center of the bed gives a Standard Deviation of .047mm for me using the supplied BLTouch probe.
That seems a bit high. Maybe I can get that lower with some tuning.
Roxy-3D
on 22 Oct 2016
It doesn't surprise me that BLTouch isn't the most accurate probe. That electro-magnet probably has some variance. There are plenty of Google results to back this up.
thinkyhead
on 22 Oct 2016
@Roxy-3D ok. i got it setup and ran a g29 p1 m ( im assuming thats correct)
now would i use m500 afterwards as normal? and do i have to redo the g29 everytime a home is done?
WOOKIE111
on 25 Oct 2016
ok. i got it setup and ran a g29 p1 m
Really... You should start the process with a G29 P1 O The M is still honored, but it confuses some host programs. And if you want to be lazy, do a G29 P3 R C .25 O followed by a G29 A S1 and you will be good to go. You would probably want to do a Mesh Validation Print to see where you are at with a: G29 P C O 2.0 And then if you need to, you go edit any area of the mesh that is less than perfect by moving the nozzle there and doing a G29 P4 R O . When happy with things, do another G29 S1
Roxy-3D
on 25 Oct 2016
@Roxy-3D So.... for a starting gcode when printing do i need to do the whole g29 thing again. or is it ok to just do a g28 and it will follow the matrix
WOOKIE111
on 26 Oct 2016
So.... for a starting gcode when printing do i need to do the whole g29 thing again. or is it ok to just do a g28 and it will follow the matrix.
It depends on how you set things up. I've allowed backward compatibility where you have to run a G28 and then do a G29 to get the bed leveling active. But if you save a Mesh to one of the EEPROM Mesh Slots with the UBL System Active.... It will be active when the printer powers up (or resets). In that case you never need to another G29 until you want to change something. The UBL System is active and doing its thing all the time.
I want the bed leveling system alive and functioning when my printer powers up. So of course, I make sure that happens. But if you want to have control over everything you can save the Mesh to some slot with the system de-active. And in that case you can do a G28 and until you do a G29 A the system will not be correcting things. (The last Mesh Slot you saved something will be loaded automatically. If you want to use a different mesh, you will have to do a G29 L5 A to load Slot 5's mesh and activate it.)
Roxy-3D
on 26 Oct 2016
@Roxy-3D as to how ive set things up? erm i dont quite understand.
all i did was modify the config.h file to fit the motor steps etc. and as for everything else you have said. well thats a small migraine in itself XD i understood very little of that
WOOKIE111
on 26 Oct 2016
I'm sorry... You can try a few things just to get the feel of things and see how things work. Try this:
- Bring up the printer and do a G28
- G29 P0 O To zero the entire mesh and print it out.
- G29 A To activate the system
- G29 S1 Save the mesh (that right now is entirely 0.000 to mesh slot 1)
- G26 P C O 3.0 To print a Mesh Validation Pattern. (Remember... there really is no correction yet) (You may need to also specify your filament diameter, nozzle size and bed and nozzle temps)
- G29 P4 R O Move the nozzle to any bad area of the pattern, and edit the mesh point up or down. Press and Hold the encoder wheel when you want to move to a new area. Move to a new 'bad area' and repeat the command again.
- G29 S1 Save the updated mesh to slot 1. Now, go back up to the G26 P C O 3.0 and give it another try.
Once you get a decent Mesh Validation Print... You can just turn on your printer, and it will use the correction matrix for any print you do. You will see the Z-Axis moving back and forth as the nozzle moves around on the bed (assuming you have the nozzle low enough you are below the 'Fade Height')
But @WOOKIE111, lets either start a new thread or change the title of this one if you want to continue this discussion. This thread didn't start of as a UBL thread. We should try to keep things a little bit organized.
Roxy-3D
on 26 Oct 2016
In order i did this
G29 P1 O ( it started probing)
After it finished i did these
G29 P3 R C .25 O
G29 A S1
G29 P C O 2.0
However they didnt seem to echo back...did they work?
G29 P3 R C .25 O
SENDING:G29 P3 R C .25 O
g29 a s1
SENDING:G29 A S1
G29 P C O 2.0
SENDING:G29 P C O 2.0
as an extra here is the probing results
http://pastebin.com/HUnLGEW3
edit:
Running a straight G26 attempts to activate a non existant heated bed ( temporary) and thusly trips the dangerous temp kill.
G26 B0 gives an error for implausible bed temp.
is there a way to bypass this?
WOOKIE111
on 26 Oct 2016
Change the code to be this. (There is just an extra 'if' statement and a closing brace)
bool turn_on_heaters() {
#if ENABLED(ULTRA_LCD)
if ( bed_temp > 25 ) {
lcd_setstatus( "G26 Heating Bed. ", true);
lcd_quick_feedback();
#endif
UBL_has_control_of_LCD_Panel++;
thermalManager.setTargetBed( bed_temp );
while( abs(thermalManager.degBed()-bed_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while( abs(thermalManager.degBed()-bed_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while ( G29_lcd_clicked() ) // Debounce the switch
idle();
lcd_setstatus( "Leaving G26 ", true); // Now we do it right.
return 1;
}
idle();
}
#if ENABLED(ULTRA_LCD)
}
lcd_setstatus( "G26 Heating Nozzle. ", true);
lcd_quick_feedback();
#endif
And then specify a bed temperature of 22 (room temperature). That should get you further into the process. Sorry about that... This was developed on a machine with a heated bed. Of course I should have realized some people don't use a heated bed. But this is the first time it has been pointed out.
Roxy-3D
on 26 Oct 2016
@Roxy-3D wow...where is that? ive only seen Config.h and this doesnt look like it
WOOKIE111
on 26 Oct 2016
About 975 lines into G26_Mesh_Validation_Tool.cpp I've changed the title... And marked it as a UBL thread.
Roxy-3D
on 26 Oct 2016
that works at 22? even without a thermosistor in the bed spot?
WOOKIE111
on 26 Oct 2016
Well... It isn't an elegant 'fix'. But it isn't going to tell the bed to heat up if you add that code and specify a temperature of 22 degrees. It's going to be ignored. At the very end of the command, when it turns off the heaters, there may be an issue. If so, you can add a 'K' to keep the heaters on. So it would be G26 C K P O 3.0 and then it won't turn off the heaters. Or alternatively, you can let it get an error at the very end, and just restart the printer. The important thing is you have a Mesh Validation Pattern partially printed so you can see what has to happen to make the mesh definition better.
Roxy-3D
on 26 Oct 2016
im not sure if this has any merit. but i have found out why i cant get any commands in after runnign the probe.
my LCD says M105 for some reason. which perhaps may be blocking further actions.
i can affirm this because i can run the commands after rebooting everything
but if i run a probe. the screen will say something along the lines of G29 UBL Active
but after it completes the LCD stays at m105
WOOKIE111
on 26 Oct 2016
Hmmm... Are you saying your LCD Panel is injecting an M105 all by itself? I don't understand what you are seeing.
But let's see if we can get you up and running without using the probe. That will be valuable for other people.
Roxy-3D
on 26 Oct 2016
Uh, isnt the point of UBL to use a probe for an uneven bed? or have i been mistaken? im really confused now.
WOOKIE111
on 26 Oct 2016
Uh, isnt the point of UBL to use a probe for an uneven bed? or have i been mistaken? im really confused now.
No! The purpose is to provide perfect correction for non-flat and non-level beds. UBL will use the probe to acquire much of the information if the probe is available. But the steps I was giving you were to get you setup without even using the probe. Even if the printer has a Z-Probe, there are parts of the bed that can not be reached by the probe because the probe is usually offset from the nozzle. For these points, even if the bulk of the mesh is generated with the probe, other methods have to be deployed to get those values defined.
What we are doing is getting the whole mesh defined for your bed without using the probe.
Does that make sense?
Roxy-3D
on 26 Oct 2016
alrighty. that i understand.
now i have got the probe points from
G29 P1 O
then i saved it with
G29 S1
i then attempted to print something with the starting Gcode of
G28
G29 A
G29 L1
it seemed to apply the matrix. but in a few areas it still got much too close to the bed. and partially plugging the nozzle in areas because it was that close.
so i guess this is where the manual bit would apply?
WOOKIE111
on 26 Oct 2016
also when implementing this code
bool turn_on_heaters() {
#if ENABLED(ULTRA_LCD)
if ( bed_temp > 25 ) {
lcd_setstatus( "G26 Heating Bed. ", true);
lcd_quick_feedback();
#endif
UBL_has_control_of_LCD_Panel++;
thermalManager.setTargetBed( bed_temp );
while( abs(thermalManager.degBed()-bed_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while( abs(thermalManager.degBed()-bed_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while ( G29_lcd_clicked() ) // Debounce the switch
idle();
lcd_setstatus( "Leaving G26 ", true); // Now we do it right.
return 1;
}
idle();
}
#if ENABLED(ULTRA_LCD)
}
lcd_setstatus( "G26 Heating Nozzle. ", true);
lcd_quick_feedback();
#endif
into the area... i get this error in arduino
a function-definition is not allowed here before '{' token
and it highlights this
void prime_nozzle() {
it seemed to apply the matrix. but in a few areas it still got much too close to the bed. and partially plugging the nozzle in areas because it was that close.
You should do G26's until the Mesh Validation Pattern is perfect every where. We are starting with a totally unprobed bed. (just to prove the UBL System can be used effectively without a Z-Probe) The Mesh was all 0.0000's at the start. So it is going to take a few iterations to get the Mesh 'Right'. (Also... You have no experience how much to raise or lower the given Mesh Points based on what the pattern looks like. That alone is going to add an iteration to the process.) But after an hour of printing test patterns and editing the mesh... You are going to get a perfect 1st layer everywhere on the bed, every time. If you are doing a 10 x 10 Mesh... It will play out that way even with the horrible piece of glass I'm using right now.
I uploaded a better G26. It might fix that issue if you want to give it a try. Be sure you don't over write your currently some what working Configuration.h file. Here is the code cut and pasted out of G26. It should fix your compile error if you don't want to pull down the whole code base:
bool turn_on_heaters() {
#if HAS_TEMP_BED
#if ENABLED(ULTRA_LCD)
if ( bed_temp > 25 ) {
lcd_setstatus( "G26 Heating Bed. ", true);
lcd_quick_feedback();
#endif
UBL_has_control_of_LCD_Panel++;
thermalManager.setTargetBed( bed_temp );
while( abs(thermalManager.degBed()-bed_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while ( G29_lcd_clicked() ) // Debounce the switch
idle();
lcd_setstatus( "Leaving G26 ", true); // Now we do it right.
return 1;
}
idle();
}
#if ENABLED(ULTRA_LCD)
}
lcd_setstatus( "G26 Heating Nozzle. ", true);
lcd_quick_feedback();
#endif
#endif
//
// Now turn on the hotend (nozzle) and wait for it to come up to
// temperature.
thermalManager.setTargetHotend( hotend_temp , 0 );
while( abs(thermalManager.degHotend(0)-hotend_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while ( G29_lcd_clicked() ) // Debounce the switch
idle();
lcd_setstatus( "Leaving G26 ", true); // Now we do it right.
return 1;
}
idle();
}
#if ENABLED(ULTRA_LCD)
lcd_setstatus( " ", true);
lcd_quick_feedback();
#endif
return 0;
}
@Roxy-3D when doing the G29 P4 R O should i expect the nozzle gap to change while using the scroll wheel? or are we estimating. when i used that command it didnt move to z0 is that normal? also when a g1 z0 is issued then the G29 P4 R O the z moves to z13
WOOKIE111
on 27 Oct 2016
when doing the G29 P4 R O should i expect the nozzle gap to change while using the scroll wheel? or are we estimating.
@WOOKIE No... You should not see much movement of the nozzle up or down while editing a Mesh Point. The nozzle is moved to the Mesh Point but raised enough it can safely move around. The nozzle is positioned over the Mesh Point so you can easily tell what you are editing. And as you edit each Mesh Point, it moves to the next one until the editing in that area is complete.
when i used that command it didn't move to z0 is that normal? also when a g1 z0 is issued then the G29 P4 R O the z moves to z13
G1 Z0.000 should move the nozzle to just touch the glass. But Z-Axis only moves are a special case. I'm not sure without digging through some stuff. You might want to do a G1 X100 followed by a G1 Z0.000 to see if you get the desired behavior. (The Fade Height multiplier is cached to reduce floating point operations. It is possible you have to do some movement after the G29 P4 to refresh the variables.)
Roxy-3D
on 27 Oct 2016
well no matter how high or low i put the z axis before hand with a g1 z# ...... as soon as i do the G29 P4 R O it moves to the first mesh point. and z13 and rotating the knob either direction even into full numbers doesnt cause the bed to move.
WOOKIE111
on 27 Oct 2016
so at this point since the gap doesnt move from z13. everything i put in on the lcd is a guess.
is that the point? guesstimation? or am i supposed to actually be using a feeler gauge or paper
WOOKIE111
on 27 Oct 2016
That is correct behaviour. The Z=13 is your Z_RAISE_BETWEEN_PROBINGS number. That is a known safe height to move the nozzle around. When you turn the Encoder Wheel at a given Mesh Point while doing a G29 P4 R O command, you are raising or lowering that Mesh Point. (You are not actually moving the nozzle at that point in time.) If you check the Map before you start editing a point, and check the map after, you should see the change reflected at that location on the map.
As for how much to turn the Encoder Wheel? Well... You get a feel for it pretty quickly. You want the lines drawn by the Mesh Validation Pattern print to be squished out a little bit and flat. But you don't want them squeezed so thin you can barely see any plastic being put down.
If your layer height is .25mm, if you have any adhesion at all, you probably only want to drop the mesh point by .15mm at a time. If you do the Mesh Validation Print, you should have some locations that you can see the filament is a little bit rounded and not squished into the glass. Go edit a couple of those points and lower them by .10mm or .15mm. You will get a feel for how much to raise or lower things very quickly.
I don't even look at the LCD Panel when doing a new Mesh. I just look to see where the nozzle is and turn the dial close to the right amount. You will be doing the same thing very soon.
Roxy-3D
on 27 Oct 2016
so. is going negative making the hotend closer?
WOOKIE111
on 27 Oct 2016
so. is going negative making the hotend closer?
You don't have enough text here for me to be sure what you are asking. But when you are editing a Mesh Point with the G29 P4 sub-command... Going negative means you want the nozzle to move closer to bed in this area of the mesh. If the bed was perfectly flat, you would want 0.0000's everywhere. But if you had a perfectly flat bed with a small dip in one area, you would indicate that by putting the Mesh Points in that area at a negative value.
Roxy-3D
on 27 Oct 2016
Precisely what I meant.
thank you again. I stopped trying a few hours ago (about 20 mins fter my last question.) but I shall try again tomorrow. and pester you more! :P
WOOKIE111
on 27 Oct 2016
When you can get a G26 P C O 3.0 to partially print... Post a picture. It will help the discussion. When you can see the Validation Pattern, it becomes very clear what needs to be adjusted. (Post a G29 O map also!)
Roxy-3D
on 27 Oct 2016
here is the baseline. a map of all 0's
http://imgur.com/a/mFdYT
next up is the first modifiation
WOOKIE111
on 27 Oct 2016
Bed Topography Report:
(0,9) (9,9)
(0,338) (358,338)
0.01000 0.06000 0.05000 0.04000 0.05000 0.06000 0.10000 0.10000 0.15000 0.16000
-0.10000 0.05000 0.01500 0.02000 0.05000 0.02000 0.07000 0.06000 0.04500 0.15000
-0.10000 0.05000 0.05000 0.05000 0.07500 0.02000 0.07000 0.04000 0.05000 0.10000
-0.10000 -0.10000 -0.10000 0.05000 0.05000 0.02000 0.05000 0.03000 0.02000 0.07000
-0.15000 -0.10000 -0.10000 -0.10000 -0.15000 -0.15000 0.05000 -0.10000 -0.10000 0.01000
-0.10000 -0.10000 -0.10000 -0.10000 -0.12500 -0.10000 -0.10000 -0.10000 -0.10000 -0.10000
-0.15000 -0.10000 -0.10000 -0.10000 -0.10000 -0.10000 -0.10000 -0.10000 -0.10000 -0.10000
-0.15000 -0.10000 -0.10000 -0.15000 -0.10000 -0.15000 -0.10000 -0.15000 -0.15000 -0.15000
-0.15000 -0.15000 -0.15000 -0.10000 -0.10000 -0.15000 -0.10000 -0.15000 -0.15000 -0.15000
[-0.15000] -0.15000 -0.15000 -0.15000 -0.15000 -0.15000 -0.10000 -0.15000 -0.15000 -0.15000
(0,0) (358,0)
(0,0) (9,0)
TEST
I'm sure you have already made edits. (I wouldn't be patient enough to wait!) But it looks to me like the Center needs to be a little bit more positive. (I can't really see the lines. I'm assuming they are there but they are squished very thin. If they just did not stick and got pulled off the glass, what I'm saying is not true.)
And the middle part close to you (when taking the picture) needs to be made a little bit more negative. (Remember, the "mesh values" get added to the nozzle height. So a negative number pulls the nozzle down.)
Don't go crazy on the amount you change things. And given Mesh Point affects things all the way to the next Mesh Point in all directions. But its impact drops as you move further away from the center of the Mesh point.
With all that said... The goal is to get you comfortable using the encoder wheel to adjust the points up or down. Soon, you won't be looking at the LCD Panel. You will be looking to see where the nozzle moved. Once you get to that point, you can make a new mesh very quickly.
Are you printing on glass? It kind of looks like you are printing straight on the metal bed. I hope it is on glass because it is much easier to get the validation print off the glass if you can put it in the freezer for 10 minutes.
Roxy-3D
on 27 Oct 2016
Bed Topography Report:
(0,9) (9,9)
(0,338) (358,338)
0.02000 0.07000 0.05500 0.05000 0.06000 0.07000 0.13000 0.13000 0.17500 0.18500
-0.09500 0.04000 0.00500 0.02000 0.06000 0.02000 0.08500 0.07000 0.06000 0.16500
-0.10500 0.04000 0.04500 0.04500 0.08500 0.02000 0.08000 0.06000 0.06000 0.13000
-0.10000 -0.08000 -0.08000 0.06000 0.06000 0.02000 0.07000 0.04000 0.03000 0.08000
-0.15000 -0.08500 -0.08500 -0.08500 [-0.10000] -0.10000 0.05000 -0.08500 -0.10500 0.02000
-0.10500 -0.08000 -0.10000 -0.07500 -0.05000 -0.09500 -0.08500 -0.08500 -0.10500 -0.08500
-0.15500 -0.10500 -0.10500 -0.10500 -0.08500 -0.10000 -0.09500 -0.10500 -0.10500 -0.10500
-0.15500 -0.10500 -0.10500 -0.15500 -0.10500 -0.15500 -0.10500 -0.16000 -0.15500 -0.16500
-0.15000 -0.15500 -0.15000 -0.10500 -0.10500 -0.15500 -0.10500 -0.15500 -0.16500 -0.15500
-0.16000 -0.15000 -0.15500 -0.15500 -0.15500 -0.17000 -0.10500 -0.16500 -0.15500 -0.11000
(0,0) (358,0)
(0,0) (9,0)
Getting better!!!!! Soon you won't be looking at the LCD Panel! :)
Roxy-3D
on 27 Oct 2016
@WOOKIE111 I fixed a bug in the G26_Mesh_Validation_Tool.cpp file. Some of those inconsistencies we were seeing in your pictures were probably caused by the bug. If you grab the current .ZIP file, and reprint the G26 Mesh Validation Pattern, we will get more accurate results of how close your mesh is to 'correct'.
I've lowered the amount of filament extruded per mm of travel (by about 20%). This makes it easier to see where the filament is squished a little bit into the glass. And it makes it easier to see where the filament is not squished and round in shape (indicating the nozzle needs to be a little bit lower).
@adamfilip I suspect this bug was affecting you also.
Roxy-3D
on 28 Oct 2016
@Roxy-3D Inconsistencies? like what. if anything i noticed the circles were flat sided.
but does this mean i can use my probe?
WOOKIE111
on 28 Oct 2016
The circles are really constructed with 12 straight lines. The are not really circles. That is fine.
But no... What I meant was if the filament looks very thin in some places, it may not be because the nozzle was pressing down super hard on the glass. I found a bug that is now fixed. (Please upload the new code to your board!!!) The filament extrusion is much more uniform now and you can draw better conclusions about what the 'right' action is at a given area of the Validation Pattern.
As for using your probe... If you want to generate a Mesh from scratch using it... Sure go ahead. But the mesh you have in that last picture is getting pretty close to correct (one or two more iterations and it will be perfect.) There is no reason not to experiment with your Z-Probe. Just save your current mesh in a mesh slot where you won't accidentally over write it. It will still be there later if you want to get it back. (For all intrinsic purposes... You have already proven a viable mesh can be generated without even using the Z-Probe!!!)
Roxy-3D
on 28 Oct 2016
@Roxy-3D
error compiling when copy pasta the previous code because of lacking bed heater
bool turn_on_heaters() {
#if HAS_TEMP_BED
#if ENABLED(ULTRA_LCD)
if ( bed_temp > 25 ) {
lcd_setstatus( "G26 Heating Bed. ", true);
lcd_quick_feedback();
#endif
UBL_has_control_of_LCD_Panel++;
thermalManager.setTargetBed( bed_temp );
while( abs(thermalManager.degBed()-bed_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while ( G29_lcd_clicked() ) // Debounce the switch
idle();
lcd_setstatus( "Leaving G26 ", true); // Now we do it right.
return 1;
}
idle();
}
#if ENABLED(ULTRA_LCD)
}
lcd_setstatus( "G26 Heating Nozzle. ", true);
lcd_quick_feedback();
#endif
#endif
//
// Now turn on the hotend (nozzle) and wait for it to come up to
// temperature.
thermalManager.setTargetHotend( hotend_temp , 0 );
while( abs(thermalManager.degHotend(0)-hotend_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while ( G29_lcd_clicked() ) // Debounce the switch
idle();
lcd_setstatus( "Leaving G26 ", true); // Now we do it right.
return 1;
}
idle();
}
#if ENABLED(ULTRA_LCD)
lcd_setstatus( " ", true);
lcd_quick_feedback();
#endif
return 0;
}
it spat out this long line in arduino flashing IDE ( dunno the real name XD)
Arduino: 1.6.12 (Windows 7), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"
In file included from C:\Users\James\Desktop\Marlin-devel-ubl10242016\Marlin-devel-ubl\Marlin-devel-ubl\Marlin\Marlin.ino:37:0:
sketch\Configuration.h:779:0: warning: "DEFAULT_ZJERK" redefined
#define DEFAULT_ZJERK 0.4 // (mm/sec)
^
sketch\Configuration.h:771:0: note: this is the location of the previous definition
#define DEFAULT_ZJERK 1.0 // (mm/sec)
^
In file included from sketch\thermistortables.h:26:0,
from sketch\Configuration.h:1242,
from C:\Users\James\Desktop\Marlin-devel-ubl10242016\Marlin-devel-ubl\Marlin-devel-ubl\Marlin\Marlin.ino:37:
sketch\Marlin.h:349:0: warning: "RAW_CURRENT_POSITION" redefined
#define RAW_CURRENT_POSITION(AXIS) RAW_POSITION(current_position[AXIS], AXIS)
^
In file included from sketch\thermistortables.h:26:0,
from sketch\Configuration.h:1242,
from C:\Users\James\Desktop\Marlin-devel-ubl10242016\Marlin-devel-ubl\Marlin-devel-ubl\Marlin\Marlin.ino:37:
sketch\Marlin.h:140:0: note: this is the location of the previous definition
#define RAW_CURRENT_POSITION(AXIS) (RAW_POSITION(current_position[AXIS], AXIS))
^
C:\Users\James\AppData\Local\Temp\ccyS1ZMI.ltrans3.ltrans.o: In function `gcode_G26()':
ccyS1ZMI.ltrans3.o:(.text+0x7f6): undefined reference to `chirp_at_user()'
ccyS1ZMI.ltrans3.o:(.text+0x81c): undefined reference to `chirp_at_user()'
collect2.exe: error: ld returned 1 exit status
exit status 1
Error compiling for board Arduino/Genuino Mega or Mega 2560.
This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
@WOOKIE111 I believe I've already put the extra code to correctly handle a missing bed heater into the repository.
if ( !Keep_Heaters_On) {
#if HAS_TEMP_BED
thermalManager.setTargetBed( 0.0 );
#endif
thermalManager.setTargetHotend( 0.0 , 0 );
}
and
bool turn_on_heaters() {
#if HAS_TEMP_BED
#if ENABLED(ULTRA_LCD)
if ( bed_temp > 25 ) {
lcd_setstatus( "G26 Heating Bed. ", true);
lcd_quick_feedback();
#endif
UBL_has_control_of_LCD_Panel++;
thermalManager.setTargetBed( bed_temp );
while( abs(thermalManager.degBed()-bed_temp) > 3 ) {
if ( G29_lcd_clicked() ) {
strcpy( lcd_status_message, "Leaving G26 "); // We can't do lcd_setstatus() without having it continue;
while ( G29_lcd_clicked() ) // Debounce the switch
idle();
lcd_setstatus( "Leaving G26 ", true); // Now we do it right.
return 1;
}
idle();
}
#if ENABLED(ULTRA_LCD)
}
lcd_setstatus( "G26 Heating Nozzle. ", true);
lcd_quick_feedback();
#endif
#endif
and
if ( !Keep_Heaters_On) {
#if HAS_TEMP_BED
thermalManager.setTargetBed( 0.0 );
#endif
thermalManager.setTargetHotend( 0.0 , 0 );
}
lcd_init(); // Some people's LCD Displays are locking up. This might help them
}
I just pulled down the current repository and compiled it. It compiles clean. You don't need to mess with the code. Just get the Configuration.h file setup correctly and I think it should compile clean for you. Get it running and lets see a G29 Mesh Validation Pattern without the extrusion bug adding uncertainty! :)
(The G26 Heating Nozzle won't happen without a heated bed.... But I'll clean that up later. You don't need that right now. If you want the message right now... you can warm over the tail end of that code to be: )
#endif
#if ENABLED(ULTRA_LCD)
}
lcd_setstatus( "G26 Heating Nozzle. ", true);
lcd_quick_feedback();
#endif
//
// Now turn on the hotend (nozzle) and wait for it to come up to
// temperature.
If I save a mesh with g29 s1 then a m500
I then update firmware and do a m502 m500 the mesh is gone.
adamfilip
on 29 Oct 2016
@adamfilip
That is because M502 Is the command to reset EEPROM to factory settings ( aka whatever that version of marlin says is original) so yes it would remove the mesh as the factory setting is without one or with a one of all 0's i think
and you know that M500 then saves all EEPROM
G29 S1 is just a specific way to save a mesh to a slot in EEPROM ( which can be reset with M502 and saved with M500 which you did)
While Building a Mesh i found myself to use multiple slots ( cant explain why)
@Roxy-3D
Yeah i cant explain how or why. but things compile now
what i was doing was copying the g26 file from the new zip and dumping it in the old. as well as implementing the old blurb of code i had from you.
but when i took config and all the pins files i had changed and pasted them into the new zip, it all compiled correctly. i then had put the blurb of code in from you.
When i get the mesh sorted out i will do the same working sequence but leave out the modify of g26 with that code. gotta see if the un edited new code works ;)
also i did a few more mesh iterations. and they look MUCH better with the new zip.
WOOKIE111
on 29 Oct 2016
If I save a mesh with g29 s1 then a m500. I then update firmware and do a m502 m500 the mesh is gone.
I did intend for the saved mesh patterns to survive across a M502 / M500 pair. But I might have a mistake in that code. In general, ALL of the mesh patterns should survive. But my guess is you are seeing the 'active mesh slot' get clobbered. This isn't a long term work around, but if you save your mesh in a couple of slots prior to doing a M502 / M500 pair, my guess is all but the 'Active mesh slot' are OK.
Would this solution be acceptable: A M502 zeros the active mesh (in RAM memory) and the active slot gets reset to 0. If a M500 happens, the zero'ed mesh in RAM gets saved to mesh slot 0 ? Slot 0 would still get cleared, but we could document that as the 'defined behavior'. Alternatively, we could just save the UBL State information with no active slot number and the system turned off. And not touch any of the saved mesh patterns. That 2nd approach might be more faithful to the expected M502 behavior.
Roxy-3D
on 29 Oct 2016
@adamfilip The more I think about it... I think the 'Correct' thing for M502 to do to UBL is deactivate it, set the default mesh slot to 'Undefined' and to invalidate the entire Mesh (in RAM memory). And do absolutely nothing to any Mesh's that are stored in EEPROM. And going a little bit further, I think the 'Correct' thing for M500 to do is just save this current state in the EEPROM and not mess with any of the previously stored Mesh's.
Would you be comfortable with that behavior? You would still be able to load a previously saved Mesh from the EEPROM, and Activate the UBL System. And if you choose to make the system come up automatically, you would just have to re-save the Mesh with the system in the Active state.
Roxy-3D
on 30 Oct 2016
That sounds fine..is there anyway to save the mesh to the SD card.. or output the current mesh to some code that could be added back later. example run some command with a long string to load a previous mesh
G29 s1 4.0 -3.5 -5.5 -6.5 -5 -3 -5 -3 -2 -4 -2 etc..
so before you update firmware you can display the saved mesh values.. copy and save that and then load it in again after M502 and M500 wipes it out.
adamfilip
on 30 Oct 2016
That sounds fine..is there anyway to save the mesh to the SD card.
I guess I have a couple of comments. First, if things work correctly and you never lose a mesh stored in the EEPROM, there is still a need to move that mesh to another controller board. Once you get the mesh perfectly defined for a given piece of glass, there is no rule that says that piece of glass can only be used on the original printer. And of course, there is the obvious reason to back up your data externally to the system!
Let me think about it. It shouldn't be too hard too do. There are already some of the original Mesh commands to set Mesh points to a given value. M421 could be used to reconstruct a mesh if the worst case situation happens. Or for that matter, if you want to move the mesh to another machine. It would be almost trivial to dump the mesh in a form that it could be fed back into a (or another) system using M421. But here is the rub... The mesh has to have the same dimensions for that to work. You can't have a 10 x 10 mesh on one machine and think you can feed that into a 9 x 11 mesh on another machine.
And Adam... I feel bad about you losing your mesh! I've already made changes to my code base to make sure that doesn't happen again. But with that said.... We should do something to let you store your mesh off-line and out of the controller board's EEPROM. Let's think about it and come up with a good solution!
I do like the idea of saving to an SD-Memory card. The only problem with doing that is it is a bunch more work and it is going to be harder to debug and make sure everything is right. It might be best to set that as a goal, but just generate M421 commands initially that can be saved in the case of a disaster.
Roxy-3D
on 30 Oct 2016
I vote for "exporting" the mesh as the text of the GCode that recreates it.
thinkyhead
on 30 Oct 2016
I vote for "exporting" the mesh as the text of the GCode that recreates it.
@adamfilip There is now a G29 E option to 'Export' the Mesh so you can save it. I have done some testing to ensure it works properly. I am able to reconstruct my Mesh even with invalidated areas in it. You just do a G29 E with your Mesh loaded and save the output to a file for later use. To use it, just load the file in PronterFace and say 'Print'.
But going forward... I now have M502 and M500 so they will not make any assumptions about what to do with the stored Mesh patterns. (This is not uploaded yet to the repository. Just the G29 E is uploaded) M502 will deactivate the UBL System and tell it there is no default Mesh to load. It will also invalidate the Mesh in RAM. If you do M500 at that point, the system will be turned off until you do something to turn it on. But all of your Mesh patterns will still be safely stored in the EEPROM for later use.
Roxy-3D
on 30 Oct 2016
@Roxy-3D I just tried to make a print. it still is behaving the same as RCBugfix and my initial problems.
the mesh matrix had 0 low spots. but yet the 3d print is showing it grinding onto the bed :(
yet its showing this in the skirt of a print
The starting Gcode is as follows
G28
G29 A
G29 L1
Attached is the Gcode File in txt format
bedTest190oct30.txt
WOOKIE111
on 31 Oct 2016
That is very strange! (Those pictures are very helpful to understand what you are seeing!!!) The thing that doesn't make any sense is the skirt is OK up to the Mesh Point, and then it drops out until the next Mesh Point and looks OK again.
What happens if you let the print continue? At least with Slic3r, it puts out less material for the skirt than it does when it is actually doing the print.
Roxy-3D
on 31 Oct 2016
I give up on this. no matter what i change in that area of the mesh.
ive only been increasing the gap in the problem areas AND surrounding nodes. and yet i get really close to having it nice with a few problem areas, when using the print i use to test after printing a map ( the map looks wonderful btw) and yes i do save the map with G29 s1
or it is almost like it goes back 10 steps and uses a shitty map or something. either way my high spots in the surface arent being taken care of in a print. yet the maps are looking good
this is incredibly frustrating
and i have been letting the print continue and the print just starts showing off more areas that wont change no matter how much adjustment.....
yet the map looks pretty perfect. yet the print is scraping and grinding
WOOKIE111
on 1 Nov 2016
Can you tell if those 'thin' parts of the Mesh Validation Pattern happened because the nozzle was too close to the glass? Or maybe it wasn't extruding enough filament?
Also... Can you please do a G29 W and verify the UBL System is Active!
I don't know what to tell you. But one thing to try is put the nozzle .25mm above the bed. Can you use PronterFace to move the nozzle over those high spots and see if it even tries to track the bed by going up and then coming back down.
Roxy-3D
on 1 Nov 2016
ok...the mesh validation pattern comes out fine. heck i can get it to print so it barely sticks and is barely squished. the thing is...
when i go to do a real print. there are areas that are touching if not scraping the hotend. on hte first layer. i dare not go higher if it cant finish the first!
and from my noticing unless printing. the bed doesnt move as if influenced by the mesh and yes the mesh is active. i always make sure with a G29 A
WOOKIE111
on 2 Nov 2016
Does mesh bed leveling take into account Z-offset (M851 ?) I hope it does :)
Yesterday had catastrophic crash, almost snapped extruder off X carriage. Did G29 P1 O, went G26 P C O 3.0 H230 B90. Since around 1/3 of bed was not good, I went with G29 P4 R O in order to adjust problematic areas. Only did move some spots -0.05-0.1 that were not sticking on bed in first G26. I did not have time to stay and monitor printing second G26 (super big mistake!!!) and when I returned, extruder crashed into bed and keept going totally ignoring triggered Z-probe. Extruder was like 15 degrees tilted to bed because motors were forcing it down. Crazy. Obviously I screwed up but this looks like I entered 0.5mm instead of 0.05 during tuning mesh. Is there any chance to get nozzle to actual height during tuning? Because it only output measured height on lcd, but nozzle is not moving vertically.
ngarafol
on 2 Nov 2016
@WOOKIE111 can you post your G29 O W information?
Is there any chance to get nozzle to actual height during tuning? Because it only output measured height on lcd, but nozzle is not moving vertically.
Originally, that was the plan. And then when a Mesh Point was edited and confirmed, the nozzle would raise to Z_RAISE_BETWEEN_PROBINGS. It was kind of problematic. First there was always some oooze coming out of the nozzle that affected things and kept you from seeing exactly where the nozzle was. But also it took a lot of time to do the raise and lower of the nozzle.
@ngarafol can you post a map so we can see how bad your bed is?
Roxy-3D
on 2 Nov 2016
Oh, I see. Ooze makes sense. But sometimes I get confused what is up and what is down :) If I want to tune higher positive spot I have to go lower, if I tune low negative spot I have to go higher value, 0 is always reference point, right?
Will post map when I get to the printer. But basically its medium bad, from 0.1 to 0.5mm difference. Here is pic of first validation pattern https://goo.gl/photos/nW5EhvGcDj1VV7iBA. Left side is mostly missing because it was too high, did not stick and got dragged with nozzle. Lower right is little squished, only some spots in the middle are "ok". Its 15x15 mesh
ngarafol
on 2 Nov 2016
But sometimes I get confused what is up and what is down :) If I want to tune higher positive spot I have to go lower, if I tune low negative spot I have to go higher value, 0 is always reference point, right?
Think of the Mesh Point this way: The Mesh Point number says how much you want the nozzle to go up or down at this location to get good adhesion to bed. A Mesh Point of -.1 says you have a small dip in the glass and you need the nozzle to go lower to track the surface of the glass.
So on the left side... You want positive Mesh Point numbers. And as you get further to the left, most likely you want the numbers to get bigger and bigger (compared to the center).
In theory 15x15 should be OK. But there is much more testing and use at 10x10. You should be perfectly fine with 10x10 even with a bad piece of glass!
Roxy-3D
on 2 Nov 2016
Here is G29 O output after "fresh" G29 P1 O since there were some crazy numbers like millions, maybe reason for headcrash?! http://pastebin.com/u8EvXtvd
EDIT: now that I look at it, seems like my Z axis is slipping. Since all lines are 0.5mm off left side compared to right side. Lol. Will redo G29 and post back.
ngarafol
on 3 Nov 2016
since there were some crazy numbers like millions, maybe reason for headcrash?!
Where were the crazy numbers in the map? It would be very difficult for those kind of numbers to get into the middle of the map without corrupting more of it. Did you change Mesh Sizes or something? Because the position of the various mesh slots will shift back and forth depending upon the Mesh dimensions. That could explain how you could get crazy numbers like that. If you change the Mesh Dimensions, you should not try to use a previously saved Mesh with the newly built firmware!
Roxy-3D
on 3 Nov 2016
They were in the front part of map, approximately where head crashed. -2137434 or something crazy like that.
ngarafol
on 3 Nov 2016
OK! Just as an FYI. The Mesh Slots are stored way off at the end of the EEPROM. But if you use a big number (like Mesh Slot 9 or 10 with a 10x10 Mesh), the last slot can be vulnerable to corruption if you load different versions of firmware. For example, move back from devel_ubl to RCBugFix and then come back again. Or, reconfigure your devel_ubl to a different set of Mesh Dimensions.
Other than that type of thing, the stored Mesh data should be safe from corruption.
Roxy-3D
on 3 Nov 2016
Probably help to add a checksum for the mesh data, as we did for the parameter EEPROM.
thinkyhead
on 4 Nov 2016
I do have a question. when using the probe...which physically touches the bed. to get a measurement. why is the mesh map so messed up looking??
with the probe having a repeatable accuracy of 0.0014 i would assume that the map would not look the way it does.
is there some bad math in the firmware?
WOOKIE111
on 4 Nov 2016
Probably help to add a checksum for the mesh data, as we did for the parameter EEPROM.
Yeah... But I haven't gotten to that. But I did put a full 16 bit CRC on the normal EEPROM data:
https://github.com/MarlinFirmware/Marlin/blob/devel-ubl/Marlin/configuration_store.cpp#L61
with the probe having a repeatable accuracy of 0.0014 i would assume that the map would not look the way it does. is there some bad math in the firmware?
What does your Mesh Map look like?
Roxy-3D
on 4 Nov 2016
@WOOKIE111
"What does your Mesh Map look like?"
boelle
on 9 Nov 2016
Looks similar to a mesh map of 0's
WOOKIE111
on 9 Nov 2016
@WOOKIE111 If your system isn't running right... Let's dig in and get it fixed...
Roxy-3D
on 9 Nov 2016
@Roxy-3D Since i had gotten Incredibly Furstrated to the point of breaking things.
Instead of breaking things. i decided to tidy the wiring and redo some of the wires that benefit from sheilded wiring.
Now all the stepper motors are shielded. The Viki2 is Shielded. All sensors are ( endstops thermosistors) and servo input.
the only thing not shielded is power input, Hotend Power, Bascially anything that is power specific and doesnt carry a signal.
and all of the wiring is getting tidied into expandable sleeving. so everything is gonna look hotter than......well its gonna look good.
before it was a mess of wires and nothing was specifically shielded.
i needed this time to step away from the frustration. also im soon to receive my new 1/4 Piece of Mic6 Aluminum with (hopefully) Less warp. so that means i can also install the heated bed silicone back soon.
So as for anything practical i cannot provide it at the moment due to above. Hence why i didnt provide a picture of the last mangled Mesh i was ranting about.
So right now. from this point. until everything is back together it is all theory.
WOOKIE111
on 9 Nov 2016
Thank You for the update. Cleaning up the wiring is always a good thing!
I'm guessing in a week I'll have a new revision of UBL. If you want to try to bring that up you will have my full attention. But it might not hurt to bring up RCBugFix first just to get the printer checked out. What ever you want to do is fine.
Roxy-3D
on 9 Nov 2016
@Roxy-3D
But it might not hurt to bring up RCBugFix first just to get the printer checked out.
UBL doesnt work well? or has RCBugfix been updated to get rid of the bug where it doesnt compensate ( RC7 Doesnt compensate either)
Confused as to why to use one over the other
WOOKIE111
on 9 Nov 2016
RCBugFix is a more mature (and stable) branch. By definition... devel_ubl is a 'Development' branch where the concepts work, but the thinking (and code) are not fully mature.
Roxy-3D
on 9 Nov 2016
@WOOKIE111 did the problem solve itself with RCBugfix?
boelle
on 12 Nov 2016
@boelle
did the problem solve itself with RCBugfix?
Did what problem solve itself?
WOOKIE111
on 12 Nov 2016
This issue is labeled with Bug potential....
i wonder if there is a bug as such or its more a support issue... if so we should have the Bug label removed
boelle
on 12 Nov 2016
@boelle No the bug is still present as im still not the only one experiencing it.
and there seems to be a similar bug in DevUBL however not as prominent.
Will Speak more once properly done rewiring.
WOOKIE111
on 12 Nov 2016
oki doke.... just trying to figure all the Bug issues
RC8 is coming out soon
boelle
on 12 Nov 2016
@Roxy-3D alrighty. all wired up except for the display which is easy and done in 5 mins.
now i cannot remember which thermosistor table value i used for the heatedbed.
this is the heated bed http://www.ebay.ca/itm/35X35CM-800W-110V-Silicone-Heater-3D-Printer-Heated-Bed-Large-Plate-Heating-Pad-/281658618264?hash=item4194297198
and it describes a thermosistor as
NTC 100K thermistor ( Beta 25/50 3950K)
no idea which that would be.
i forgot wbhat i had used lol
WOOKIE111
on 20 Nov 2016
and it describes a thermosistor as NTC 100K thermistor ( Beta 25/50 3950K)
no idea which that would be. i forgot what i had used lol
I believe you want to declare that as a Type:1 thermistor. I presume you have a SSR (Solid State Relay) to switch the power to the heat pad on and off? It is possible that a Type:6 or Type:7 declaration will give you better results. You won't hurt anything if you just tell your bed to go to 60 degrees C and then measure it to confirm where you are. Please let me know which thermistor type gives you the best accuracy. I will be wiring up a silicon heat bed with that same NTC 100K (Beta 25/50 3950K) thermistor in the next week!
Roxy-3D
on 20 Nov 2016
To my experience with Keenovo
* 10 : 100k RS thermistor 198-961 (4.7k pullup)
* 11 : 100k beta 3950 1% thermistor (4.7k pullup)
* 12 : 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed)
11 is not far off.
Blue-Marlin
on 20 Nov 2016
@Roxy-3D
I presume you have a SSR (Solid State Relay) to switch the power to the heat pad on and off?
Yes i do :D Omron G3NA-220B-DC5-24 Solid State Relay.
when you say measure it. do you mean temperature? cause i have no way of doing so :(
WOOKIE111
on 20 Nov 2016
when you say measure it. do you mean temperature? cause i have no way of doing so :(
OK. I have one of those IR Thermometer guns. They work pretty good for this kind of thing:
I believe Blue-Marlin is correct that Type:11 is the one that makes sense. I remember looking at the numbers before and that is what I concluded. But when I just pulled up the tables to help you, I saw Type:1's numbers and thought that was the one I decided I wanted to try first.
Please start with Type:11 and see if that works well for you.
Roxy-3D
on 20 Nov 2016
@Roxy-3D
Welp, before making any changes to the firmware. everytime i open the firmware i run a verify to see if it compiles.
well no changes, just sitting there on the hard drive. i get this
I think only the last few lines are what you actually need. but im including the whole thing just in case
also my old version of rcbugfix compiles fine. and a brand new UBL also does.
Arduino: 1.6.12 (Windows 7), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"
In file included from sketch\Marlin.h:44:0,
from sketch\Bed_Leveling.cpp:23:
sketch\Configuration.h:779:0: warning: "DEFAULT_ZJERK" redefined
#define DEFAULT_ZJERK 0.4 // (mm/sec)
^
sketch\Configuration.h:771:0: note: this is the location of the previous definition
#define DEFAULT_ZJERK 1.0 // (mm/sec)
Thanks for the heads up! I'll get that fixed ASAP. (I deleted all but the first error... Just to keep the thread readable!)
Roxy-3D
on 21 Nov 2016
@Roxy-3D idk why but this sometimes just happens where a whole config just goes bad. no idea why
WOOKIE111
on 21 Nov 2016
I just pulled down the whole branch and pulled it into Arduino 1.6.9 It compiled clean:
Roxy-3D
on 21 Nov 2016
@Roxy-3D Yeah...thats what i said. a fresh UBL compiled clean. an old rcbugfix compiled clean.
just the UBL that was configured didnt. and this was before i cahnged the heatbed thermosistor value too. so literally nothing changed it was sitting dormant.
for shits and giggles.
I opened the Trouble UBL and a Fresh UBL and copy and pasted from BAD to Fresh not the files but literally highlighting everything. of these files Config.h Pins azteegx3.h(and all linked pins files)
and it compiled Clean.
I dont get it. its literally the same setting it was JUST complaining about.
sometimes the arduino compiler is like a child.... -.-
WOOKIE111
on 21 Nov 2016
please attach your Configuration.h. I'll see if it compiles clean on my machine (maybe in the morning... Maybe sooner.) I bet we have a missing ; or something going on. I'm watching a movie with friends... So you are #2 on the priority list :)
Roxy-3D
on 21 Nov 2016
@Roxy-3D GOOD NEWS! the thermosistor in the silicone heat pad....i have been provided a table!
http://www.keenovo.com/NTC-Thermistor-R-T-Table.pdf
now we do not have to guess! :D
WOOKIE111
on 21 Nov 2016
Do we need to make a new table entry for NTC 100K thermistor ( Beta 25/50 3950K) type silicon heater pads? (and it is more than your vendor that uses that thermistor!!!) Or is it close enough to a Type:11 that we just use that flavor?
(I can't do the analysis right now.... I'm just hoping you know the answer.)
Roxy-3D
on 21 Nov 2016
@Roxy-3D I do not know. i dont know how to interpret said data. nor how to figure out if 11 is useable at this moment. nor how to input the data
i come here for help. i provide all the information i can. i just update when i can.
im not sure if youre annoyed or not. i really dont.
WOOKIE111
on 21 Nov 2016
I do not know. i dont know how to interpret said data. nor how to figure out if 11 is useable at this moment. nor how to input the data
I'll look at it in the morning. That data table is exactly what I need to dial my (and your) silicon heat pad. What ever I find... I'll post a "Reader's Digest" version of it tomorrow.
...
i'm not sure if you're annoyed or not. i really don't.
My claws come out way too easy. But you are no where near that point. Listen... I'm very appreciative that you were willing to get a Mesh setup without using the Z-Probe to do it. Soon (in 4 or 6 weeks) I want to do the same thing except without an LCD Panel. At at that point, the UBL system will be able to help anybody even if they don't have an LCD Panel and/or a Z-Probe.
Roxy-3D
on 21 Nov 2016
@Roxy-3D
if it helps. a friend found this
https://github.com/MarlinFirmware/Marlin/blob/RC/buildroot/share/scripts/createTemperatureLookupMarlin.py
and input the R25 and the one at 150 and 250
and out spat this
https://gist.github.com/Apsu/9c6baf10d9eac30b81574181f922e86f#file-table-c-L35
is this more helpful? i dont know. all of this is way way way above my head.
I'm very appreciative that you were willing to get a Mesh setup without using the Z-Probe to do it
haha yeah its sitting there neglected just as a glorified endstop XD
Different note. this new MIC6 aluminum is Sexy AF much different finish and heft to it. i cant wait to heat it up hehehe
WOOKIE111
on 21 Nov 2016
if it helps. a friend found this
https://github.com/MarlinFirmware/Marlin/blob/RC/buildroot/share/scripts/createTemperatureLookupMarlin.py
and input the R25 and the one at 150 and 250 and out spat this
https://gist.github.com/Apsu/9c6baf10d9eac30b81574181f922e86f#file-table-c-L35
is this more helpful? i dont know. all of this is way way way above my head.
Yes! That is very helpful. It looks like Type:11 would work. The curve follows what is in that table, but the problem is it is offset. It looks like saying we have a Type:11 would always leave the bed a little bit cooler than what we want at higher temperatures. At low temperatures it is not off by much.)
I re-ran the script with: --num-temps=65 I'm going to add this as a new Thermistor Type for NTC 100K thermistor ( Beta 25/50 3950K) Silicon Heater Beds with 4.7K pull up resistor
The UBL branch now has a type:75 Thermistor for Generic Silicon Heat Pads with a NTC-100K sensor. If you pull down the current UBL code, and set your #define TEMP_SENSOR_BED 75 I think it is going work and be accurate for you.
// Thermistor lookup table for Marlin
// ./createTemperatureLookupMarlin.py --rp=4700 --t1=25.0:100000.0 --t2=150.0:1770.0 --t3=250.0:230.0 --num-temps=65
// Steinhart-Hart Coefficients: a=0.000793472151148048, b=0.000200763250286666, c=1.63283411817931e-07
// Theoretical limits of termistor: -49.79 to 635.79 degC
const short temptable[][2] PROGMEM = {
{ (short) ( 11.64 * OVERSAMPLENR ), 350 }, // v=0.057 r=54.019 res=6.690 degC/count
{ (short) ( 12.53 * OVERSAMPLENR ), 344 }, // v=0.061 r=58.212 res=6.131 degC/count
...
{ (short) (1001.78 * OVERSAMPLENR ), 8 }, // v=4.892 r=211926.812 res=1.018 degC/count
{ (short) (1007.13 * OVERSAMPLENR ), 2 }, // v=4.918 r=280652.451 res=1.302 degC/count
{ (short) (1011.32 * OVERSAMPLENR ), -4 } // v=4.938 r=374966.354 res=1.688 degC/count
};
@Roxy-3D
Receiving this error when the plate is cold ( 1/4" 420mmx420mm MIC6 aluminum
>>> M303 E-1 S60 C8
SENDING:M303 E-1 S60 C8
PID Autotune start
PID Autotune failed! timeout
TEST
the fail message comes after about....5 minutes
Also after shutting everything off.. and then back on again i decided to try heating it without a PID ( yes slightly silly) same symptoms.
Setting bed temperature to 60.000000 degrees Celsius.
Error:Heating failed, system stopped! Heater_ID: bed
[ERROR] Error:Heating failed, system stopped! Heater_ID: bed
Error:Printer halted. kill() called!
[ERROR] Error:Printer halted. kill() called!
again. after about 5 minutes.
edit:
Noticed that the Negative on the heat bed was going to the PSU ground and not PSU Neutral
Derp.
WOOKIE111
on 21 Nov 2016
Marin sees the bed heating much slower than usual.
Is the bed getting warm?
Does the measured temperature rise?
If so, you can increase the time constants:
in temperature.cpp
} // every 2 seconds
// Over 2 minutes?
if (((ms - t1) + (ms - t2)) > (10L * 60L * 1000L * 2L)) { // !!!
SERIAL_PROTOCOLLNPGM(MSG_PID_TIMEOUT);
return;
}
if (cycles > ncycles) {
in Configuration_adv.h
/**
* Thermal Protection parameters for the bed are just as above for hotends.
*/
#if ENABLED(THERMAL_PROTECTION_BED)
#define THERMAL_PROTECTION_BED_PERIOD 20 // Seconds !!!
#define THERMAL_PROTECTION_BED_HYSTERESIS 2 // Degrees Celsius
/**
* Whenever an M140 or M190 increases the target temperature the firmware will wait for the
* WATCH_BED_TEMP_PERIOD to expire, and if the temperature hasn't increased by WATCH_BED_TEMP_INCREASE
* degrees, the machine is halted, requiring a hard reset. This test restarts with any M140/M190,
* but only if the current temperature is far enough below the target for a reliable test.
*
* If you get too many "Heating failed" errors, increase WATCH_BED_TEMP_PERIOD and/or decrease
* WATCH_BED_TEMP_INCREASE. (WATCH_BED_TEMP_INCREASE should not be below 2.)
*/
#define WATCH_BED_TEMP_PERIOD 60 // Seconds !!!
#define WATCH_BED_TEMP_INCREASE 2 // Degrees Celsius
#endif
If not - repair the heater.
Blue-Marlin
on 22 Nov 2016
//#define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders
//#define THERMAL_PROTECTION_BED // Enable thermal protection for the heated bed
You must have these turned on. If you turn them off, does everything work?
Roxy-3D
on 22 Nov 2016
the problem was
the ssr - connection i had it connected to ground on the PSU
now on neutral on the PSU like it should
Works fine
WOOKIE111
on 22 Nov 2016
@Roxy-3D
Hopefully your description is good enough to make it distinguishable from the already 3 other 3950K thermistors. Something like "Keenovo silicon heater with 3950K 1% thermistor - derived from the table values"
This 3950K 1% thermistors are a cheap, few cent, Chinese mass product. I don't expect them to be out there in a wide variete - i expect them to be all the same.
So differences in our temperature lookup tables are likely caused by different methods to build them.
One could be based on measured values, the other on table values, one could be based on 3 points at 0,50,100 °C and the other one on points at 25, 150, 250 °C. All will look different, but describe the same hardware - under different conditions.
An other interesting aspect is - How did the distributors produce their tables.
Other remarks on temperature lookup tables:
When we look up a sensor value to find a temperature, the tables are at fist sequentially searched, then the value is interpolated between the points above and below. A short table is searched much faster.
Does it make sense to provide a table for a bed heater thermistor up to 350°C when the used glue will give up at 150°C?
PS: It would make me wonder if the 4.7K resistors on RAMPS &co. would have a better tolerance than 5%
Blue-Marlin
on 22 Nov 2016
Good points!
I guess the reason for the 'Generic Silicon Heat Pad' name is this same NTC-100k Thermistor has started showing up everywhere. Maybe we need a better name. But right now... looking at different Silicon Heat Pads... many (if not most) of them are saying they use the NTC-100K part. And it is very possible this NTC-100K part gets used with out a heat pad too. I just wanted it in the UBL thermistor tables because both Wookie and I are going to be using it now.
I don't know how the vendor generated that table. I'm just assuming they know more about this stuff than me and the table is correct. But you are certainly right about more values not helping. I guess I should strategically delete at least half of those values. It might make sense to have a few values at each end of the table. And at least for me, a cluster of values around the 205 C marks and the 225 C marks.
I will take your advice and cut that table down to size!
Roxy-3D
on 22 Nov 2016
Some more comments.
NTC-100k describes not a special type of thermistor. It describes a class of them. Its just a abbreviation for
Thermistor with __N__ egative __T__ emperature __C__ oefficient with a resistance of __100K__ ohm at 25°C
These IR-thermometer guns are not good for shiny/glossy metal surfaces. They are made for surfaces with much less 'reflection'.
Blue-Marlin
on 22 Nov 2016
@WOOKIE111 @Roxy-3D
I guess this one is not "solved" yet?
boelle
on 23 Nov 2016
@boelle No the initial Issue with RCbugfix to my knowledge isnt fixed. i however changed gears and went to UBL. please stop asking if the problem is solved with me. i do not know as i dont use RCbugfix at the moment
@Roxy-3D
Since my heated bed runs on an SSR and is 110v 800w ..... Should i Be using Bang Bang and not PID? If so can you guide me into how to turn bang bang on? its different than what it used to be it seems.
WOOKIE111
on 24 Nov 2016
Since my heated bed runs on an SSR and is 110v 800w ..... Should i Be using Bang Bang and not PID? If so can you guide me into how to turn bang bang on? its different than what it used to be it se
I just got a silicone heated bed. But mine is 12 volts. But still... I believe I have to use a SSR to switch the power to it. I'm in a holding pattern because I fried the the 300 watt ATX power supply I had sitting around. I should be ready to continue in a couple days.
All of that aside... What I'm going to do is hitch up the SSR's control + side to 12 volts. And I'm going to connect the - side of the switch to the MOS-FET on my RAMPS board. I believe that is going to switch the power for me. I think all of that is the same between what you are going to do and I need to do. The big difference is I need a 12 v power supply with 25 amps of current. You can just hitch up the heat pad to the wall socket and have it switched by the output side of the SSR.
OK... Assuming you have all that wired up right... It is my belief that either mode will work for you. But I'm pretty sure the PID is going to have less over shoot and do a better job. That is what I plan on doing. I plan on trying PID first. But I'm not a power expert. It is very possible some of the people that wrote the PID (or Bang Bang) code are going to jump in and correct these statements!
Roxy-3D
on 24 Nov 2016
Any easy way to set the z offset for the probe? i think i may have incorrectly guessed mine.
WOOKIE111
on 2 Dec 2016
M851 Z-X (for negative X offset value -> X here meaning actual probe Z offset value). Negative meaning move down (toward bed), positive meaning lift from bed. In case you want positive offset, remove "-" between Z and X inside command :) And after M851 do M500 to save to eeprom, and verify setting with M501.
ngarafol
on 2 Dec 2016
Yes! M851 Z -?.??? is very helpful. But I'm starting to deliberately set my Z home position .10mm off the glass and just use the Z BabyStepping to dial in the nozzle height at the start of a print. For me... That works very well. I print on glass. But especially for people that print on those expensive heat pads or use tape on the print bed, I think that would help reduce the wear and tear on the surface.
Roxy-3D
on 3 Dec 2016
What Would cause this really weird problem. on the first layer.
0,0 has regular of not a little too much squish....just a little too much
0,max you're able to see a gap a small one to the glass.
max,max you're able to see a gap a small one to the glass.
max,0 you're able to see a gap a small one to the glass.
However the corner opposite origin looks to be the same amount away as the other corners.
yet the bed is level when checked with a feeler gauge. or even paper method. on all 4 corners.
WOOKIE111
on 3 Dec 2016
It may be you are over thinking stuff. That is the whole purpose of the Mesh. What ever weird stuff is going on with your printer, the Mesh tells the nozzle how much to correct for that location. Take a look at my Mesh with a really bad piece of glass. It has a bulge in the middle. It has warp (or twist) going left to right. And it has some smaller ups and downs. I get good adhesion across the entire bed every time. The nozzle just floats above the bed anywhere it goes.
G29 N M
SENDING:G29 N M
Bed Topography Report:
(0,9) (10,9)
(0,180) (200,180)
-0.21000 -0.04500 0.00000 0.00000 0.08500 0.08500 0.15000 0.14000 0.15500 0.00000 0.00000
-0.24500 -0.10500 -0.13500 0.00000 0.04500 0.06000 0.16500 0.12500 0.13000 0.11000 0.00000
-0.33500 -0.18000 -0.06500 -0.08000 0.00000 0.00000 0.19500 0.20000 0.20500 0.08500 0.05000
-0.31000 -0.16500 -0.17000 0.01500 0.00000 -0.05000 0.04000 0.15000 0.15000 0.09000 0.09500
-0.43000 -0.24500 -0.13500 -0.04000 -0.10500 -0.16000 -0.07500 0.15000 0.15000 0.03500 0.00000
-0.41000 -0.29500 -0.22500 -0.08500 -0.27500 -0.03000 0.03500 0.06500 0.13000 0.00000 0.00000
-0.53500 -0.34500 -0.22500 -0.34500 -0.17500 0.00000 -0.23500 -0.07000 -0.05000 0.00000 0.00000
-0.67500 -0.43500 -0.32500 -0.35000 -0.17500 -0.19500 -0.05000 0.05000 0.09500 0.00000 0.00000
-0.85000 -0.57500 -0.47000 -0.34500 -0.18000 -0.21000 -0.19500 -0.13500 -0.17500 0.02500 0.06500
[-0.83500] -0.80500 -0.56500 -0.47500 -0.42500 -0.39500 -0.39000 -0.17000 -0.07500 -0.10500 0.00000
(0,0)
(0,0) (10,0)
That's the thing though. Ever since I added the new aluminium plate I've been using a fully zero mesh
And I wasn't able to set my zoffset for the probe correctly before ..so I had it at -2.02
But now that I figured in the firmware I need to set the firmware ends top to off to allow it to go negative...it's changed to -2.2
And that change from the offset of -2.02 to -2.2 made me notice the bed squish more.
Is there a way to print a mesh validation that's easier to see so I can adjust it. Because now that points aren't scraping the bed. I can't make heads or tails. I know it's sticking and adhering and close. But obviously some are a lot closer than others
WOOKIE111
on 3 Dec 2016
You are doing a M502 and M500 after you change numbers and upload the firmware, right?
You can adjust all the numbers on the G26. It is actually easier to see what is going on if you back off the amount of filament being put down. Then it is easier to see things like where the nozzle is too close or too far from the bed. Try backing off the amount of filament it is putting down on the plate. You do that by lying and claiming your filament size is larger than what it really is. If you have 1.75mm filament, go ahead and say you have 2.25mm filament, and less will get squeezed out the nozzle. I don't know if 2.25 would be too much or too little. But a couple iterations and you'll find a number that does what I'm suggesting.
So it would be something like G29 F2.25 in the made up example.
Roxy-3D
on 3 Dec 2016
@Roxy-3D i get it. so purposely under extruding( i assume thats what a large diameter will do) to force a flaw if not close enough making said flaws more visible.
you tried this before?
WOOKIE111
on 3 Dec 2016
Yes... that is better wording... If you under extrude it is easier to see exactly what is happening. But it is also very possible parts of your Mesh Validation Pattern do not get good adhesion. When you under extrude, the nozzle height above the bed becomes even more important. And one beneficial side effect is you can look at the line being drawn and see if the top of it is round (because the nozzle is a little bit too high above the bed). Of it might be squished dramatically flat and wide (because the nozzle is too close to the bed).
And claiming to have a larger filament diameter than you really do will cause an under extrusion.
Roxy-3D
on 3 Dec 2016
@Roxy-3D went and peeked at RC8. lol they dont have an up to date therm table.
WOOKIE111
on 7 Dec 2016
What needs to change for RC-8 to be correct? I'm going to start crossing UBL over to the RC-8 code base soon. So when that happens, you will have RC-8 with UBL as the bed leveling system. (I'm guessing it will be ready in 2 weeks. )
The motivation for doing that is I'm seeing some lost serial characters and there have been a ton of fixes done to RC-7's serial code. I tried moving those fixes over to UBL, but it got pretty hairy and I decided it would be the same amount of work to move UBL over to RC-8. And if I go that direction, I pick up a bunch of LCD Panel fixes too that have been causing problems.
Roxy-3D
on 7 Dec 2016
@Roxy-3D
This one specifically i noticed not there.
// 75 is for Generic Silicon Heat Pads with NTC 100K thermistor ( Beta 25/50 3950K) and 4.7k pull up.
and that sounds pretty rad. so there will be UBL as well as all the other bed level methods to choose from? WOW.
Yeah, merging INTO RC8 instead of from does sound like the lesser of two evils ( or headaches! :P)
WOOKIE111
on 7 Dec 2016
No! It is not that simple! I added a type 75 in UBL because I thought it would be useful. But an NTC-100K didn't mean what I thought it did. That means 'Negatively Temperature Correlated 100K' Thermistor. And there already was one pretty similar to that. I don't have enough data to know if we should even keep that in the UBL branch, let alone merge it back into the 'Release Candidate'.
And... Moving the UBL code back to the RC-8 code base doesn't imply anything other than UBL will be based off of RC-8 (and very similar to RC-8). RC-8 will still continue on the path it is on to resolve bugs and head towards a 'Stable Release'. It just means UBL will have the benefit of all the bug fixes that have been found and fixed and put into the RC. (The Serial Buffer Over Runs will be gone as well as a bunch of LCD Panel bugs.)
The whole purpose of UBL was to make it so people didn't have to choose which bed leveling scheme they wanted to use. The purpose was to make it so all of the different features were available for all machine types at all times. We aren't there yet. But we will be in a couple of months.
And from a different perspective... UBL is a 'Development Branch'. It is OK for it to be a little bit in front of the main branch. And it is OK for features (and concepts) that have been proven useful to flow backwards into the main branch. You have seen that recently with the 'Fade Height' and the mesh being saved in EEPROM. Both of those were in UBL first. But now they are in RC-8.
I never quite get to it... But it won't be hard to put the Grid Leveling into UBL. If somebody says they need it, it will show up sooner. But the truth is the high resolution Mesh Bed Leveling is so good you don't even need the 3-Point leveling of the mesh.
Roxy-3D
on 7 Dec 2016
the mesh being saved in EEPROM. … But now they are in RC-8.
Not yet.
thinkyhead
on 7 Dec 2016
@Roxy-3D @thinkyhead One thing that is driving me a little batty. and if fixed means we could probably probe slower. is the glass tapping after probing with the bltouch
WOOKIE111
on 7 Dec 2016
Yeah... I'm seeing that also. And it happens if you don't back away fast enough from the glass. The problem is, when that happens, it puts the probe into an 'Error State'.
Yes... This is a known issue! And in fact, I've sent the BL-Touch information about what we are seeing.
The good news is soon there will be a new mode in the BL-Touch probes. The new mode will dumb down the BL-Touch and it should not do that. The problem is, that won't help all the the BL-Touch probes that are already out there. So we need to resolve this for all the people already using an older one.
I think the first thing to try is have your probe back off further after it triggers... And have it back off faster... That might resolve things for you. I really don't like this as a 'solution', but at least with UBL it is not too painful. Any error (or loss of precision) caused by moving faster can be edited out of the mesh during the Mesh Validation Pattern editing phase. And any loss of precision during homing can be adjusted out using the Quick Access to Z-BabyStepping while the skirt of a print is being done.
Roxy-3D
on 7 Dec 2016
@Roxy-3D but how does one get it to back off faster after probe and only approach slowly? as far as i could find/remember there is only one setting for probing speed.
WOOKIE111
on 7 Dec 2016
Yeah... That is the problem!!! You have to probe FASTER. Which I don't want to do!!!!
Tell you what... If you change one line in run_z_probe() it might do what we need. I can't test it right now... But at about 2147 lines into Marlin_main.cpp you will see this code. Try changing it to this:
// move up the retract distance
zPosition += home_bump_mm(Z_AXIS);
// line_to_z(zPosition);
planner.buffer_line(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS], feedrate / 8, active_extruder);
stepper.synchronize();
endstops.hit_on_purpose(); // clear endstop hit flags
This replaces the call to line_to_z(zPosition) with a call to the planner's buffer_line routine. That is the same thing line_to_z() does, except we are going to do the call with a rate that is 7.5 times faster. So how ever fast it backs off now... It should back off much faster with this one line replaced.
I don't know that it will fix things... But it has a decent chance of 'helping' with the problem. And that /8 number isn't special. It is just a guess. We don't want to back off at full speed. But it maybe that /4 is more appropriate in order to back off fast. I don't know! If /8 doesn't quite do it... try giving the /4 a chance and see what happens!
And as always.... Please have your finger on the reset switch when you test this!!!!!
Roxy-3D
on 7 Dec 2016
Well...how does the other F/W do it?
WOOKIE111
on 10 Dec 2016
I do not know the answer to that question. But the BL-Touch probe currently puts out a 5ms pulse when it triggers. At very slow probe rates it is possible to miss the pulse because endstop status is checked in the interrupt code that feeds step pulses to the motors. (At slower probe rates, the steps come too slow and the 5 ms. pulse can come and go without being seen.)
There is work that may be available very soon to put the end stops on interrupt pins. When that is ready, we should be able to trigger using the 5ms pulse and not ever miss it. And independent of that, Antclabs (the makers of BL-Touch) are adding a new mode to the probe where the triggered state will not disappear after 5 ms. So... One way or the other.... Soon... We we will get this problem put to bed.
Roxy-3D
on 11 Dec 2016
i still cant seem to quite get this going right.
one side seems to be high all the time and the others always sloping away.
I have also recently tried seperating the circles of the mesh and measuring them for thickness and marking the measurement on the glass where they came from.
as the height is a supposed 0.2 i had corrected the mesh point so that using the data collected it would then be 0.2
its the closest i have been to uniformity. but one corner is still alot closer than the other :(
im starting to think its something to do with the bltouch and how the bltouch senses with weird pulses having to be captures. maybe i would have better luck and repeatability with a standard servo and switch type probe :(
also. has anything changed in the UBL branch?
and for all of you guys wanting LAAARGE print surfaces. yeah dont haha. because the accuracy to be maintained across the large surface is rather high haha.
WOOKIE111
on 28 Jan 2017
and for all of you guys wanting LAAARGE print surfaces. yeah dont haha. because the accuracy to be maintained across the large surface is rather high haha.
Having a large (bad) print surface was the main reason for making MBL in the first place :) https://github.com/MarlinFirmware/Marlin/pull/1619
epatel
on 29 Jan 2017
im starting to think its something to do with the bltouch and how the bltouch senses with weird pulses having to be captures. maybe i would have better luck and repeatability with a standard servo and switch type probe :(
Agreed...
also. has anything changed in the UBL branch?
No. But I'm going to be merging it with RC-8's RCBugFix very soon. That should fix a lot of random issues that got fixed between July 4th and now.
and for all of you guys wanting LAAARGE print surfaces. yeah dont haha. because the accuracy to be maintained across the large surface is rather high haha.
@WOOKIE111 In theory, you don't even need to probe. Can you use G26 to create a Mesh Validation Pattern and just edit your mesh to perfection?
Roxy-3D
on 29 Jan 2017
@WOOKIE111 In theory, you don't even need to probe. Can you use G26 to create a Mesh Validation Pattern and just edit your mesh to perfection?
thats what ive been doing haha. i started by homing. then by manual feelergauge leveling the corners.
then doing a manual mesh.
So involved.
WOOKIE111
on 29 Jan 2017
Related issues
paulpenney
·
549Comments
bruce356
·
169Comments
kAdonis
·
169Comments
viperchannel
·
415Comments
revilor
·
370Comments