Results 131 to 140 of 757
-
07-31-2014, 11:24 AM #131
- Join Date
- Jun 2014
- Posts
- 37
-
07-31-2014, 12:58 PM #132
SCORE!!! Thanks BrainScan!!!
-
08-02-2014, 08:29 AM #133
- Join Date
- Jul 2014
- Location
- Van Nuys, CA
- Posts
- 22
Ha, I was just about to point that out. Brainscan beat me to my own post
-
08-04-2014, 02:55 PM #134
If I go and find case 500 so I can put this new case 499 in front of it I'm not sure of the syntax.
I have:
/////////////////////////////////Code Start Paste///////////////////////////////////////////
#if defined(ENABLE_AUTO_BED_LEVELING) && defined(SERVO_ENDSTOPS)
case 401:
{
engage_z_probe(); // Engage Z Servo endstop if available
}
break;
case 402:
{
retract_z_probe(); // Retract Z Servo endstop if enabled
}
break;
#endif
case 500: // M500 Store settings in EEPROM
{
Config_StoreSettings();
}
break;
/////////////////////////////////Code End Paste///////////////////////////////////////////
Does is go like this?
/////////////////////////////////Code Start Paste///////////////////////////////////////////
#if defined(ENABLE_AUTO_BED_LEVELING) && defined(SERVO_ENDSTOPS)
case 401:
{
engage_z_probe(); // Engage Z Servo endstop if available
}
break;
case 402:
{
retract_z_probe(); // Retract Z Servo endstop if enabled
}
break;
case 499: // Invalidate the M500 Store settings in EEPROM command
{
Invalidate_EEPROM_Settings(); // Roxy added function to guarintee we are using
// the default values defined in the firmware!
}
break;
#endif
case 500: // M500 Store settings in EEPROM
{
Config_StoreSettings();
}
break;
////////////////////////////Code End Paste///////////////////////////////////////////////////
My reason for asking is it looks like each case gets a 'break;' at the end and your snippet didn't have that.Bambu P1S/AMS
NVision4D http://nvision4d.com
-
08-04-2014, 04:32 PM #135
Thank You for pointing that out. That was sloppy cutting & pasting.
Yes, each 'case ??:' gets a break normally. That keeps the code from falling through into the next 'case'. Usually (but not always) you want a 'break' after the code for a given case. And certainly for this invalidate code, you want to break after it finishes.
I put the 'break' in the correct place on that post.Last edited by Roxy; 08-04-2014 at 04:36 PM.
-
08-04-2014, 05:20 PM #136
Thanks Roxy for confirming that. I assumed that it would be good to have the break; there. I know just enough code (but learning every day) to Frankenstein it together. I haven't studied programming and just don't understand how to write the logic.
I have autoleveling working well and have gone back over this long thread again. You and brainscan got into a very, very long tweak but for the most part, the very front end of the thread is all that matters for most of us. There is a bit on page 8 that is useful too.
The only problem I have is that once I get my RAMPS flashed from Arduino and I have the perfect offset for my head's Z coordinate (.2mm gap when I issue a G1 Z0), every different slicer treats it differently. I've started an Excel sheet just to track it. I have to adjust the Z offset manually in each and every slicer. In a way it negates the time savings of having autolevel as I now spend an hour with each slicer tweaking the Z offset, testing a print, quitting it, adjusting again, printing, cancelling....you see where I'm going...until I have it. I was wondering why they don't read the configuration.h file correctly?
I wish I could settle on one slicer and be done with it but they all just have behaviors that are beneficial from job to job. I recently bought Simplyify3D and like it but I still get a cleaner print out of KissSlicer, the cleanest printing slicer I've every configured. So, I had Simplify3D all configured and had my Z offset manually tweaked and perfect and I go to print. Well, the print just wasn't clean. So, I stop and go back to Kisslicer. I find that the Z offset is not not correct so I spend an hour to get it correct and get a good print.
Sorry to meander, but my point is, until I can figure out a way to have ALL slicers trust the Z offset from the configuration.h file and know that all slicers will respect it, I'm not garnering any time savings with autolevel. I hope I can solve this as autolevel seems like it can "be the bomb." But for now, it's just as tedious as hand leveling the bed with corner bolts.Bambu P1S/AMS
NVision4D http://nvision4d.com
-
08-04-2014, 05:42 PM #137
Sorry for needing the hand holding.
When I place the case 499 code in Marlin_main.cpp I get the following compile error:
Marlin_main.cpp: In function 'void process_commands()':
Marlin_main.cpp:3065: error: 'Invalidate_EEPROM_Settings' was not declared in this scope
When I place the void Invalidate_EEPROM_Settings() code in ConfigurationStore.cpp (I don't have Configuration_Store.cpp) I get the following error after the sample code below:
#include "Marlin.h"
#include "planner.h"
#include "temperature.h"
#include "ultralcd.h"
#include "ConfigurationStore.h"
void Invalidate_EEPROM_Settings()
{
char bogus_ver[4] = "xyz";
char confirmation[4] = "???";
int i=EEPROM_OFFSET;
EEPROM_WRITE_VAR(i,bogus_ver);
i=EEPROM_OFFSET;
EEPROM_READ_VAR(i,confirmation); //read stored version
if (strncmp(bogus_ver, confirmation,3) == 0)
SERIAL_PROTOCOLLNPGM("EEPROM Settings invalidated.");
else {
SERIAL_PROTOCOLLNPGM("EEPROM Settings not invalidated.");
SERIAL_PROTOCOLPGM("Read Version: [");
SERIAL_PROTOCOL(confirmation);
SERIAL_PROTOCOLLNPGM("]\n");
}
}
ERROR:
ConfigurationStore.cpp: In function 'void Invalidate_EEPROM_Settings()':
ConfigurationStore.cpp:11: error: 'EEPROM_OFFSET' was not declared in this scope
ConfigurationStore.cpp:13: error: 'EEPROM_WRITE_VAR' was not declared in this scope
ConfigurationStore.cpp:16: error: 'EEPROM_READ_VAR' was not declared in this scope
Bambu P1S/AMS
NVision4D http://nvision4d.com
-
08-04-2014, 05:44 PM #138
- Join Date
- Jul 2014
- Location
- Van Nuys, CA
- Posts
- 22
Ok, this doesn't sound right at all. Something else is going on with your system. How much do you need to tweak the Z offset? The slicer should just be setting the initial Z to whatever your first layer height is. So for instance, if your first layer height in slic3r is set to .4, then in the generated gcode, you should see it go to that height (G1 Z0.4) as the first G1 for printing. If you see that, then the slicer is doing what it is supposed to do. After flashing your ramps board, did you do the EEPROM commands to make sure you were using the firmware version of the settings, then save them to EEPROM again? If you don't do that, then the firmware won't automatically adjust your Z offset when issued G1 commands. I'm guessing you did the EEPROM thing, since you say you can issue a G1 Z0.
Also, usually we try to adjust for a .1mm gap (one paper sheet thickness)
BruceLast edited by brucehvn; 08-04-2014 at 05:48 PM.
-
08-04-2014, 06:50 PM #139
Hi Bruce. Maybe I'm not doing the EEPROM commands. I think that's what I'm trying to set up with Roxy's directions on page 8 and my questions above. I suspect that that might be the culprit. Until I hear back from Roxy I'll go ahead and find those EEPROM commands and issue them.
For my normal workflow, what I do is I open my configuration.h file and then go to my printer and to a G29 and then a G28. That 'homes' everything and does an Autolevel. When the autolevel stops, my hotend is sitting there with the probe 'up' waiting to start a print. It should be at the perfect offset distance. I issue a G1 Z0 and the hot end will move down to the bed. If all is good with my configuration.h file, then the head will stop and I'll have that "sheet of paper gap." If it's a hair tight, I go to my configuration.h file and add 1/10th mm to it, do G29 and G28 Z0 again. Most of the time that's it. I close Arduino and I should be good to go. That's I do though. I haven't been issuing and EEPROM commands after the G1 Z0.
So continuing my standard workflow that I just mentioned, I now go to print with say Slic3r, and it's about 2mm high off of the bed. So, I switch to any other slicer, and they too will be off but not the same amount. So, I'm constantly now refining each slicer and it's just gotten way too tedious considering I have autoleveling going.
I think what you are suggesting is that I'm missing a step. Are you saying that I need to issue some EEPROM commands after I flash the RAMPS? I need to find those, I think they are in the 500's if I remember earlier comments in this thread. Let me try that and report back.Bambu P1S/AMS
NVision4D http://nvision4d.com
-
08-04-2014, 07:30 PM #140
- Join Date
- Jul 2014
- Location
- Van Nuys, CA
- Posts
- 22
The EEPROM command should only be necessary if you modify the z offset in the configuration.h file. It shouldn't be necessary every time you home the printer and try to print. The new z offset needs to get stored in EEPROM otherwise it won't be used the next time you start your host software which will read the old value from EEPROM.
So, after you've made modifications to the offset in Configuration.h and reflashed the Marlin firmware, go into your host program and issue a M502 command which resets all setting to what you actually have in Configuration.h. Then issue a M500 command to store the current values back to EEPROM. You don't need to do that again unless you modify the z offset in the Configuration.h (or any other parameters from Configuration.h that are stored in EEPROM).
You should also make sure that your bed or your z axis is not unstable. After you've tweaked your z offset, and you can get the G1 Z0 to be the paper sheet height, then move all your axes around for a bit (without homing), then move everything back to where it was when it homed, issue the G1 Z0 command again and check it. See if you have the same clearance. If that's all good, then maybe do Roxy's probe reliability test to see if your probe is giving you close to the same readings each time.
BruceLast edited by brucehvn; 08-04-2014 at 07:34 PM.
Ender 3v2 poor printing quality
10-28-2024, 09:08 AM in Tips, Tricks and Tech Help