Bed Auto Leveling.. check this out

Hello all,

When I use the G28 command, all goes as expected, the X, Y and Z axes are zeroed (Z using the servo moved switch, in the center of the bed) and my axis work as they should, then I send a G29 and the probe is made in my 3 specified points, but my Z axis gets reversed and the bed tries to go up instead of down. I have tried with Marlin from ErickZalm and AlexBorro, both downloaded today and the problem persists..... what can I do??? any sugestions will be very appreciated guys.

Thanks!

I have several machines all setup with Auto Bed Leveling, and all have been working fine up until today.
One of my machines started doing what you describe with the Z axis. It would start to home a very little and then moved in the upward direction. I could move it back down again to the start position or up as far as I wanted. This gave me a clue. I checked the connections on the micro switch that is connected to the servo and found one lead had come loose.
Re-made the connection and all was fine again.

From this I think you should check your endstops by sending a M119 in Pronterface to make sure that the Z is not triggeredwhen it shouldn't be.

---

[regpye.com.au]
"Experience is the mother of all knowledge." --Leonardo da Vinci

check your endstops by sending a M119 in Pronterface to make sure that the Z is not triggered when it shouldn't be.

---

[regpye.com.au]
"Experience is the mother of all knowledge." --Leonardo da Vinci

Thank you very much regpye!!

Today I made some tests with M119. My endstops are never triggered when they should not be. Not after a G28 nor G29, but still my Z axis gets reversed after a G29.

Tomorrow I will triple check my Z endstop connections and will test again. I will let you know the results.

Thanks again

well after much struggling I have this working on a sanginololu with no servo

the real issuse is the math for the offset and the bed locations as it turns out
if you go beyond any of your soft limits there is trouble

after re reading this thread again for third time I found it on page 3
I hope this helps someone else

thank you everyone for all your posts
and re read this thread as you work through the setup for this there is all kinds of good info
here that you may not think you need until you do

and most of all thank you Alex for making this work
and Lars for the start of it I think finally my prusa will be able to spend more time printing than tweaking

Hi again, folks:

Today I reconnect my endstop switch completely, making sure that there were no problems with the wiring or false contacts and my problem persists, after a G29, my Z axis is still being reversed so I cant send a piece to the printer because my bed will try to go up instead of down.....

I am very confused, can you please help me further??

Thanks in advance!!

Quote
ludara
Hi again, folks:

Today I reconnect my endstop switch completely, making sure that there were no problems with the wiring or false contacts and my problem persists, after a G29, my Z axis is still being reversed so I cant send a piece to the printer because my bed will try to go up instead of down.....

I am very confused, can you please help me further??

Thanks in advance!!

Your assumption that you can not send a piece of work to the printer because you are having trouble with auto bed leveling is not true. While you are working through the issues associated with auto bed leveling you can just omit the G29 command to do things normally.

Specifically, in your start up code for the printer you still want the Slicer to issue a G28. This will set the correction matrix to unity. Just do not issue a G29 until you have things worked out. Or conversly, manually edit the GCode to delete the G29 until you have everything figured out and working.

Edited 2 time(s). Last edit at 01/06/2014 02:32PM by edn.

Could also be a defective microswitch. Try one from another axis that you know works. And you can test one while not connected to the servo with m119.

I have issues with setting op the probe locations, and before probing the z not first homing the x and y with a m29, but guess that is firmware problem, cant also work with my reprapworld keypad. But that should be firmware bugs, i had one that worked but was an old one and the latest marlin has so much that others put in that in some setups there can be specific problems.

Greetings W.

---

Mendelmax 1.5, E3D v6, ramps 1.4, drv8825, kapton heated bed (working)
Sparkcube 1.1, e3d v6, radds 1.5, raps128, 12864 lcd, octoprint (build and testing)
Sparkcube 1.1 XL, radds 1.5, raps128, lcd, fsr autobed, octoprint on odroid (building)

Thank you guys:

Edn: I appreciate your advice. I already kne that avoiding a G29 the printer is functional, but then for sure you dont have the benefits of the auto compensation. Will try to find the problem and will report later....

Wvantoorn: I will tray to change the switch as you recommend, the one I am using now responds correclty to M119 in all tryings, but for the sake of peace of mind, will change it. I am also changing my arduino and ramps.

Will report all my findings and troubles.....

Thank you!

Hi again,

New arduino, new ramps, new switch, the problem still exists.

What can I do now???

Thanks

Quote
ludara
Hi again,

New arduino, new ramps, new switch, the problem still exists.

What can I do now???

Thanks

This problem is showing up in too many people's setup. I suspect there is a logic flaw that the community is going to have to work through. I think the most likely explaination is the correction matrix has it's normal pointing in the wrong direction.

Do you have the 3 point probe code? Or do you have the 'ACCURATE_BED_LEVELING' code that probes an nxn matrix of points? You need to know the answer to this question in order to proceed with my path of resolving this.

I have attached 2 files for you. Simply replace the existing VECTOR_3.CPP file in your build environment with the attached file in this post. All of the logic is the same but the debug routines have been expanded to print with 7 digits of accuracy.

The other file G29.CPP has the 'ACCURATE_BED_LEVELING' point probe code in it. You need to replace the G29 code in your MERLIN_MAIN.CPP file with this code. It is very verbose. If you have 'ACCURATE_BED_LEVELING' you can just replace that case of the switch statement with this code. If you have the older code, delete the 'ACCURATE_BED_LEVELING' portion of this code but then do the replace of the G29 code.

The purpose in doing all this is you will get a huge amount of information that you can cut & paste for us to help with the diagnosis of what is wrong. At the very end of this code the bed leveling matrix will get printed. From this information it is likely we will be able to say exactly what is right and how to fix what is wrong.

Edited 1 time(s). Last edit at 01/07/2014 10:04AM by edn.

edn:

Thank you very much for your time and knowledge!

I did what you instructed me to do and after a G29 here you have what Pronterface returned:

SENDING:G29
Bed G29.1: X:45.0000000 Y:10.0000000 Z:1.7938970
Bed G29.2: X:45.0000000 Y:400.0000000 Z:3.0104327
Bed G29.3: X:445.0000000 Y:400.0000000 Z:2.5990529
Bed level matrix:
0.9999996 0.0000000 -0.0010284
0.0000000 0.9999951 0.0031193
-0.0010284 0.0031193 -0.9999946
echo:endstops hit: Z:2.60

My code had the 'ACCURATE_BED_LEVELING' portion, and I replaced the whole G29 section, and I am sure you know it, the z axis gets still reversed after de G29. If I can/need to do anything else to provide you with more info, please just let me know.

Thanks again!

Ludara. Are your switches normally open or normally closed
I noticed issues with my normally open switches once I changed them to normally closed things seemed to work better I am pretty sure
The logic has some issues with setups that are not quite normal

Broncosis:

Thank you for the advice, I had the z axis endstop as normally open, changed it to normally closed but z axis still gets reversed after G29.

Will continue reporting....

And when you take the marlin from alex or edn, wouldnt that be an option and compare? Or upload their firmware and look if that does it for you? I know there are so many different commits, and changes that when someone puts something in marlin, it wont work anymore for others.
And there is no checking like with repetier. That is open source, it evolves, but sometimes there has to be a time-out and check if the essence of the firmware is still there, to make all our printers work fine.
Got my printer build 4 months ago, and after bad plastic components i bought, not fitting parts, so much different manuals, and so many opinions, the virus is loosing me, and i dont want that. I want to build, commit, let it be checked and adjusted, and only then put it in the firmware so it will work for all.
I bought a build RRW keypad and LCD, and lcd works after a week tweaking, but the keyboard still wont work. Another €20 down the drain.

Just wanted to tell my opinion, with the great work from alex, edn, eric, and so many others we have our great reprap scene, but as we say in holland, there are to many treas in the way to see the beautiful forest.

I hope i did not offend anyone, that is absolutly not my intention, i just want us all to have fun and not the frustation when a tiny issue gets a big problem for someone.

Its just my 2 cents.

With regards and a thanks to all who make it possible for us,

Wilco van Toorn

---

Mendelmax 1.5, E3D v6, ramps 1.4, drv8825, kapton heated bed (working)
Sparkcube 1.1, e3d v6, radds 1.5, raps128, 12864 lcd, octoprint (build and testing)
Sparkcube 1.1 XL, radds 1.5, raps128, lcd, fsr autobed, octoprint on odroid (building)

Hi Ludara,
Just for comparisons sake, what are your settings in configuration.h for the following?

#define INVERT_X_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false <--Thing to note for me is that I run a mendal and have to set this to "false", not true as noted in comment...
#define INVERT_Z_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR true // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

Also, where on the plate does each point touch on G28. For me, I am "back left", "front left" and "front right" where "0,0" is back left.

What I am wondering is if things are getting confused because assumptions are different than what others have. (say front right is 0,0 for others)

Can anyone with this working let me know what your settings are and if they are the same for you?

thanks

Quote
ludara
edn:

Thank you very much for your time and knowledge!

I did what you instructed me to do and after a G29 here you have what Pronterface returned:

SENDING:G29
Bed G29.1: X:45.0000000 Y:10.0000000 Z:1.7938970
Bed G29.2: X:45.0000000 Y:400.0000000 Z:3.0104327
Bed G29.3: X:445.0000000 Y:400.0000000 Z:2.5990529
Bed level matrix:
0.9999996 0.0000000 -0.0010284
0.0000000 0.9999951 0.0031193
-0.0010284 0.0031193 -0.9999946
echo:endstops hit: Z:2.60

My code had the 'ACCURATE_BED_LEVELING' portion, and I replaced the whole G29 section, and I am sure you know it, the z axis gets still reversed after de G29. If I can/need to do anything else to provide you with more info, please just let me know.

Thanks again!

OK... We know what is going sour! I'm running the 'ACCURATE_BED_LEVELING' code, but you are using the original 3 point probe. The problem is in the lower right corner of the matrix. You have a -.9999946 and that is what is causing the inversion problem. I don't know why that is showing up, but that is what is reversing your Z-AXIS direction. Here is what my correction matrix looks like:

Eqn coefficients: a: -0.000099 b: -0.001518 d: 9.578395
planeNormal x: 0.0000990 y: 0.0015175 z: 1.0000000

Bed level matrix:
1.0000000 0.0000000 -0.0000990
0.0000000 0.9999989 -0.0015175
0.0000990 0.0015175 0.9999989

echo:endstops hit: X:0.04 Z:9.25

The diagonal should be all positive numbers and each number should be very close to unity. You have the last number inverted!

It may be possible that if you just enable the 'ACCURATE_BED_LEVELING' the problem goes away. I suggest you do that first for two reasons. First the correction matrix is generated in a totally different mannor. It is calculated by solving a set of simultanious equations for a best least squares fit. It is possible that what ever is going wrong for you will not be going wrong if that code is used instead.

If that fails, we can brute force fix the problem until a more elegant solution shows up in the code base. We would just manually flip the sign of the lower right number. Probably, we would have to flip the signs of the other numbers off the diagonals but I'm not positive about that off the top of my head.

Can you turn on 'ACCURATE_BED_LEVELING' and see if the matrix that gets generated has positive numbers close to unity along the diagonal? If so, we will probably be out of the woods and you will be a happy camper. If that doesn't solve your problem, we will dig in and figure out how to warm over the matrix so it does what you need.

Edited 1 time(s). Last edit at 01/07/2014 05:39PM by edn.

Quote
TobinatorCO
Hi Ludara,
Just for comparisons sake, what are your settings in configuration.h for the following?

#define INVERT_X_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false <--Thing to note for me is that I run a mendal and have to set this to "false", not true as noted in comment...
#define INVERT_Z_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR true // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

Also, where on the plate does each point touch on G28. For me, I am "back left", "front left" and "front right" where "0,0" is back left.

What I am wondering is if things are getting confused because assumptions are different than what others have. (say front right is 0,0 for others)

Can anyone with this working let me know what your settings are and if they are the same for you?

thanks

Toby, almost for sure, that is what is going on. Ludara's correction matrix looks plausable. But the last number along the diagonal is inverted which means the normal to the plane is pointing the opposite direction. Almost for sure, that is because the calculations aren't smart enough (yet) to handle an inverted axis or probe point.

If switching on the ACCURATE_BED_LEVELING code does not make the problem go away, there will be a simple solution for everybody. I'll write a little function to change the matrix such that the normal vector is pointing the opposite direction. It won't be a big deal to make it so it checks to see if a correction is needed, and only apply the correction if necessary.

Edited 1 time(s). Last edit at 01/07/2014 05:57PM by edn.

TobinatorCO

Here are my settings:

#define INVERT_X_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR false // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR false// for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

My probe points are "back right", "front right" and "front left" where "0,0" is back right.

You are right, different designs requiere different settings.

Thanks

Quote
ludara
edn:

Thank you very much for your time and knowledge!

I did what you instructed me to do and after a G29 here you have what Pronterface returned:

SENDING:G29
Bed G29.1: X:45.0000000 Y:10.0000000 Z:1.7938970
Bed G29.2: X:45.0000000 Y:400.0000000 Z:3.0104327
Bed G29.3: X:445.0000000 Y:400.0000000 Z:2.5990529
Bed level matrix:
0.9999996 0.0000000 -0.0010284
0.0000000 0.9999951 0.0031193
-0.0010284 0.0031193 -0.9999946
echo:endstops hit: Z:2.60

My code had the 'ACCURATE_BED_LEVELING' portion, and I replaced the whole G29 section, and I am sure you know it, the z axis gets still reversed after de G29. If I can/need to do anything else to provide you with more info, please just let me know.

Thanks again!

I looked a little bit more at how the correction matrix is generated. I still think you ought to turn on the ACCURATE_BED_LEVELING and see if that fixes your problem because that is a better methodology for this solution .

But if that doesn't work for you, go search for the line in MARLIN_MAIN.CPP that looks like this:

vector_3 planeNormal = vector_3::cross(xPositive, yPositive).get_normal();

I haven't done it (because I don't want to mess my printer up) but if you change this line to:

vector_3 planeNormal = vector_3::cross(yPositive, xPositive).get_normal();

I think your problem will go away. By changing the order of the terms to the cross product, you are going to invert the direction of the normal vector that is produced. And that should make your Z-AXIS go in the right direction whan a coordinate is rotated by the correction matrix.

With a little luck this will get fixed 'correctly' in the main code base soon so people don't run into this any more!

Edited 1 time(s). Last edit at 01/07/2014 08:09PM by edn.

edn:

Sorry for the delayed response, but I want you to know that when I used the G29 with ACCURATE_BED_LEVELING, nothing in my printer moves, not the carriage, the bed, the servo..... but I got the following data in return:

SENDING:G29
xGridSpacing: 200.000000
yGridSpacing: -195.000000
Bed Height:
> 0.000000 0.000000 0.000000
< 0.000000 0.000000 0.000000
> -0.000000 0.000000 0.000000
Total for Bed Height: -0.000000
Average Bed Height: -0.000000
Correct +.14 with one clockwise turn.
Delta Bed Height:
>+0.000000 +0.000000 +0.000000
<+0.000000 +0.000000 +0.000000
>-0.000000 +0.000000 +0.000000



Eqn coefficients: a: 0.000000 b: 0.000000 d: 0.000000
planeNormal x: 0.0000000 y: 0.0000000 z: 1.0000000
Bed level matrix:
0.0000000 0.0000000 0.0000000
0.0000000 0.0000000 0.0000000
0.0000000 0.0000000 0.0000000


However, I changed the line

vector_3 planeNormal = vector_3::cross(xPositive, yPositive).get_normal();

to

vector_3 planeNormal = vector_3::cross(yPositive, xPositive).get_normal();

and just as you told, the printer now reacts as it should, the values on the diagonals of matrix are positive and the z axis is not reversed!!!!

I can not thank you enough!

I owe you, man!

Now to test and probe everything....

Quote
ludara
edn:

Sorry for the delayed response, but I want you to know that when I used the G29 with ACCURATE_BED_LEVELING, nothing in my printer moves, not the carriage, the bed, the servo..... but I got the following data in return:

SENDING:G29
xGridSpacing: 200.000000
yGridSpacing: -195.000000

...


Eqn coefficients: a: 0.000000 b: 0.000000 d: 0.000000
planeNormal x: 0.0000000 y: 0.0000000 z: 1.0000000
Bed level matrix:
0.0000000 0.0000000 0.0000000
0.0000000 0.0000000 0.0000000
0.0000000 0.0000000 0.0000000


However, I changed the line

vector_3 planeNormal = vector_3::cross(xPositive, yPositive).get_normal();

to

vector_3 planeNormal = vector_3::cross(yPositive, xPositive).get_normal();

and just as you told, the printer now reacts as it should, the values on the diagonals of matrix are positive and the z axis is not reversed!!!!

I can not thank you enough!

I owe you, man!

Now to test and probe everything....

Ludara,

I'm glad you got it going... But as it turns out Toby's problem is probably exactly the same as yours. Here is what I sent him after he sent some of his CONFIGURATION.H settings. Can you check and see if this is what is causing you problems? (Change that line of code back and make changes similarly to what I suggest to Toby --- And turn the ACCURATE_BED_LEVELING back on) ? If your front and back numbers are backwards like I suspect, that fully explains why the cross product vector is pointing in the wrong direction and reversing your Z-Axis.

---------------------------------------------------------
Toby,

I think the problem is these two lines:

#define BACK_PROBE_BED_POSITION 10
#define FRONT_PROBE_BED_POSITION 170

Try reversing them. Make them be:

#define BACK_PROBE_BED_POSITION 170
#define FRONT_PROBE_BED_POSITION 10

The front and back in the names kind of assumes the origin is at the front left. But if you have things rotated, you need to still have the back number bigger than the front number. That would explain why the loop isn't probing any points. Specifically, in the G29 code there is a loop to probe points:


for (double yProbe=FRONT_PROBE_BED_POSITION; yProbe <= BACK_PROBE_BED_POSITION+.001 /* incase of round off errors */ ; yProbe += yGridSpacing) {

This line in my G29 code is heavily modified from the distribution code, but the logic is the same. (It uses double precision with a fudge factor to make sure the last column never gets omitted.)

With your #define's yProbe starts off bigger than the BACK_PROBE_BED_POSITION and the loop that probes points never happens.

Edited 1 time(s). Last edit at 01/08/2014 01:28PM by edn.

edn:

I will do what you want as soon as I got back in town tomorrow at lunch time more or less.... wil post results inmediately.

Greetings

Quote
regpye
Check out this part that is further up in this forum.



There is a problem in the code for the feedrates when moving for bed leveling.

#define XY_TRAVEL_SPEED 6000 // X and Y axis travel speed between probes, in mm/min

This is not only used for XY travel but also for Z travel. That is the reason the Z motor stall.

I fixed some things in the code so that the Z moves uses the homing_feedrate and not XY_TRAVEL_SPEED This fixed the stalling Z motor problems for me.

You could also set the XY_TRAVEL_SPEED to someting like 150 but that means XY travel would be very slow.

static void do_blocking_move_to(float x, float y, float z) {
float oldFeedRate = feedrate;

feedrate = homing_feedrate[Z_AXIS];

current_position[Z_AXIS] = z;
plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
st_synchronize();

feedrate = XY_TRAVEL_SPEED;

current_position[X_AXIS] = x;
current_position[Y_AXIS] = y;
plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
st_synchronize();

feedrate = oldFeedRate;
}

Hi regpye,

I have the same problem. When putting my xy_speed to 150 instead of 6000. It works ok. But i prefer a higher xy speed and only slowing down the Z-axis speed. How do you implement the above code in the Marlin_main.cpp? Do you have to delete anything or just put this code somewhere in?

I'm not so much of a software guy, but i'm learning a lot here
Thanks for all the info, everybody...

msmone

Quote
msmone

Quote
regpye
Check out this part that is further up in this forum.



There is a problem in the code for the feedrates when moving for bed leveling.

#define XY_TRAVEL_SPEED 6000 // X and Y axis travel speed between probes, in mm/min

This is not only used for XY travel but also for Z travel. That is the reason the Z motor stall.

I fixed some things in the code so that the Z moves uses the homing_feedrate and not XY_TRAVEL_SPEED This fixed the stalling Z motor problems for me.

You could also set the XY_TRAVEL_SPEED to someting like 150 but that means XY travel would be very slow.

static void do_blocking_move_to(float x, float y, float z) {
float oldFeedRate = feedrate;

feedrate = homing_feedrate[Z_AXIS];

current_position[Z_AXIS] = z;
plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
st_synchronize();

feedrate = XY_TRAVEL_SPEED;

current_position[X_AXIS] = x;
current_position[Y_AXIS] = y;
plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
st_synchronize();

feedrate = oldFeedRate;
}

Hi regpye,

I have the same problem. When putting my xy_speed to 150 instead of 6000. It works ok. But i prefer a higher xy speed and only slowing down the Z-axis speed. How do you implement the above code in the Marlin_main.cpp? Do you have to delete anything or just put this code somewhere in?

I'm not so much of a software guy, but i'm learning a lot here
Thanks for all the info, everybody...

msmone

- Go edit the file MARLIN_MAIN.CPP
- Find the function do_blocking_move_to() It is roughly 950 lines from the start of the file.
- Replace that function with the function regpye posted. It is in bold to make it clear exactly where it starts and ends. (I have this code in my build environment. It is correct and works as expected)
- rebuild the Marlin firmware in Arduino
- Upload the code to your board.
- Test to make sure it is behaving as you expect.

Edited 1 time(s). Last edit at 01/10/2014 06:34PM by edn.

Where would you attach servo 2?

Quote
i-make-robots
Where would you attach servo 2?

The Marlin firmware doesn't have a use for a second servo right now. But the support is in place to handle more servo's if you have a purpose for one.

edn - I have use for the second servo and I'm using a RUMBA controller. What I don't know is where to attach it.

I see from earlier in the thread that EXP3 pins 2/4/6 are for a servo, provided you swap the GND and 5V pins.
In the same message Yotiro references a second servo, but doesn't indicate where to attach it. I'm guessing 8/10/12, same config. Can anyone confirm?

Quote
i-make-robots
edn - I have use for the second servo and I'm using a RUMBA controller. What I don't know is where to attach it.

I see from earlier in the thread that EXP3 pins 2/4/6 are for a servo, provided you swap the GND and 5V pins.
In the same message Yotiro references a second servo, but doesn't indicate where to attach it. I'm guessing 8/10/12, same config. Can anyone confirm?

I don't have an answer for you. But I do have some information that will probably help you. The Marlin firmware is good but it is a mash-up of several different code bases. There is an inconsistancy between the logical pin numbers depending upon which set of library functions you use to access them. Be aware of that because if you see inconsistant and non-logical things happening, you may be running into a difference depending upon which set of functions you use to access the pins.

I have a PrintrBoard and it was a bit of effort to find a pin I could control for the servo and then to access it. And I wanted a confirmation switch so I could get the M600 filament change code to work nicely without an LCD panel. So I had to find another pin I could use in input mode. I have a couple of suggestions:

Get a volt meter or a LED logic probe and connect it up to a physical pin. You can use the M42 to set the logic value on a pin. You would do something like:

M42 P 11 S 0 To set logical pin 11 to zero. If I remember right, to set it to a logic one something like:
M42 P 11 S 255

If you connect up your logic probe or volt meter to a likely pin, you might want to use the following code. I was pulling my hair out trying to get documentation for the PrintrBoard and it was tough to come by. So I ended up just writing a function that would brute force scan the logical I/O pins and let me watch to see when I found one that I was connected to with a volt meter. It does not mess with logical pins that have been defined as 'Sensitive', so it is fairly benign. Depending on how you monitor a given pin, you may need to change the delays in the code, and once you find one using the M43 scanning code, you can go back and mess with it using M42.

But anyway... If you add this code right under the 'case 42:' code, build it, put it into your board, and then send it a M43 command with your logic probe connected, it probably won't take you too long to find a pin you can use for your extra functions. And the M43 code prints out the legitimate values to use for HIGH and LOW when writing to a pin. I don't remember what they are off the top of my head. But you should be using those values when you verify things with the M42 command.


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

case 43: //M43 - EDN hack to look for GPIO pins
int pin_number;
int i;

SERIAL_PROTOCOLPGM("M43 - EDN GPIO Hackery:\n");
SERIAL_PROTOCOLPGM("HIGH/LOW: ");
SERIAL_PROTOCOL(HIGH);
SERIAL_PROTOCOLPGM("/ ");
SERIAL_PROTOCOL(LOW);
SERIAL_PROTOCOLPGM("\n");
for( pin_number=0; pin_number<55; pin_number++) {
SERIAL_PROTOCOLPGM("Pin ");
SERIAL_PROTOCOL(pin_number);
for(i = 0; i < sizeof(sensitive_pins); i++) {
if (sensitive_pins == pin_number) {
SERIAL_PROTOCOLPGM(" Sensitive!\n");
goto NEXT_GPIO;
}
}

pinMode(pin_number, OUTPUT);
delay(50);
digitalWrite(pin_number, LOW);
delay(500);
digitalWrite(pin_number, HIGH);
delay(1000);
digitalWrite(pin_number, LOW);
delay(500);
// analogWrite(pin_number, HIGH);
pinMode(pin_number, INPUT);
delay(50);
SERIAL_PROTOCOLPGM("\n");
NEXT_GPIO: ;
}
SERIAL_PROTOCOLPGM("Done...\n\n");
break;

Quote
i-make-robots
edn - I have use for the second servo and I'm using a RUMBA controller. What I don't know is where to attach it.

I see from earlier in the thread that EXP3 pins 2/4/6 are for a servo, provided you swap the GND and 5V pins.
In the same message Yotiro references a second servo, but doesn't indicate where to attach it. I'm guessing 8/10/12, same config. Can anyone confirm?

Here are a couple more functions (commands) I put in when I was trying to get my servo going. I added a M45 to set a given logical pin (that has a servo on it) to some angular position. And when I was fighting the power problems of the server, I added a fancier M46 command to move the servo in steps from where it is to the new position and some rate. Maybe those will be helpful for you too????

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


case 45: //M45 - EDN hack to mess with servo values
if (code_seen('S'))
{
int pin_status = code_value();
int pin_number = 11;
if (code_seen('P') && pin_status >= 0 && pin_status <= 255)
pin_number = code_value();

if (servo_endstops[Z_AXIS] > -1) {
servos[servo_endstops[Z_AXIS]].attach( pin_number );
servos[servo_endstops[Z_AXIS]].write(servo_endstop_angles[Z_AXIS * 2]);
delay(PROBE_SERVO_DEACTIVATION_DELAY);
servos[servo_endstops[Z_AXIS]].detach();
}
}
break;

//
//
// Usage of M46 Servo Step command:
//
// Use the form:
// M46 S0 P11 D20 J5
// M46 P11 D1 J4 S50
//
// S xx is the desired servo angle at completion of the command
// P xx is the virtual Pin the Servo command is on
// D xx is the milisecond delay between each step
// J xx is the angle step size between delays
//
case 46: //M46 - EDN hack to mess with servo values
SERIAL_PROTOCOLPGM("M46 - EDN Servo Step Move:\n");
if (code_seen('S'))
{
double servo_destination = code_value();
double servo_current_pos = 0;
int pin_number = 11;
double step_delay = 1000;
double step_size = 1;

if (code_seen('P') && servo_destination >= 0 && servo_destination <= 255)
pin_number = code_value();

if (code_seen('D') )
step_delay = code_value();

if (code_seen('J') )
step_size = code_value();

servo_current_pos = servos[servo_endstops[Z_AXIS]].read();

if (servo_endstops[Z_AXIS] > -1) {
servos[servo_endstops[Z_AXIS]].attach( pin_number );
if ( servo_current_pos < servo_destination) {
while ( servo_current_pos+step_size < servo_destination ) {
servos[servo_endstops[Z_AXIS]].write( servo_current_pos+step_size );
delay( step_delay );
servo_current_pos = servos[servo_endstops[Z_AXIS]].read();
SERIAL_PROTOCOLPGM("M46 Servo at: ");
SERIAL_PROTOCOL_F( servo_current_pos,5 );
SERIAL_PROTOCOLPGM("\n");
}
SERIAL_PROTOCOLPGM("M46 Final step move.\n");
servos[servo_endstops[Z_AXIS]].write( servo_destination);
delay( step_delay );
} else {
while ( servo_current_pos+step_size > servo_destination ) {
if ( (servo_current_pos-step_size) < 0.001 )
break;
servos[servo_endstops[Z_AXIS]].write( servo_current_pos-step_size );
delay( step_delay );
servo_current_pos = servos[servo_endstops[Z_AXIS]].read();
SERIAL_PROTOCOLPGM("M46 Servo at: ");
SERIAL_PROTOCOL_F( servo_current_pos,5 );
SERIAL_PROTOCOLPGM("\n");
}
SERIAL_PROTOCOLPGM("M46 Final step move to ");
SERIAL_PROTOCOL_F( servo_destination,5 );
servos[servo_endstops[Z_AXIS]].write( servo_destination);
SERIAL_PROTOCOLPGM("\n");
delay( step_delay );
}
servo_current_pos = servos[servo_endstops[Z_AXIS]].read();
SERIAL_PROTOCOLPGM("M46 Final read() Position: ");
SERIAL_PROTOCOL_F( servo_current_pos,5 );
SERIAL_PROTOCOLPGM("\n");

delay(PROBE_SERVO_DEACTIVATION_DELAY);
servos[servo_endstops[Z_AXIS]].detach();
}
}
SERIAL_PROTOCOLPGM("M46 command completed.\n");
break;