Printrbot Talk Forum

by **krog7d7** » 2014-Jul-Tue-14-Jul

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

**Sponsor**

by **bres55** » 2014-Jul-Tue-15-Jul

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.

by **Mooselake** » 2014-Jul-Wed-08-Jul

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

by **krog7d7** » 2014-Jul-Fri-03-Jul

by **Mooselake** » 2014-Jul-Fri-08-Jul

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

by **krog7d7** » 2014-Jul-Sat-18-Jul

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?

by **Mooselake** » 2014-Jul-Sat-20-Jul

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 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

by **RetireeJay** » 2014-Jul-Sat-21-Jul

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.

by **lwalkera** » 2014-Jul-Sat-22-Jul

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

by **krog7d7** » 2014-Jul-Sun-03-Jul

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

by **ei8htohms** » 2014-Jul-Sun-07-Jul

by **krog7d7** » 2014-Jul-Tue-01-Jul

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

by **mechanizedmedic** » 2014-Jul-Wed-10-Jul

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!

by **ei8htohms** » 2014-Jul-Wed-12-Jul

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?

by **mechanizedmedic** » 2014-Jul-Wed-17-Jul

by **ei8htohms** » 2014-Jul-Wed-19-Jul

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.

by **mechanizedmedic** » 2014-Jul-Wed-21-Jul

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

by **krog7d7** » 2014-Jul-Thu-23-Jul

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?

by **mechanizedmedic** » 2014-Jul-Sat-00-Jul

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.

by **ei8htohms** » 2014-Jul-Sat-14-Jul

by **Mooselake** » 2014-Jul-Sat-15-Jul

by **krog7d7** » 2014-Aug-Sat-22-Aug

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.

by **RetireeJay** » 2014-Aug-Sun-09-Aug

by **krog7d7** » 2014-Aug-Sun-19-Aug

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

by **krog7d7** » 2014-Aug-Mon-00-Aug

Read through a lot of threads including these below:

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

by **krog7d7** » 2014-Aug-Mon-02-Aug

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

by **krog7d7** » 2014-Aug-Mon-14-Aug

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

by **krog7d7** » 2014-Aug-Mon-15-Aug

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.

by **RetireeJay** » 2014-Aug-Mon-16-Aug

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)

by **krog7d7** » 2014-Aug-Mon-16-Aug

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.

by **krog7d7** » 2014-Aug-Mon-16-Aug

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.

by **krog7d7** » 2014-Aug-Mon-21-Aug

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.

by **krog7d7** » 2014-Aug-Mon-21-Aug

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, , 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

by **krog7d7** » 2014-Aug-Mon-22-Aug

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

by **thawkins** » 2014-Aug-Tue-00-Aug

by **krog7d7** » 2014-Aug-Tue-02-Aug

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

by **krog7d7** » 2014-Aug-Sun-18-Aug

Any ideas?

Stumped with this last piece of actually getting EVERYTHING working.

Thanks,
Ken

by **krog7d7** » 2014-Aug-Tue-01-Aug

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

I'm sooooo close to perfection! =)

Thx

by **RetireeJay** » 2014-Aug-Tue-08-Aug

by **jkeith248** » 2014-Aug-Tue-21-Aug

by **RetireeJay** » 2014-Aug-Wed-09-Aug

Here's the link for you:

by **Mooselake** » 2014-Aug-Wed-16-Aug

by **jkeith248** » 2014-Aug-Wed-16-Aug

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!

by **krog7d7** » 2014-Sep-Wed-17-Sep

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

by **TutherJay** » 2015-Jan-Wed-17-Jan

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

by **TutherJay** » 2015-Jan-Wed-17-Jan

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!!!!

by **RetireeJay** » 2015-Jan-Wed-17-Jan

by **TutherJay** » 2015-Jan-Wed-18-Jan

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?

by **RetireeJay** » 2015-Jan-Wed-19-Jan

Printrbot Talk Forum

Unified Firmware + Reversed X/Y axis for Printrbot Plus

Who is online