You are not logged in. Please login or register.
SoliForum - 3D Printing Community → Hacks & Mods → Bed Level Sensor experiment
This holiday weekend has given me the time to start hacking up an experimental bed level sensor using a force sensitive resistor:
http://home.comcast.net/~tomhorsley/har … level.html
Perhaps tomorrow I'll get it installed and see if it actually works :-).
As Spock would say.. Fascinating!
looks good.
Only thing I can think of immeadiately is that you need to account for the fact the stock x-carriage is designed to have play, in the order of 1/8" in old money... to prevent binding and assist with its x-movements. Combined with the weight of the extruder, it does tend to naturally wobble even with a rock solid bed by design...
just a thought to consider...
look forward to the results 
I've updated my web page with the proof of concept working fairly well (though nothing like the way I initially thought about it). All I really needed to do was wedge the resistor between the bottom of the extruder cooling fan and the top of the carriage. The carriage flexes enough when the nozzle makes contact with a shim I placed on the bed to be quite obvious on the multi-meter:
Don't know if the change would be as obvious micro-stepping the Z axis as it was moving manually 1/10 mm in RH.
Somebody named "Rincewind" posted this link today in the irc channel.
http://youtu.be/5d_aFr2TJQ0 Auto bed leveling on my SD2!
Might give you some inspiration.
Yep, I've seen that. The beauty of this technique is that the nozzle and the probe are one and the same, so no offset is required and no servos need to be added.
The pain of this technique is that the sensor needs to be an analog input monitored for changes, so none of the firmware that is currently written is exactly suitable for using the variable resistor.
At least I've finally gotten my linux box setup to where I can compile the new beta firmware successfully for my printrboard (at least it says it compiled, I haven't worked up the nerve to upload it yet).
The pain of this technique is that the sensor needs to be an analog input monitored for changes, so none of the firmware that is currently written is exactly suitable for using the variable resistor.
All the boards used have available analog_ins, so not sure what the prob with the firmware is.
Claghorn wrote:The pain of this technique is that the sensor needs to be an analog input monitored for changes, so none of the firmware that is currently written is exactly suitable for using the variable resistor.
All the boards used have available analog_ins, so not sure what the prob with the firmware is.
Very nice idea Claghorn. But I agree, it would require some fiddling with the firmware, as it would need to rewrite the endstop logic.
All the boards used have available analog_ins, so not sure what the prob with the firmware is.
Just writing it :-). I notice that ENABLE_AUTO_BED_LEVELING appears on 51 lines and several different files in the firmware. How much of that code thinks it "just knows" the sensor is a simple switch, I don't know. Come to think of it, just sorting through all the layers of pin definitions to find which analog input pin is available and what header that maps to on the printrboard could easily take several days :-). I've worked on arduino projects before, but there is a big learning curve to get familiar enough with Marlin to be willing to fiddle the code. Maybe something to do over Christmas.
adrian wrote:All the boards used have available analog_ins, so not sure what the prob with the firmware is.
Just writing it :-). I notice that ENABLE_AUTO_BED_LEVELING appears on 51 lines and several different files in the firmware. How much of that code thinks it "just knows" the sensor is a simple switch, I don't know. Come to think of it, just sorting through all the layers of pin definitions to find which analog input pin is available and what header that maps to on the printrboard could easily take several days :-). I've worked on arduino projects before, but there is a big learning curve to get familiar enough with Marlin to be willing to fiddle the code. Maybe something to do over Christmas.
Well the problem is that as far as I understood, the bed leveling simply uses the Z endstop logic, which is (I believe) interrupt-based. So it can just plan a movement to Z=-10 and wait until the interrupt is triggered. What you would need to do instead would be to move the bed in .1mm steps and every time read the analog value... So a pretty radical change of approach. However, the good news is: it's not that complicated. I just had a look at the code and I believe you would just need to rewrite the function run_z_probe in marlin_main.cpp.
Re the pins, its pretty easy to find whats available - the documentation for the boards on the reprap wiki makes it pretty easy to track down.
Printrboard (current SDs) : http://reprap.org/wiki/Printrboard
Sanguinololu (Pre June-2013 SDs) : http://reprap.org/wiki/Sanguinololu
The sang has A0, A1, A2, A3, A4 spare... broken out to the I/O header
It has been a while, but I'm making lots of progress on the physical bits of the FSR bed sensor:
http://home.comcast.net/~tomhorsley/har … 20Mounting
It is almost to the point where I can't delay working on the firmware any longer, which brings me to the question: What the heck is the best version of the firmware to start with? Is there a specific github branch with all the latest bed level stuff integrated? Some zip file snapshot that is better?
My GitHub branch is the best Solidoodle specific firmware
https://github.com/ozadr1an/Solidoodle- … in_v1_beta
I clearly don't understand the github web page :-). When I use the pull-down menu to select the beta branch, it flickers for a moment then switches back to the Solidoodle-Marlin_v1 choice (no beta). The "Download zip" button does work though.
Yeah the download zip will get what you need.
GitHub gets easier and if you do any sort of tinkering it's worth getting the hang of since its more or less (rightly/wrongly) the defacto standard for revision controlled open source. ...
In case anyone is interested, I've got a lot of updated material in my web page:
http://home.comcast.net/~tomhorsley/har … level.html
So far, this still looks like it is going to work. I have the FSR mounted in a position where it seems to reliably get squeezed when I push up on the nozzle lightly, I've found that ADC2 on pin 59 is not used on the printrboard, and I've got the cable to the FSR hooked up there. I can build the firmware from source and upload it. All I need to do now is remember the Atmel programming I've forgotten and get the FSR working with the existing bed level code in Marlin. (Probably I'll first just add a command to print the ADC2 value so I can see if I have the pins and headers right and the value really does change when I poke the nozzle).
Meanwhile, I've been digging through the firmware and have reached a point of confusion about how to proceed. Is there any good place where a discussion of the innards of Marlin might provide good results? My problem at this point is the best way to add my analog input to the interrupt routine that polls all the analog inputs in temperature.cpp. Do I pretend the FSR is a thermistor and ifdef code elsewhere using the results? Do I add new cases to the switch and screw up the timing that appears to expect 8 cases in the switch? Do I add complicated ifdefs to replace one of the thermistor cases with an FSR case? Do I doulbe the number of cases in the switch and double the frequency of interrupts so the timing will be the same?
The progress continues! I now have firmware that adds a new command to tell me what values I'm been seeing on the analog pin I have connected to the force sensitive resistor, and I can run it in the manual control scree of RH and see different values when I'm not touching and touching the nozzle. (I've included a patch to the beta firmware on my web page showing exactly what I did - probably somewhat kludgy, but it works).
Still have to figure out how the heck to interface with the existing bedlevel code, but it does occur to me that I could write a stand alone program now to move the head around and measure the level at different positions and tell me how much to adjust the screws by to level the bed :-).
I've been reading the run_z_probe() code, and things would be a lot easier if I knew what was actually going on :-).
In the existing bed level setup, are the bed probe switches on the carriage connected to the same pin as the z-stop switch? Is the code measuring the position at normal Z home, then measuring it again after swinging down the probe and using that difference to drive the algorithm?
If I've got that right, I'd just have to home the Z axis, then disable the checks for the Z stop and move the bed manually (slowly I turned) till I monitored a change in resistance, perhaps backing off and enabling the z axis micro stepping to get the most accurate position estimate.
Am I on the right track here? I hate chasing wild geese :-).
Auto bed level uses a single switch. It also requires you to home all axis (G28) before you run the auto level command (G29). This is because the auto bed level uses absolute positioning for the probe points.
Also try to remember the code was written with the idea of using a servo to swing the switch out. So, if you home Z or home All, it swings the switch down and then uses that to 'home'. Then, you run the auto level command and it will (again) swing the switch down and probe three points on your bed. These three points (and not the first one) are used to calculate the correction factor. As a matter of fact, the G28 command will zero out the correction factors. Take a look at some of the introduction youtube videos to see that the switch for homing is the same for the auto level.
Now, Adrian can correct me if I am wrong, but the Z probe function just tells the Z axis to move down (further than it expects to go). The homing functions work the same way. It tells the axis to move 1.5 times farther than the axis length is defined. In other words, it is commanded to purposely hit the endstop. In the stepper.cpp file is the stepper Interrupt routine, which constantly checks the endstops while it writes the 'steps' to the output pins. If an endstop is defined, and is triggered, the MCU no longer writes any more 'step' outputs until the move is finished. The planner then knows what position it is in.
So.
What nobody has told you yet is that you will need to get pretty creative here. If you try to rewrite the stepper interrupt service routine, you will be hosed if you run a G28, since the nozzle will NOT be under the print surface after it homes X and Y. Possible fix would be to add an X/Y move to place the nozzle over the bed before it runs the HOME[Z-AXIS] in the G29 command.
I have no idea how you plan to insert the analog value into this to begin with. It sounds like your using a timer event to read the analog input. At the time you read the analog value, you should set/clear a bool value (as in HIT or NOT HIT). This could be the value you would evaluate in the stepper interrupt (instead of the Z switch pin). My only concern is that if you use one interrupt to read an analog value and another interrupt to write stepper output pulses governed by that analog value, your analog routine better run at nearly the same speed as the stepper routine or else the stepper will move much farther than what your sensor tells you it should stop.
Quite frankly, this is alot of firmware work, with a great opportunity for introducing alot of bugs into the system (analog noise cause and endstop hit when nowhere near the print surface, or what about when the nozzle hits a curled up edge in the middle of a print job?). Honestly, a much easier solution would be to run the sensor into a separate comparator that can output a digital high/low signal that would then be input to the MCU. Its more hardware, but you leave the fimrware alone. Although, this would still require you to perform an alternate method of homing all your axis before running the G29 command.
EDIT: reading what I posted sounds pretty ugly. If you want me to, I can post in laymans terms what is happening during the homing and auto-bed-level functions in another post. Then what I said might make more sense.
Actually that does make sense to me :-). Thanks. I guess that combined with the reading I've already been doing in the code helps.
I don't think I need to involve the stepper code with checking the analog input. (And I didn't invent the timer event to read the analog input, that timer was already there, and without major restructuring of the microcode it is where all analog inputs must be read since it is in control of the ADC mux - in fact without major modifications it can't read more than 4 analog values, so I've just stolen one to use for my FSR).
My current plan (which I think I've decided I can wedge into the microcode) is something like this:
1. Physically adjust the z-stop screw so the nozzle will be above the bed at least a little when it is hit.
2. Teach run-z-probe() to first home to the endstop, then disable the endstop and move just a little bit at a time till it sees the analog value change.
There is already an ifdef flag that says ENDSTOPS_ONLY_FOR_HOMING, so if that actually works, I can turn it on, and no one will be paying attention to the endstop or the analog value except when homing, when I'll know what is going on.
No doubt I'll have to include some geometry checks so I won't try to detect the nozzle touching the bed when I happen to be positioned off the bed surface.
At some point I might actually want to make it pay attention to the analog value all the time for really large changes so it can possibly detect the case where a large piece just got knocked at an angle and is jammed between the nozzle and the bed (but that's just a possible future frill).
And if I can't get any of that to work, I can always just write a stand alone program to use what I have now to detect the bed level and tell you exactly how much to turn each leveling screw and the z-stop screw to get into perfect adjustment :-).
Wow auto bed leveling is cool but writing firmware sounds tricky as hell!
OK, my latest firmware change seems like it might be working now:
http://home.comcast.net/~tomhorsley/har … ml#Results
but I realize I still have a foolish question: "How do I use it?" :-).
I assume I need to wedge a G29 bed probe command into the start code before it prints?
Yup. And it requires you to send a G28 code right before you do that (also in the start code).
is there a G code library? where it defines waht all the G and M commands mean?
SoliForum - 3D Printing Community → Hacks & Mods → Bed Level Sensor experiment
Powered by PunBB, supported by Informer Technologies, Inc.
