Welcome to the SeeMeCNC Community

Here @ my local Highschool trying to setup the Orion.
We have everything set but the G code that is being crunched seems to be trying to print upside down. Brim for instance, is above the print, with the "top" being below the build plate. Instead of incremending the Z height upwards, it is trying to go towards the earth.

Any ideas on how I can get this fixed?

It seems that the unit is trying to lower a build plate (which it doesn't have)
Can't find anywhere in repetier or cura that shows an Invert Z direction or any sort of disable build platform. Ideas?

mortinus wrote:It seems that the unit is trying to lower a build plate (which it doesn't have)
Can't find anywhere in repetier or cura that shows an Invert Z direction or any sort of disable build platform. Ideas?

In configuration.h you should see the following lines, changing them to the opposite value will change the direction. (E0 is extruder)
#define INVERT_X_DIR true
#define INVERT_Y_DIR true
#define INVERT_Z_DIR true
#define INVERT_E0_DIR true
You would want to change the Z_DIR False
You would need to edit the necessary lines then upload to the Rambo using the Arduino and selecting repetier.ino then upload but that I'm sure you know.
Stepper motor direction of rotation can also be changed by switching a pair of wires on the connectors, the problem is getting the pins out of the connector and switching them
some can be stubborn, usually there is a small hole in the connector where you can gently push the metal while pulling gently on the wire and it should release. A pair is defined
as pins 1 and 2 OR pins 3 and 4.

Trying this now; thanks!
The odd thing is this happened after a rollout upgrade from firmware .83 to .91

mortinus wrote:Trying this now; thanks!
The odd thing is this happened after a rollout upgrade from firmware .83 to .91

This has happened to others for the same reason. If you search the forum at the Rostock Max and Orion
for .091 you will find incidents that are the same as yours.

Nope this didn't work
Now my mid tower bearing plunges down which forces the gantry towards me outside the printing limits.

Not really sure what to do on this one. It homes just fine with the default settings, but printing is backwards.

Wiped it again, found EEPROM_MODE was = to 1 so it was using the EEPROM and overriding my settings somehow...no idea what happened but I've reflashed it disabling EEPROM and using default settings from the repetier /orion branch 0.91 firmware and it homes itself correctly again...now just trying to get the Z increment direction to be good.

Progress!?

Prints now in the correct direction, but is slamming into the build plate, with the vase.gco file included on the card.
I noticed there is no longer a menu option for Setting the Z height.
Any suggestions would be great...

mortinus wrote:Wiped it again, found EEPROM_MODE was = to 1 so it was using the EEPROM and overriding my settings somehow...no idea what happened but I've reflashed it disabling EEPROM and using default settings from the repetier /orion branch 0.91 firmware and it homes itself correctly again...now just trying to get the Z increment direction to be good.

The first page about the new .091 firmware tells you to clear the Eprom before installing.
If your prints are backwards then the x or y is inverted and moving the wrong way.
You may want to start over following the clearing of the Eprom first then getting the version
for the Orion and reinstall one more time. The process to clear the Eprom is discussed here:http://forum.seemecnc.com/viewtopic.php?f=54&t=4130
The second paragraph tells you how to clear the Eprom. You are pulling the firmware that is for the Orion, correct?

Yep,
Wrote EEPROM clear and reflashed firmware multiply. Still not able to save the new Z height for 0, nor do the sd card files print.
Not sure how this is possible with a fresh install :-\

mortinus wrote:Yep,
Wrote EEPROM clear and reflashed firmware multiply. Still not able to save the new Z height for 0, nor do the sd card files print.
Not sure how this is possible with a fresh install :-\

Not sure either, you may want to get in touch with John in support at seemecnc.com

If you've disabled the EEPROM (no idea why...), then of course the machine isn't going to retain the Z height setting you're making.

g.

geneb wrote:If you've disabled the EEPROM (no idea why...), then of course the machine isn't going to retain the Z height setting you're making.

g.

Gene he was supposed to clear the eprom as indicated on the first page of this thread, then install the Orion Repetier .091
There is no reason the Eprom should be disabled. If it is that would explain some of the problems.

All good now. I'll have to check to see if the EEPROM becomes disabled in .0091 in the version I have for some reason, says it happened right after the upload of new firmware. It would no longer set z.

I got everything working by manually calculating the z and changing it in config.h. Since that worked and LCD didn't id have to agree w EEPROM disable. Happy to report Orion deltas up and running at Chico Highschool drafting lab. They previously had two Uprints and the students were unable to use them due to high failure rate and material cost.

This Orion is the first "open" 3d printer the students can use.

Did you have to contact John at Seemecnc.com? Do you know how to re-enable the Eprom if it is disabled?

Hey Eaglezsoar,
I didn't contact them directly as I was in the middle of a lab and didn't really have the facilities for that. Dead zone/no reception or landline anyways.
Besides, it was definitely a great opportunity to learn as they say. We all learned a lot and it was great for the kids to be able to see how different open-source printers like the Orion are from the uPrint stratasys machines. Any issue like that with their current equipment would cost thousands to have techs sent out etc. It's refreshing to be able to port into the printer and fix things on the fly.

I'm reading the config now and it looks like it's just a setting under eeprom_mode. Any further insight would be appreciated as I do need to schedule another trip out there to "patch" this.

mortinus wrote:Hey Eaglezsoar,
I didn't contact them directly as I was in the middle of a lab and didn't really have the facilities for that. Dead zone/no reception or landline anyways.
Besides, it was definitely a great opportunity to learn as they say. We all learned a lot and it was great for the kids to be able to see how different open-source printers like the Orion are from the uPrint stratasys machines. Any issue like that with their current equipment would cost thousands to have techs sent out etc. It's refreshing to be able to port into the printer and fix things on the fly.

I'm reading the config now and it looks like it's just a setting under eeprom_mode. Any further insight would be appreciated as I do need to schedule another trip out there to "patch" this.

You are correct, set configuration.h to have this value defined #define EEPROM_MODE 1 then upload as normal. If the #define EEPROM_MODE is set to 0 it will disable the Eprom.
Glad you got most of it working.

Just checking, did you get the printer working correctly?

I won't be able to go back out to the Lab to "patch" it until next week, but it was working when I left. The students were printing their files

I really have NO clue what could have caused the Z direction going backwards (the original problem in this post), which completely disappeared after a few firmware uploads. At this point I'm chalking it up to a bum upload. Makes absolutely no sense.

mortinus wrote:I won't be able to go back out to the Lab to "patch" it until next week, but it was working when I left. The students were printing their files

I really have NO clue what could have caused the Z direction going backwards (the original problem in this post), which completely disappeared after a few firmware uploads. At this point I'm chalking it up to a bum upload. Makes absolutely no sense.

Agreed, it does not make any sense. I am glad the they can use the printers.

Mortinus,


I bet i know what you did.

Somehow you accidentally clicked on the 'set z=0.0 in the delta configration menu>set z height on the LCD. That sets the z=0 to wherever the head is at, which if you accidently click on it when it's homed out, will make it do what you describe.

Anyhow, awesome you dug in and got it figured out! Congrats! If you ever need anything, we're only 2hrs east of you, I travel to Chicago a lot, and will be in town tomorrow so hit us up if you need anything at all

Hey John!
Thanks for the ping.
I live about 72 hours west of Chicago or I would have taken you up on the offer (Chico)

Writing this after a 6 hour stint @ Chico High. By now I'm probably starting to look a bit unprofessional.
Been here since 7:30am. Giving up & Going home for now

I'm now completely convinced there is an error w/ the EEPROM or the harness..or..something.

It's printing but...it still won't level. It's "printable" But..first layer looks horrible. As I can't access the EEPROM to get the radius changed to adjust the convex/concave issue, it's rough.

Here's what I have done to try and enable EEPROM. It is not working, and I cannot access the EEPROM. Not sure if this means anything, but: uploading the EEPROM_Clear from arduino test takes..FOREVER!

0. Power up Orion/ Laptop / Connect via USB
1. Launch Arduino, Send EEPROM_Clear from Test files
2. Load the repetier file in arduino that loads the thousand other header files and the rest of the firmware programs. Edit the configuration.h to have the language NOT be german.
3. Locate EEPROM_Mode and "Change it to a value that wasn't present". As it was just wiped moments ago, I should be able to put anything (except 0) and it would use EEPROM. To be safe, I put 7, because I want to be able to use EEPROM.
4. Upload to Orion (Compile,Check+Upload)
5. Upload pass, Orion reboots.
6. Load Repetier Host. EEPROM grayed out. Connect to Printer. EEPROM grayed out.

Repeat steps 0-6 changing EEPROM_MODE to various values, including 0 to try and get EEPROM "visible" under repetier. I need the EEPROM visible not to set the Z height (I can do this manually) but to adjust the radius to cure the convex/concave.

I'm just tossing this last one in there for anyone who knows the wiring diagram; The SD Card randomly is not detected as well.

Any ideas would be really appreciated. I've spent about 14 hours so far trying to get this thing to be hands off, but I can't seem to nail it down.
As always, thanks so much for your support.


**MORE STUFF**
In case anyone is interested in how I have it able to be printing currently;
What I "know";

the "plane" is established in firmware, as is the radius calculated in firmware, and then stored in a var in EEPROM. This value is not accessible / manually editable outside of EEPROM. The Printer_radius is, but this is only one portion of a complex formula that affects the printer_radius ("complex" being 3 vars, but still). I only have control over the hardware at this point, and a very ROUGH plane origin (Max Z travel) through firmware if I am willing to calculate it.

What I don't know, or "unknowns"
I can no longer/can't drive the Chico High Orion via Repetier. It has 9 commands queued and sits there forever. Today I used the same laptop that drives the Orion @ work, so I wasn't sure if this was an issue. However, the Chico Highschool computer has "bad" USB ports...so I could not rule this out.
After I came home and plugged my laptop into the work Orion, it said "checksum wrong, clearing queued commands 1-9" and cleared out. The Chico High Orion would never do this. Even after clearing EEPROM and all data??

What I did;
Because EEPROM is not working and the firmware has a default value of Max Z travel set to 250, and the actual travel distance when all is said and done is between 220-240 depending on the setting of the Z height endstop screws, I could not run a G1 X0 Y0 Z0 script without it trying to impale itself.

Go into configuration>Z position in the LCD menu and manually lower it until it is visually at zero. For us, this is 16.4mm off of what manual zero was.
Subtract value from 250, manually adjust Z max in firmware > re-send firmware.
Now I am able to send G1 X0 Y0 Z0 without it tagging the glass & trying to commit suicide.

I now have either created a convex/concave issue as I have measured from a center point.
I now run the tower scripts that I've created in each tower to check the height there...I then follow the standard procedure to adjust towers, to have them perfect. I then check the center and it's much too tight... should be adjusting radius in the EEPROM......that's where I am stuck.

You really need to talk to John about why you do not have an Eprom. You certainly sound as if you know what you are doing and have done everything any of us would and still cannot access the Eprom. John can and will help you but reaching him via this forum is not usually possible. [email protected] is the way to contact him. I am impressed with the time you have taken and the skills you have shown. I think you have done all you can on your own, the rest needs to be resolved by John. I wish you the best of luck and be
sure to let us know what the final outcome is. If I have misread what you have written and you believe that you can access the eprom yourself, I apologize but I do not believe
that I have misread what you have written.

Eaglezsoar wrote:You really need to talk to John about why you do not have an Eprom. You certainly sound as if you know what you are doing and have done everything any of us would and still cannot access the Eprom. John can and will help you but reaching him via this forum is not usually possible. [email protected] is the way to contact him. I am impressed with the time you have taken and the skills you have shown. I think you have done all you can on your own, the rest needs to be resolved by John. I wish you the best of luck and be
sure to let us know what the final outcome is. If I have misread what you have written and you believe that you can access the eprom yourself, I apologize but I do not believe
that I have misread what you have written.

Thanks Eagle, I sure appreciate that.
I definitely have had a steep learning curve
You're correct, EEPROM cannot be read.

The issue he's hitting involves communication with the printer. The EEPROM issue is simply a symptom. We hammered some things out on IRC yesterday, but because he's not got the printer handy it makes it a difficult troubleshooting task.

g.