Mhackney's Rostock Max

[mhackney]

It is unique and very rich looking. The more I print with it, the more I like it!

[aerouta]

Eagle, from a couple of days ago regarding the cool PLA colors I got. I have now printed with the wine red and turquoise and very happy to report that they print very well indeed. The colors are awesome. That red is a nice deep and translucent wine. I really like it.\

[img]http://mhackney.zenfolio.com/img/s5/v13 ... 8308-3.jpg[/img]

From the top down:

Real KBell Engineering on eBay eBay:
Green

faveprices on eBay:
Yellow
Turquoise
Sea Green
Wine Red

The faveprices on Ebay have some nice colors like the wine red. Could you let us know your opinion on quality when you get a chance to try a spool from them?
Definitely interested!

I see you are using a threaded thermister. Do you have to thread the hole yourself?

[mhackney]

Yes you do. M3-.5 tap.

[cope413]

I've been meaning to make that switch for a long time now. Just too lazy to break it all down and do it.

Any noticeable change with the threaded therm? How much different were your PID settings?

[mhackney]

My PID was pretty much dead on. I did recalibrate but there wasn't a lot of change and it ran fine on the previous settings. Calibration was spot on too. I used a bit of thermal grease when installing to get better conductivity. I just got 4 in the mail today for my new Kraken hot end(s).

[mhackney]

Well, I'm trying to make a final push to get my Kraken upgrade finished. I made a lot of progress on wiring and getting ready for the swap to the new Azteeg X3 Pro - and that is where the pain began!

I finished soldering the connectors on the X3 pro, checked my work under a magnifier and then installed the 8 stepper drivers. At this point, I wanted to upload Repetier and start testing.

Problem 1: the Repetier .91 release that we've all been using does not compile if you set the board type to either RAMPS (board 33) or Azteeg X3 (board 34). You get some odd errors:

Code: Select all

Commands.cpp: In static member function 'static void Commands::emergencyStop()':
Commands.cpp:1423: error: 'DIOHEATER_BED_PIN_WPORT' was not declared in this scope
Commands.cpp:1423: error: 'DIOHEATER_BED_PIN_PIN' was not declared in this scope
Commands.cpp:1423: error: 'DIOHEATER_BED_PIN_WPORT' was not declared in this scope
Commands.cpp:1423: error: 'DIOHEATER_BED_PIN_PIN' was not declared in this scope

Nowhere does DIOHEATER_BED_PIN... appear anywhere in the sources?! I've looked several times. Anyway, I fetched the latest point release .91.7 and it compiles just fine with board type #34. Progress, almost...

Problem 2: I've been having issues connecting to my RAMBo via USB since upgrading to Mac OSX Mavericks. There are so many problems with Mavericks in odd areas. Turns out Apple changed the USB drivers and that is causing all sorts of problems. But there is a published work around.

After disabling the Apple driver and reinstalling the virtual driver, I rebooted. I was able to connect to RAMBo but I almost always could after a reboot so it is too early to tell if it will work long term.

Problem 3: Now with the usbmodem serial port working again, I connected the X3Pro and attempted to upload the firmware... And immediately ran into a timeout problem uploading: avrdude: stk500v2_ReceiveMessage(): timeout A google search turned up a lot of info that this might be caused by sequences of "!!!" (there ! marks) in the source code. Go figure, this sequence was used in the Arduino boot loader to enable the monitor or something. Silly. There is an updated boot loader (this looks like a several year old problem) or you can remove the "!!!". Turns out the Repetier source has quite a few places where the developer gets overly excited and has sequences like "!!!!!!!". So I removed them all and tried again. Things looked a little better, the Tx/Rx LEDs on the X3 flashed quickly for a few seconds then went dim a another timeout error appeared. I found a couple of posts on the Arduino forums about turning on verbose upload logging and checking it for sequences of "!". I did that and found no sequences, just connection failures and time outs.

That's where I am now. I've emailed Roy at Panucatt to see if he has any information. It may be a boot loader problem or a USB hardware issue that Mavericks doesn't like or handle. Tomorrow, when I'm a little calmer, I'm going to set up one of my XT PCs with Arduino and see if I can get things to work on Windows.

I should note that during these issues, I did swap out the X3 with my spare RAMBo and had no problems connecting and uploading the firmware to it. So there is something with the X3 that is an issue, either an actual problem or hardware that Apple is not supporting properly.

All in all, quite a few hours of frustration today. I feel better now writing this down.

Michael

[GeraldO]

Hey mhackney. I use RAMPs on my MAX and forked the SeeMeCNC fork of repetier 0.91. It compiles to RAMPS and I've been using it without fault since.

You can find it here: https://github.com/gjorban/Repetier-091-ROSTOCKMAX

[mhackney]

Thanks GeraldO - I literally did this: downloaded the source from your link, changed the board type from 301 to 33 (RAMPs) and compiled in Arduino 1.0.5 and got the same errors. I've uploaded a screen shot. I then immediately changed to board 301 and it compiles fine.

[mhackney]

The board type in Arduino is "Arduino Mega 2560 or Mega ADK"

[GeraldO]

Oh crap. I forgot that I was working on a branch: https://github.com/gjorban/Repetier-091 ... 91.ramps14

Sorry for the confusion

[mhackney]

Odd that no one has experienced this compile issue on .91 for RAMPS considering how popular it is.

Roy emailed me back and asked that I try the Marlin firmware to eliminate a variable. I did (the latest) and it time-out too. It will be interesting to see if my XP box works tomorrow.

[mhackney]

Anyone can try this - simply set the board type to 34 and compile (DON'T UPLOAD!). I'd be curious to see if this happens to anyone else and/or on Windows.

[GeraldO]

When I made the fix to it, I assumed that it was due to SeeMeCNC's extensive modifications of the UI and possibly some Rambo dependent changes to the firmware. I haven't had the time to actually find the errant commit which causes the compiler error for RAMPS boards though so there's no finger pointing

[bubbasnow]

i see your problem...you have a mac

Problem 2: I've been having issues connecting to my RAMBo via USB since upgrading to Mac OSX Mavericks. There are so many problems with Mavericks in odd areas. Turns out Apple changed the USB drivers and that is causing all sorts of problems. But there is a published work around.

**windows high five**

jk. i don't know how to help

[mhackney]

Yeah, yeah, yeah. But in 30 years I've NEVER had a virus or malware on my Macs whereas my PCs have been a disaster.

Anyway, Roy had me do some tests that led to a discovery!

He wanted me to try the blink sketch. Which I did and it failed. But, I disconnect the USB and restarted Arduino and tried again. This time it worked! I then tried Marlin and it worked. I then tried Repetier .91.7 and it timed out on upload. Long story short - and through a series of tests I discovered that if I either disable the LCD or keep it at the reprapdiscount display and NOT set to the Viki display, Repetier will upload too. Marlin mentions Viki but doesn't appear to have a way to enable it (that I've seen yet). I am not sure why enabling the Viki display should cause an upload time out but it does. Now to figure out what is going on and hopefully fix it.

[mhackney]

GeraldO, as I mentioned, I've searched ALL of the Repetier code and can not find that define: DIOHEATER_BED_PIN...

Interestingly, google it and you'll see one hit: https://github.com/repetier/Repetier-Firmware/issues/94 from 11 months ago.

[mhackney]

Well, it turns out part of this may be an arduino / firmware issue too. I posted my problem on repetier's github and got a response that if the firmware exceeds 128kb bank, the compiler inserts bad code (i.e. "!!!" sequences).

https://github.com/repetier/Repetier-Fi ... t-37719880

[mhackney]

Cool, looks like a fix was found and I just tested the latest as of 1 hr ago and I can upload now. My viki less flashed once and I have no display but that is likely a pin misconfiguration I can chase down.

[mhackney]

Spoke too soon! I just hit the reset button on the X3 Pro and the Viki sprang to life!

[Eaglezsoar]

Spoke too soon! I just hit the reset button on the X3 Pro and the Viki sprang to life!

Was there a particular site you used for the Viki to X3 connections or did you do your usual and figured it out yourself?

[mhackney]

I figured them out from the Viki circuit and X3 Pro circuit diagrams. But I am documenting and photographing it so I can pst here. Right now, the Viki display and menus all work but the SD card is not connected. Roy recommended waiting to get the rest working first. I need to chase down 3 pins on the X3 board to connect it.

[Eaglezsoar]

I figured them out from the Viki circuit and X3 Pro circuit diagrams. But I am documenting and photographing it so I can pst here. Right now, the Viki display and menus all work but the SD card is not connected. Roy recommended waiting to get the rest working first. I need to chase down 3 pins on the X3 board to connect it.

Thanks! You are the Man!

[mhackney]

Now that I am using 2 of the 4 hot ends on RAMBo (with my Kraken) I had to sacrifice my part cooling fan. I also needed to figure out how to mount a fan with the Kraken setup. I have 2 RAMBos and was looking at the spare tonight and noticed that the replacement board they sent me has a new connector labeled FAN 2 right below the hot end connectors at the "top" of the board. You can see it here:

[img]http://reprap.org/mediawiki/images/b/ba ... n-main.jpg[/img]

This is the layout for the RAMB rev 1.2 board but BOTH of my rev 1.1b boards have this connector. If you have it, you can use it to power a fan to cool your PLA and control it from your host with M106 (on) and M107 (off). Here's how:

Firstly, the connector on the board is not marked for (+) and (-) so I had to figure that out. Turns out the left side is (+) the opposite of the hot end connectors above it. Now that you have it plugged into your fan correctly, you need to tweak Repetier firmware. Close to the top of Configuration.h you will see:

Code: Select all

// Override pin definions from pins.h
#define FAN_PIN   2  //4 Extruder 2 uses the default fan output, so move to an other pin

Yours may be commented out and set to the default "4". Simply uncomment, change to 2 (FAN 2 is on digital pin 2 on RAMBo as per: http://reprap.org/wiki/Rambo_development (search for Fan 2). Recompile and upload Repetier and you should be good to go. You can test by connecting from Repetier Host and clicking the Fan on button and controlling the speed with the slider.

So now I have two hot ends AND fan control. (Of course you could use Fan 1 on hot end 1 but where's the fun in that!)

cheers,
Michael

[enggmaug]

I don't get it, if you use HEAT_0 and HEAT_1 for your Extruder 0 and 1, then you still have FAN_0 and FAN_1... to control the pump, and a layer fan.

Do you have a need for more ?

Me, I believe I will use HEAT_0, HEAT_1 and FAN_0 to control 3 hot ends, FAN_1 for the pump and FAN_2 for 2 layer fans.
I will use a protoboard to extend EXTRUDER 2 STEPPER, And I will be good to go with 3 extrudders.

If it works well, I will then make PCB to try adding a 4th Extruder as I described in my other thread.

[mhackney]

No and yes. In my case I am using FAN_0 to control the water pump for the Kraken cooling and FAN_1 to control a "PEEK FAN" when I switch the Kraken over to my E3D or JHead. I don't want to have to swap connectors all the time or put in a splitter since FAN_2 is available. If you don't have a setup like mine, then you are correct that you don't need to use it.