Unified Firmware + Reversed X/Y axis for Printrbot Plus

[krog7d7]

Hi all-

I've been trying to get Printrbot support to fix this and not getting any traction.

The Unified Firmware, v2/v3 is supposed to work for ALL bots. Those who have used it know that is generally true but you have to do some tweaking to get it to work right for your own bot.

I have a highly upgraded Printrbot Plus v2. I've done the Z-X upgrade, the probe along with other enhancements. I am currently using v2 of the unified firmware and when using with the Printrbot Plus, you have to swamp the X/Y axis motors to get them oriented in the correct direction.

Even though I have dialed in my settings and have things working well, one of the most FRUSTRATING things is with no firmware fix for the X/Y motor axis', ALL my prints come out reversed. Imagine how frustrating that is if you're model requires a certain orientation to come out correct......text comes out backwards, models are flipped, etc. etc.

Couple of questions I'm hoping someone will take the time to answer:

1. If I educate myself on editing and recompiling the firmware, does anyone know if I can fix it with a couple of line changes in the code?
2. Does anyone know what specific section they could point me to in order to fix the X/Y axis'?

3. Anyone know of a work around that is fairly straight forward in Repetier that would allow me to "flip" the model so that text would come out correct?
I would like to avoid having to go into a 3D modeling program to correct the models. Seems like a little too much work for something that should be working in the firmware.

Any other suggestions? I can't imagine I'm the only one who is frustrated with this.

Appreciate any help or suggestions.

Thanks,
Ken

[bres55]

You could try using CURA, this has a mirror (flip), option, save the G-code, and load that into Repetier, but that will involve getting familiar with Curas setings. I do this sequence on every occasion, as I prefer Cura as a slicer, but repetier, has better control. I believe there is a new version of repetier, with Cura in-built, but I haven't found the need to update yet.
There is also an option in Cura to save the model as an STL, once you have mirrored it, and then you could use repeteir as normal, but I have not used this option, so cant' say if it alters the model in any negative way.
This dosen't address your problem with the motor leads swapped, but it might be a temporary work around.

[Mooselake]

Pull the affected motor connector from the printrboard and swap two adjacent wires on just one side of the connector. I'm not near my machine or I'd take a picture, but it's been covered in the forum before. There are little springy fingers that hold the sockets in the plastic shell. Push on them with something pointy (but not really sharp or it'll stick in the soft metal) while gently pulling back on the wires. Exchange the positions and push them back in until they click. Best to search for one of the previous posts.

Kirk

[krog7d7]

Pull the affected motor connector from the printrboard and swap two adjacent wires on just one side of the connector. I'm not near my machine or I'd take a picture, but it's been covered in the forum before. There are little springy fingers that hold the sockets in the plastic shell. Push on them with something pointy (but not really sharp or it'll stick in the soft metal) while gently pulling back on the wires. Exchange the positions and push them back in until they click. Best to search for one of the previous posts.

Kirk

Well shit, I feel stupid. It's that simple? Thanks!

-Ken

[Mooselake]

RJ posted better directions recently, try searching for retireejay, and it's pry and not push. Tablet, hard to post links...

Not stupid, only unenlightened! Somebody else discovered it, not me, so I'm just the messenger.

Kirk

[krog7d7]

I swapped only the outside wires with each other (red and blue). This made the motors seize so doesn't seem like the solution.

I'm back to having the motor wires plugged in backward, still having original issue with all models 'flipped'.

Any other suggestions?

[Mooselake]

Put the wires back where they came from, if you didn't already. The two outside wires are different coils, so you made two open circuits. Shouldn't have hurt anything since it would have looked like the connector was off as far as the printrboard was concerned.

Hold the connector with the red wire to the left with the red and blue wires are back in their original position. Exchange the red wire and the wire to it's immediate right - if you number them from the left then red is #1and blue #2. You're swapping wires 1 and 2; the first time you'd swapped wires 1 and 4.

Here's RJ's post describing how to do this, better than I did It's for the Z motors, but other than the doubled up wires it's the same. No guarantee the colors match, since different motors have the colors connected to different places - the spare stepper in the moosecave had the coils wired differently than RJs according to my ohmmeter.

Just to make sure I understood correctly, by flipped, you mean only one axis moves in the wrong direction.

Kirk

[RetireeJay]

Moose said it right. You only swap ADJACENT wires on one end or the other end of the connector. If you numbered them 1,2,3,4, you could swap 1 and 2 or you could swap 3 and 4. But swapping 1 and 4 won't work and swapping 2 and 3 won't work.

Actually, AFIK, plugging in the connector to the board with the connector flipped around does exactly the same thing. I didn't have the schematic when I first made that mod and I did it the hard way.

I've gotten the impression that some versions of the firmware expect the Y axis to home to Y max instead of Y min. I may be totally wrong on this; I don't have any Simples myself, and I don't play around with my firmware unless there's a need to on my machine. I don't have the z axis sensing, so I'm kinda out of the loop on all the most recent mods. If the firmware expects to "home" to Y max, then you've got to have your "endstop" switch relocated to Y max.

[lwalkera]

Yeah, the pinout of the motor connectors was designed so that you can reverse the motor direction by just flipping the connector.

[krog7d7]

All great suggestions.....I'll give it another try.

Am I wrong to assume this can be fixed in the firmware? If so, does anyone know what section of the firmware I would fix this?

Seems like a whole lot of trouble of switching wires, etc. etc. when it should just work through the firmware.

Even though I didn't want to go through the trouble, it's easier to just mirror the model in 3DS than to keep messing with the wires.

It's kind of disheartening how unorganized the firmware for each of our bots is. Just reading the description on this link about the x/y/z orientation will make your head spin: https://github.com/Printrbot/Marlin/rel ... imple-1403

[ei8htohms]

You'd think it would be an easy thing to do, wouldn't you?

When I was struggling to get the (regretfully mis-named) "bed level" firmware working on my Printrbot GO (v.1) I struggled mightily with the inverted Y axis. I modifed every firmware I could find, playing with the

Code: Select all

#define INVERT_Y_DIR true/false

and

Code: Select all

#define Y_HOME_DIR -1

(in Configuration.h) to try to invert the Y axis successfully but with no luck whatsoever. Mostly I couldn't get it to home when the Y axis was moving in the "correct" direction. Finally I found a firmware that had "bed leveling" (tram correction, bed compensation, let's call it something more descriptive) and the proper Y axis orientation for my bot and just went with it.

TL;DR - It's not as easy to modify in the firmware as you might imagine.

[krog7d7]

Appreciate everyone's help and suggestions.

I went ahead and switched the adjacent wires and seems to be working fine. About to test print some models.

Thanks!
-
Ken

[mechanizedmedic]

The parameters to change start at line #294 in the Configuration.h file (https://github.com/Printrbot/Marlin/blo ... ion.h#L294). I compiled/installed the default firmware (write down all of your M501 values first!), looked at what needed to be inverted, then made my changes and re-compiled/installed. Now I have a custom firmware that has all of my settings entered by default... PID, e-steps, acceleration, speed, built dimensions, etc. are all in there!

[ei8htohms]

mechanizedmedic: Which firmware did you start with? One can only assume things have been cleaned up since I last tinkered with the firmware (Feb '14?), but it was not as simple as you're describing at that time. Are you also able to get "accurate bed leveling" working?

[mechanizedmedic]

mechanizedmedic: Which firmware did you start with? One can only assume things have been cleaned up since I last tinkered with the firmware (Feb '14?), but it was not as simple as you're describing at that time. Are you also able to get "accurate bed leveling" working?

I followed the instructions on a few different wikis -- PrintrbotTalk and RepRap mostly -- on how to setup a build environment and compile Marlin. I downloaded the source code .zip straight from PrintrBot's github. So far it's been pretty easy to tell which parameters do what as the comments are fairly clear. If I couldn't tell from the comments then I was always able to find a better description by Google-ing the name of the definition.

I did have to comment out some of the bed leveling code that was giving compiling errors. I would assume this means it's not fixed, but I don't have a probe so its not something that I had considered.

[ei8htohms]

Ahhh. I didn't mean to imply that any of that stuff was insurmountable. I've modified several Marlin forks previously, but getting the "bed leveling" firmware sorted out was another animal. The O.P. specifically cited the addition of a probe, so getting the "bed leveling" code functioning seems somewhat critical.

[mechanizedmedic]

From everything I can tell the latest release should work for for him... https://github.com/Printrbot/Marlin/rel ... imple-1403

[krog7d7]

The 1403 firmware doesnt correct the issue

in addition, swapping the wires ONLY fixed the need to install the wires in reverse, but it still doesnt resolve the fact that without a firmware fix, the models are still reversed

or am i doing something incorrect in mu assumptions?

[mechanizedmedic]

I think there is some confusion about two separate issues here: The direction that the axis should move, and which end of the axis the endstop is located at. So...

The coordinate of the axis should increase as the hotend is further from the front left corner of the print bed. If any axis is not doing this then you either need to reverse that motor's connector or change it's inversion in the firmware.

Once the motors are moving in the correct directions they need to move toward the end stop when homing. If an axis travels away from the endstop when homing you can either relocate the endstop or change "#define X_HOME_DIR" in your firmware.

[ei8htohms]

I think there is some confusion about two separate issues here: The direction that the axis should move, and which end of the axis the endstop is located at. So...

The coordinate of the axis should increase as the hotend is further from the front left corner of the print bed. If any axis is not doing this then you either need to reverse that motor's connector or change it's inversion in the firmware.

Once the motors are moving in the correct directions they need to move toward the end stop when homing. If an axis travels away from the endstop when homing you can either relocate the endstop or change "#define X_HOME_DIR" in your firmware.

I think you're not fully understanding the problem that krog7d7 is having. Trying to coach someone through getting the bed "leveling" (compensation) firmware working on a Printrbot+ with probe from the perspective of what worked for you on a Simple without bed compensation is just leaving too many gaps.

My input may not be of any greater use frankly since I don't fully understand the problem either, but I least I can say I started from a very similar place with trying to get bed compensation firmware functioning on my GO! v1 and was ultimately successful despite banging my head against what sounds like the same wall as krog7d7 for quite a while.

What I do know is this: When I tried to get the bed leveling firmware working on my GO! v1, for virtually every version of the firmware I tried, changing the

Code: Select all

#define INVERT_Y_DIR true/false

and

Code: Select all

#define Y_HOME_DIR -1/1

did not help. Either the Y axis was reversed or else the Y axis wouldn't home at all. It's been a few months now so I can't honestly remember how often I also tried flipping the connector for the Y axis around, so maybe there was something more I could've done with those.

That said, I did eventually find this firmware and have it working now on my bot:

https://github.com/Printrbot/Marlin/releases/bedlevel-v2

I did modify a number of things in the firmware, but it doesn't appear that I had to modify the direction OR the home direction of any of the axes.

[Mooselake]

What do you mean by reversed? Can you take and post some pictures? It's not just one reversed axis (although, if I understand it correctly, two reversed axes would cancel out).

Kirk

The 1403 firmware doesnt correct the issue

in addition, swapping the wires ONLY fixed the need to install the wires in reverse, but it still doesnt resolve the fact that without a firmware fix, the models are still reversed

or am i doing something incorrect in mu assumptions?

[krog7d7]

Sorry for the delays in responding.

I swapped the wires as suggested above, so here is what is happening now:

* I've got "X" axis working correctly. When I home "X", it moves in the proper direction. I can move freely between 0-150mm. I can verify by using "GO X50" to move X axis to +50mm.

* I've got the "Y" axis wokring, but not correctly. When I home "Y", it moves in the correct position to go home. However, when I try to move the "Y" axis with the Repetier controls, it won't move. When I use "G0 Y15" it will move the opposite direction of Y home (assumption is that home = 0).

* So it's like the "X" axis is totally fine at 0 when homed. The "Y" axis seems like home = 200. So when I home it's 0,200 instead of 0,0.

I've been searching like a maniac but haven't found a Gcode or printer setting to fix this.

Is it possible I have to swap wires again just for the Y motor?

Any other clues?

Did any of that make sense?

Thanks for the help.

[RetireeJay]

OK, let's break this down.

The firmware to go to "Y home" is independent of the firmware commands to move Y towards plus or towards minus directions.

The firmware won't allow you to manually move to a Y position that's negative (less than zero). But it will allow you to manually move to positive values of Y, even before you "home"

So the first thing to do is to manually set the Y axis in the middle before you turn on the 'bot and then issue a command to move toward positive Y. If the table (on a Plus) moves toward you, all is well. If it moves away from you, then you need to reverse the Y motor plug (with power off!) and try again. Once you have Y direction established, then you can go on to work on the Y homing.

If it's homing in the wrong direction, and you are using the Unified firmware, I don't exactly know why that would be. I THINK the relevant section of "Configuration.h" is this:

Code: Select all

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define min_software_endstops false // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true  // If true, axis won't move to coordinates greater than the defined lengths below.
// Travel limits after homing
#define X_MAX_POS_DEFAULT 205
#define X_MIN_POS_DEFAULT 0
#define Y_MAX_POS_DEFAULT 205
#define Y_MIN_POS_DEFAULT 0
#define Z_MAX_POS_DEFAULT 200
#define Z_MIN_POS_DEFAULT 0

#define X_MAX_LENGTH (base_max_pos[0] - base_min_pos[0])
#define Y_MAX_LENGTH (base_max_pos[1] - base_min_pos[1])
#define Z_MAX_LENGTH (base_max_pos[2] - base_min_pos[2])

// The position of the homing switches
//#define MANUAL_HOME_POSITIONS  // If defined, MANUAL_*_HOME_POS below will be used
//#define BED_CENTER_AT_0_0  // If defined, the center of the bed is at (X=0, Y=0)

//Manual homing switch locations:
// For deltabots this means top and center of the cartesian print volume.
#define MANUAL_X_HOME_POS 0
#define MANUAL_Y_HOME_POS 0
#define MANUAL_Z_HOME_POS 0
//#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing.



Which seems to say that Y should be moving toward negative values when told to go home, and that Y home is equal to zero. That's the default configuration in Unified, as far as I know. And it should be what you want. I assume that your Y "endstop" switch is actuated when the Y table is farthest away from you, i.e. the printhead is at the closest end of the table to you, where Y = 0.

[krog7d7]

Hi RJ-

Thanks for the tips.

Here is what I've experienced:

1. "So the first thing to do is to manually set the Y axis in the middle before you turn on the 'bot and then issue a command to move toward positive Y. If the table (on a Plus) moves toward you, all is well. If it moves away from you, then you need to reverse the Y motor plug (with power off!) and try again. Once you have Y direction established, then you can go on to work on the Y homing."

Results
*I manually moved the print head to be in the middle of the print bed before I turned on the printer.
*When I turn on the printer and do a positive move toward Y, the print bed moves AWAY from me.
*Since it moves away, I turn it off and swap the Y motor reversing it.
*With the Y motor now reversed, I follow the same steps as above.
*I issue a positive move toward Y, the print bed now moves TOWARDS me.
*However, now when I home Y, it's obviously not hitting the end stop that is set/installed at the front of the Printrbot Plus.

So now I am working on getting the Configuration.h file adjusted. I'll post back with results.

Thanks,
Ken

[krog7d7]

Read through a lot of threads including these below:
http://www.printrbottalk.com/forum/viewtopic.php?f=19&t=6259
http://www.printrbottalk.com/wiki/index.php?title=FirmwareUpdate

I changed only one setting so far:
Default = #define Y_HOME_DIR -1
Changed = #define Y_HOME_DIR 1

I got the firmware to compile successfully, flashed my Printrbot Plus......and the Y home is still not homing toward me (the front of the Printrbot where the Y end stop is).

If this additional note helps, I've got it to where Home Y0 = 0. It's just not homing in the correct direction. For example, if I hit positive Y10, the print bed moves toward me. Negative directions move away from me. (I may be repeating myself from an earlier post).

I'm going to keep looking at the settings. Would appreciate any insight if I'm doing something incorrectly.

Thanks,
Ken

[krog7d7]

Looks like I might have figured it out.

I'm going to do some more tests, but it looks like I've corrected the problem with a combination of swamp/reverse motor plug ins + recompiling the firmware with the following changes notes below:

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define min_software_endstops true // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true // If true, axis won't move to coordinates greater than the defined lengths below.
// Travel limits after homing
#define X_MAX_POS_DEFAULT 200
#define X_MIN_POS_DEFAULT 0
#define Y_MAX_POS_DEFAULT 200
#define Y_MIN_POS_DEFAULT 0
#define Z_MAX_POS_DEFAULT 200
#define Z_MIN_POS_DEFAULT 0

#define X_MAX_LENGTH (base_max_pos[0] - base_min_pos[0])
#define Y_MAX_LENGTH (base_max_pos[1] - base_min_pos[1])
#define Z_MAX_LENGTH (base_max_pos[2] - base_min_pos[2])

// The position of the homing switches
#define MANUAL_HOME_POSITIONS // If defined, MANUAL_*_HOME_POS below will be used
//#define BED_CENTER_AT_0_0 // If defined, the center of the bed is at (X=0, Y=0)

//Manual homing switch locations:
#define MANUAL_X_HOME_POS 0
#define MANUAL_Y_HOME_POS 0
#define MANUAL_Z_HOME_POS 0

[krog7d7]

Now today's problem is.....

I was only able to find the Unified Firmware source files for "Unified Firmware v2". V2 doesn't seems to recognize level probe command G29.

Now I'm searching for the v3 source files.

Side rant: Does anyone else think this is something that Printrbot team should be all over? Their firmware used to be somewhat organized and understandable. Going through this drill has made me realize what a mess they have created.

-Ken

[krog7d7]

Ughh, I don't know what happened. I felt I was so close.....and now auto level probe firmware in any version (v2/v3) won't recognize G29 even after re-flashing.

[RetireeJay]

The Unified firmware pre-dated the auto-leveling probe, so yes you need a newer version. But there are more recent versions on the Printrbot Marlin Github site. See my article on firmware updating in the Printrbottalk Wiki (a paragraph from it is copied here):

In software, the equivalent of the STL file is a “hex” file – a file that’s been “pre-compiled” and is ready to flash into the Program memory. If you are just repairing the firmware on a board that has become corrupted somehow, you don’t need to have the “source code” and compile it; you can just “flash” a hex file directly. There are several “pre-compiled” versions of programs for the Printrbot. Printrbot.com makes them available on their web site, and there are other versions available on Github. (Finding files on Github can be challenging for beginners, but using Github is not within the scope of this topic. However, here is an example link to several recent versions of the Printrbot firmware: https://github.com/Printrbot/Marlin/releases)

[krog7d7]

Hi RJ,

So that's what is weird. I've reflashed in the normal fashion with just a hex file. For example, I download v3 here: https://github.com/Printrbot/Marlin/rel ... unified-v3

I flashed....and I've reflashed, etc. etc.....but G29 is non existent as well as M212 when I M503 manually.

I've checked the probe. It's plugged in correctly, its powered because I can see the light go on when it senses metal.

It's just like G29 doesn't exist and I don't know how that is possible.

I'm going to retrace my steps and try again.

[krog7d7]

I see what you're saying. You're telling me that in Unified v2/v3 that level probing may not have been supported. But from everything I've read, and 'seen' in the configuration.h, it does mentioned auto level probing.

However, I went back to re-trace my steps. I ended up downloading the Metal_1403 firmware. It does do G29 and auto level. However, yet again I have to go in a swap wires from the previous firmware I was using in the original post. (I swear I was using Unified v2).

So I am now back at the start when I had all the axis' going in negative incorrect directions. I've gone in and tried to edit the configuration.h file and makefile as I did when I thought I was getting close to solving this thing.....

I can compile successfully with and without my changes. However, no matter if I compile with or without changes, when I go to load the hex file into Flip, I'm getting "address is out of range" and the range is displayed as "0x0 - 0x0"

Now back to feeling clueless. =(

Any help or insight appreciated.

I will also mention again I can't believe how badly organized these firmware are.

[krog7d7]

Anyone know what happened to this firmware?

I believe this was the one I was using that was working with my printrbot plus and the inductive probe.

http://printrbot.com/wp-content/uploads/2014/05/Marlin.Simple.Inductive.V3.hex_.zip

[krog7d7]

I have no idea if I'm making progress at all. =)

I went back to star all over, double check my steps. I'll probably reply back with screenshots to make it easier to follow.

During my restart, I've gone with this firmware, https://github.com/Printrbot/Marlin, since all of the others don't seem to work for me.

Results so far, I've been able to get back to the point of having all axis direction operating in the proper/expected +/- directions.

I've been able to get G29 and auto level probing back to being recognized, but now....of course....a new challenge. The G29 command that is supposed to probe 3 different spots on the print bed, is now only probing on the X axis.

Back to the grind of researching wtf it's doing that.

Thanks,
Ken

[krog7d7]

I'm taking off for a few hours, haven't made any progress on the Z probing in the firmware.

What I did notice is interesting and might someone tell me what's going on.....

If I'm at X/Y (0,0) and I do G29, it will probe 0,0 like 2 times, then move to X(max) -10 and probe.

If I do X/Y (0,200) and I do G29, it will probe Y max, then move to 0,0, then move to X(max) -10.

But I haven't figured out where or how to set it to probe at y 200 to start.

Any ideas? I think I'm getting closer again.

Thanks,
Ken

[thawkins]

I'm taking off for a few hours, haven't made any progress on the Z probing in the firmware.

What I did notice is interesting and might someone tell me what's going on.....

If I'm at X/Y (0,0) and I do G29, it will probe 0,0 like 2 times, then move to X(max) -10 and probe.

If I do X/Y (0,200) and I do G29, it will probe Y max, then move to 0,0, then move to X(max) -10.

But I haven't figured out where or how to set it to probe at y 200 to start.

Any ideas? I think I'm getting closer again.

Thanks,
Ken

that usually happens if the probe point is outside of the size it thinks the bed is. PLus you have to do a G28 to zero X/Y before each G29 otherwise it could be starting in a random position.

check that Y-BACK position - Y PROBE Displacement (y distance from hot end to probe) is less than the maximum size of the Y AXIS.

[krog7d7]

I double checked it. It seems okay.

Just in case I'm not clear, I've pasted a snippet of the modded firmware:

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define min_software_endstops true // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true // If true, axis won't move to coordinates greater than the defined lengths below.

// Travel limits after homing
#define X_MAX_POS_DEFAULT 205
#define X_MIN_POS_DEFAULT 0
#define Y_MAX_POS_DEFAULT 205
#define Y_MIN_POS_DEFAULT 0
#define Z_MAX_POS_DEFAULT 200
#define Z_MIN_POS_DEFAULT 0

#define X_MAX_LENGTH (base_max_pos[0] - base_min_pos[0])
#define Y_MAX_LENGTH (base_max_pos[1] - base_min_pos[1])
#define Z_MAX_LENGTH (base_max_pos[2] - base_min_pos[2])
//============================= Bed Auto Leveling ===========================

#define ENABLE_AUTO_BED_LEVELING // Delete the comment to enable (remove // at the start of the line)

#ifdef ENABLE_AUTO_BED_LEVELING

// these are the positions on the bed to do the probing
#define LEFT_PROBE_BED_POSITION 10
#define RIGHT_PROBE_BED_POSITION X_MAX_LENGTH-10
#define BACK_PROBE_BED_POSITION Y_MAX_LENGTH-10
#define FRONT_PROBE_BED_POSITION 10

// these are the offsets to the prob relative to the extruder tip (Hotend - Probe)
#define X_PROBE_OFFSET_FROM_EXTRUDER_DEFAULT 5
#define Y_PROBE_OFFSET_FROM_EXTRUDER_DEFAULT 0
#define Z_PROBE_OFFSET_FROM_EXTRUDER_DEFAULT -4

[krog7d7]

Any ideas?

Stumped with this last piece of actually getting EVERYTHING working.

Thanks,
Ken

[krog7d7]

Nobody has any more suggestions? Am I just doing something wrong or not understanding a setting?

I'm sooooo close to perfection! =)

Thx

[RetireeJay]

Your settings look just like my settings. But here's a clip from my Configuration.h which includes a few more lines than what you showed above. I don't have auto-leveling firmware, so you have some settings that I don't.

Code: Select all

===========================================================================
//=============================Mechanical Settings===========================
//===========================================================================

// Uncomment the following line to enable CoreXY kinematics
// #define COREXY

// coarse Endstop Settings
#define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors

#ifndef ENDSTOPPULLUPS
  // fine Enstop settings: Individual Pullups. will be ignored if ENDSTOPPULLUPS is defined
  #define ENDSTOPPULLUP_XMAX
  #define ENDSTOPPULLUP_YMAX
  #define ENDSTOPPULLUP_ZMAX
  #define ENDSTOPPULLUP_XMIN
  #define ENDSTOPPULLUP_YMIN
  //#define ENDSTOPPULLUP_ZMIN
#endif

#ifdef ENDSTOPPULLUPS
  #define ENDSTOPPULLUP_XMAX
  #define ENDSTOPPULLUP_YMAX
  #define ENDSTOPPULLUP_ZMAX
  #define ENDSTOPPULLUP_XMIN
  #define ENDSTOPPULLUP_YMIN
  #define ENDSTOPPULLUP_ZMIN
#endif

// The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
const bool X_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops.
const bool Y_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops.
const bool Z_ENDSTOPS_INVERTING = false; // set to true to invert the logic of the endstops.
//#define DISABLE_MAX_ENDSTOPS
//#define DISABLE_MIN_ENDSTOPS

// Disable max endstops for compatibility with endstop checking routine
#if defined(COREXY) && !defined(DISABLE_MAX_ENDSTOPS)
  #define DISABLE_MAX_ENDSTOPS
#endif

// For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1
#define X_ENABLE_ON 0
#define Y_ENABLE_ON 0
#define Z_ENABLE_ON 0
#define E_ENABLE_ON 0 // For all extruders

// Disables axis when it's not being used.
#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z true
#define DISABLE_E false // For all extruders

#define INVERT_X_DIR true    // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR true    // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR true     // 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

// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1

#define min_software_endstops false // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true  // If true, axis won't move to coordinates greater than the defined lengths below.
// Travel limits after homing
#define X_MAX_POS_DEFAULT 205
#define X_MIN_POS_DEFAULT 0
#define Y_MAX_POS_DEFAULT 205
#define Y_MIN_POS_DEFAULT 0
#define Z_MAX_POS_DEFAULT 200
#define Z_MIN_POS_DEFAULT 0

#define X_MAX_LENGTH (base_max_pos[0] - base_min_pos[0])
#define Y_MAX_LENGTH (base_max_pos[1] - base_min_pos[1])
#define Z_MAX_LENGTH (base_max_pos[2] - base_min_pos[2])

// The position of the homing switches
//#define MANUAL_HOME_POSITIONS  // If defined, MANUAL_*_HOME_POS below will be used
//#define BED_CENTER_AT_0_0  // If defined, the center of the bed is at (X=0, Y=0)

//Manual homing switch locations:
// For deltabots this means top and center of the cartesian print volume.
#define MANUAL_X_HOME_POS 0
#define MANUAL_Y_HOME_POS 0
#define MANUAL_Z_HOME_POS 0
//#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing.

//// MOVEMENT SETTINGS
#define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E
#define HOMING_FEEDRATE {50*60, 50*60, 4*60, 0}  // set the homing speeds (mm/min)

// default settings

#define DEFAULT_AXIS_STEPS_PER_UNIT   {63.36,63.36,2272.72,590}
#define DEFAULT_MAX_FEEDRATE          {100, 100, 2, 14}    // (mm/sec)   
#define DEFAULT_MAX_ACCELERATION      {2000,2000,30,10000}    // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.

#define DEFAULT_ACCELERATION          3000    // X, Y, Z and E max acceleration in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  3000   // X, Y, Z and E max acceleration in mm/s^2 for retracts

// Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing).
// The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder).
// For the other hotends it is their distance from the extruder 0 hotend.
// #define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis
// #define EXTRUDER_OFFSET_Y {0.0, 5.00}  // (in mm) for each extruder, offset of the hotend on the Y axis



[jkeith248]

So,

I had the EXACT same issue, here and after wasting an entire day of being stubborn and not changing the location of my Y endstop, I found a solution posted elsewhere.

Quoted from the frankes website (incredibly frustrating that one cant post links that will save HOURS....)

When I wired up my Reprap and started printing, I noticed that all my prints were mirrored along the Y axis — I’d set it up with the end stop at the front and configured it so that the print bed moved forward when I clicked Y- in pronterface (printrun), and not back. (When the table moves back, the print head essentially moves forward along it.)

The end stops were already in place and I didn’t want to move them, but no combination of INVERT_Y_DIR and Y_HOME_DIR in Configuration.h would work. I even tried changing Y_ENDSTOP_INVERT, knowing full well that it wouldn’t help either.

So how do you flip an axis without moving the end stop or the home position? The answer is to change both INVERT_Y_DIR and Y_HOME_DIR in Configuration.h, and also swap the values for Y_MAX_PIN and Y_MIN_PIN in pins.h for the specific motherboard you’re using.

I followed these instructions, recompiled the firmware and BAM! Fresh custom compiled firmware for my Printrbot Plus V2.1

I used the newest Printrbot metal simple 1403 firmware and fixed the endstop issue....

[RetireeJay]

Here's the link for you: http://www.thefrankes.com/wp/?s=reprap+y+axis

[Mooselake]

... incredibly frustrating that one cant post links that will save HOURS....

You'll be able to post links soon. Until then we'll try to help you out, like Jay just did.

Unfortunately there's a good reason for the restriction - it also limits the ability of most spammers to post links to inflate their search engine ranking. The flip side to your frustration is that, even with the link restriction, I spent about an hour this morning deleting spam and banning spammers. I'm just one of several moderators who do our best to keep the sludge out of PBT.

Kirk

[jkeith248]

Thank you all for posting the link. I really appreciate the feedback on the reason for it to. I totally understand, the reason and I thank you again for adding the link.

This forum is most certainly appreciated.

Thanks again!

[krog7d7]

Sorry for being absent, life....work....etc. =)

I still haven't 100% fixed the issue, but here is what I did find.

If I use G28 prior to using G29, it will properly execute the bed probing in the 3 points between X and Y correctly.

Now please don't jump to conclusions that, "Duh, you need to home x/y before G29!" Previously, I would do a manual homing of X and Y through repetier, execute G29 and I would experience the issue below:

What I did notice is interesting and might someone tell me what's going on.....

If I'm at X/Y (0,0) and I do G29, it will probe 0,0 like 2 times, then move to X(max) -10 and probe.

If I do X/Y (0,200) and I do G29, it will probe Y max, then move to 0,0, then move to X(max) -10.

But now, when I explicity do G28, it homes to the center of the print bed. Following that, I execute G29 and it probes correctly.

I'm able to live with that but still curious what I might be doing wrong or misunderstanding.

Thanks,
Ken

[TutherJay]

Mind if I chime in?

Well, as I didn't hear any dissenters, here goes:

Can't finger out why this attempt w/ Unified v3 is so problematic for me. I WAS running a slightly modified version for myself but needed to up the ante for MAX_TEMP so I can roast marshmallows and stuff. That brought me here cuz my movement went berzerk, all three axes moving the wrong way but seeming to know which way to head for homing. So I reversed the INVERT_?_DIR booleans and tried again. As I feared, although all 3 now moved the correct direction (+/-) they also now headed the WRONG direction for home. So I changed all 3 ?_HOME_DIR defines to 1 (as they were all -1, of course). Now, though all 3 know +/- to move and know which way toward home, clicking any of the handy, dandy HOME buttons on the Manual Control tab of RH no longer moves any given axis until it finds its switch -- if it's not with (I'm guessing) 10mm. That's all the farther it will move in a single attempt. Then there's the difference between X & Y when it IS with reach: when Y hits its switch it does its usual bounce-and-set dance, but X just grinds like it can't tell. Z I haven't bothered to home all the way, yet, but this ain't the worst of it anyway! After homing X and Y one would expect to be able to move back in a positive direction all the way to the other end, but - NO!!! It will NOT MOVE EITHER MOTOR, yet it updates the position counters as if it DID move. Then, thinking it's out there off of zero, it will ATTEMPT to perform a move in the negative direction, if so instructed, only to grind the motor because it was actually still at zero.

Wacky tobaccy, for sure!

Looking like I'm going to have to resort to a prebuilt hex file and abandon my plans to BBQ, if I'm going to get ANY useful work done this week. The kids will be SO disappointed, but I can only tear out so much hair, and it'll be GONE!

...and I'll be back to fighting with Bridge, which has driven me up AND down the wall, several times.

So this constitutes a pretty weird one, doesn't it?

Big, long sigh. . . .

Later

tj

[TutherJay]

PS - if anyone happens to know where I could find the MAX_TEMP value in the hex file, which I could hack w/ a hex editor, I'd be WILDLY grateful!!!!

[RetireeJay]

PS - if anyone happens to know where I could find the MAX_TEMP value in the hex file, which I could hack w/ a hex editor, I'd be WILDLY grateful!!!!

Look for this in Configuration.h:
#define HEATER_0_MAXTEMP 275

I have no idea what this will look like in the hex file. ASCII? (probably not). Integer? (probably not). Floating point? (seems the logical choice, since it's going to get compared to a floating point value).

[TutherJay]

How do...

I'd guess FP, too, but it's only a semi-edumacated guess. Most likely it's going to be an interesting exercise to hunt it down in the bin file, but at this juncture that seems the best way out for me. I'm thinking it's not likely that my un-modified build of UniV3 won't precisely match the stock provided bin, but if I compare the two, then compare the stock bin w/ my MAXTEMP mod'ed build, a compare of those two comparisons may bring it to the fore. FInding Robin Hood's barn without GPS?

For now I'm going to try this stuff at 265 under the stock firmware and see if it can manage to keep from donking its head on the ceiling. If not, I'll try 260, perhaps. At least it will give the Pbot something to do while I do that comparison hunting and some other chores.

Oh - is it too late for lunch?

Couldn't help but notice the silence re: weirdness. Do we chalk that up to my compiling skills?

[RetireeJay]

Couldn't help but notice the silence re: weirdness. Do we chalk that up to my compiling skills?

Ummm. I wouldn't say compiling skills per se, but somehow it sounds like you have managed to invert so many things that it's hard to keep track of which end is up.

If you can get to a condition where (starting from power-on) you motor moves in Direction A when you press the + button and moves in Direction B when you press the - button, AND it also moves in Direction B when you tell it to "Home" then all you have to do is make sure that A is really positive and B is really negative by reversing the way the motor is plugged in to the board, if necessary. (This also assumes that your "endstop" switches are normally closed and go open when touched, and that you have not changed the Configuration to mess with that expectation. Use the M119 command to see the status of your switches as seen by the software.)