24V M2 updated VIKI Firmware

[Curtis Menard]

All,

I forked Jin's Marlin firmware and have been using it and modifying it since I purchased my printer. There have been a number of questions about which firmware to use so I thought I'd put mine out here.

Features:
* M108 is removed and replaced by automatic control of the extruder/electronics 40mm fans based on extruder temperature. Currently the 40mm fans will turn on/off at 35C.
* Full VIKI LCD with microSD card support.
* "MakerGear M2" will be displayed in VIKI as the printer name.
* I'm using a 24v 50mm fan and the firmware is currently configured for that. **NOTE** If you still have the 12v 50mm fan you will need to edit the Configuration.h and change line 623 to //#define M2_24v_50mm_Fan. This will run the fan at a max setting of 155 and a default speed of 127 if just an M106 command is issued. **NOTE**
* M106 will turn the 50mm fan on and M107 will turn it off. You can still send M106 Sxx to change the fan speed or even M106 S0 to turn it off.

In the Arduino IDE if you get a compilation error looking for LiquidTWI2, go to Sketch/Import Library/Add Library and browse within the downloaded firmware to Marlin\ArduinoAddons\Arduino_1.x.x\libraries\LiquidTWI2 and add the library. The firmware should compile and flash to the RAMBo without further error.

Link:
https://github.com/cmenard/Marlin/archive/MakerGearM2.zip

Thanks,
Curtis

[Jin Choi]

Nice. I'm glad someone is getting use out of the (minimal) effort I put in to porting the configuration. I recommend anyone looking for a full featured up to date Marlin for the M2 use Curtis' fork.

Curtis, you should probably pull updates from Erik Zalm's branch rather than mine, as I may be making non-generally-useful updates in the future.

I'm interested in seeing if it would be possible to use the firmware itself as a job time estimator, as any estimator that doesn't run the exact same motion planner will be off.

[WayneN]

Woohoo! Thanks Curtis, I can't wait to try it.  I'm using a 24v 40mm bed fan and I've been having a lot of problems getting it to turn automatically during prints. 

I'm planning on putting ball bearing 24v fans on my extruder and on the rambo board as well.  Can you advise what I would need to change when that time comes?

Thanks again for your work

[WayneN]

Curtis,

Looking over your firmware, I notice it has the same missing lines at the original VIKI firmware:

In Configuration.h, there are settings for the stepper motors voltage.  I have changed mine in the past to cool down the Z motor.

Without these lines in firmware, are we running a full amp to each motor?

here is the code:

// Motor Current setting (Only functional when motor current pins are connected to digipot)

// Values 0-255

// RAMBO 135 = ~0.75A, 185 = ~1A

#define DIGIPOT_MOTOR_CURRENT

#define X_CURRENT 135

#define Y_CURRENT 135

#define Z_CURRENT 135

#define E0_CURRENT 165 //For MakerGear M2, 185 is a good starting point (~1A)

#define E1_CURRENT 125

[Curtis Menard]

It's not missing, just moved.  Search the Configuration_adv.h for DIGIPOT_MOTOR_CURRENT.  You'll see that the same current settings are there.

Sent from my Nexus 5

--
You received this message because you are subscribed to the Google Groups "MakerGear - Make Today, Change Tomorrow" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makergear+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[WayneN]

[WayneN]

Ah, I see.  Thanks, I was worried about overpowering my steppers.

 

Do you have a M106 command in your startup script?

 

I'm still not getting my bed fan to turn on automatically.

Thanks again 

[Curtis Menard]

My bed fan (50mm) only comes on when directed to in the gcode. It's off with ABS and on full speed after the first layer with PLA. Those are done via the Cooling settings within Creator.

Can you start the fan with the slider in creator? Or by sending a M106 S255?

[WayneN]

Yep, the fan starts fine with M106 and with the slider so I'm sure its something in coding.

I did install a 24v 40mm fan to replace the 12v bed fan, and its a little larger (20mm thick) than the standard 10mm fans.

 

I can also start it fine by using VIKI and setting the fan speed to 255, so I guess the problem is in the gcode.

[Jin Choi]

Search the gcode for M106 and see what it says.

[Curtis Menard]

I merged in the latest upstream changes from Erik Zalm's branch. Though I haven't spent much time looking into it yet, the new bed level compensation has me truly intrigued. Here's a Youtube video provided in the Marlin README. http://www.youtube.com/watch?v=x8eqSQNAyro

There has been much updated with this and I plan to try a servo activated mechanism similar.

[Jin Choi]

Have you played with the Matt Roberts accelerated printing experimental option? I turned it on and fiddled with it, but couldn't get it to work well for me. Plus, it sounded like it was doing violence to my extruder gear.

[Curtis Menard]

Did you change line 338 of Configuration_adv.h #define STEPS_MM_E 836 to 471.5? I would think that if too many steps/mm for the extruder were defined it would sound pretty crazy.

[Tony Shulthise]

That video is inspiring.  I've never really pursued auto-leveling because I thought that hysteresis in the z axis would cause more problems than the auto-leveling solved.  I'm still skeptical because many machines will probably have too much hysteresis but this video is inspiring.  

I wonder how his machine would do if he tried printing 0.1 layers?...

Do you know which output he uses to control the actuator to pull the z switch up and down?  What type of actuator does he use?

[Jin Choi]

No, I sort of glossed over that... That would explain the crazy noises it was making. I'm going to try it again.

[Tony Shulthise]

Looking at the video again it looks like he just used a hobby servo to actuate the switch.  Are there PWM outputs on RAMBo that could be used to easily control hobby servos?  No more than the switch weighs, a micro servo would be all that's needed to actuate the switch.  Like either of these (rotary or linear).  You could also just use the linear type without PWM by sending it a 1 second pulse for each direction.  Hummmm....

[Jin Choi]

On Sunday, March 16, 2014 4:14:55 PM UTC-4, Tony Shulthise wrote:

 Are there PWM outputs on RAMBo that could be used to easily control hobby servos?

There is the unused HEATER1 pin, which I am currently using to control my LEDs through PWM. You must disable it as a heater pin before you can use it for anything else. Also, when dual extruders arrive you will have to make a choice.

[Curtis Menard]

What about adding the pins to MX EXT or there's also PWM EXT.  I would think that either could run a servo.

Sent from my Nexus 5

--

[Curtis Menard]

For those that like to try new stuff, this firmware package has the ability to enable firmware driven retraction settings. I've been using it and so far it works pretty well. Until the slicers start using the new G10 and G11 for retraction and recovery, the firmware is predicting events based on gcode from the slicer. Using the LCD to make retraction settings changes during a print comes in handy. Currently it's disabled by default. Putting M209 S1 in the S3D start up script will get it going.

New gcodes:

// G10 - retract filament according to settings of M207
// G11 - retract recover filament according to settings of M208
// M207 - set retract length S[positive mm] F[feedrate mm/min] Z[additional zlift/hop], stays in mm regardless of M200 setting
// M208 - set recover=unretract length S[positive mm surplus to the M207 S*] F[feedrate mm/sec]
// M209 - S<1=true/0=false> enable automatic retract detect if the slicer did not support G10/11: every normal extrude-only move will be classified as retract depending on the direction.

Here's the notes from my git commit:

Firmware retraction can now be enabled via the Retraction LCD menu. It
can also be enabled by issuing a M209 S1 command. To disable issue M209
S0.

I've corrected the LCD display issue and the feed rates are now in
mm/sec with a maximum value of 100 mm/sec.

For this feature to work your slicer must have retraction enabled and
some value for the amount of retraction. When the firmware sees a
retraction event from the slicer the settings will be replaced with
those in the firmware.

On the fly changes to retraction can be made via the LCD. They can also
be changed with gcode as below:

M207 - set retract length S[positive mm] F[feedrate mm/sec] Z[additional
zlift/hop]
M208 - set retract recover length S[positive mm surplus to the M207 S*]
F[feedrate mm/sec]

[Ed Nisley]

> Until the slicers start using the new G10 and G11 for retraction and recovery

In ordinary CNC usage (i.e., everybody other than RepRap 3D printers), G10 is already used to set tool offsets, either from a tool table entry or directly from the G-Code. RepRap uses G10 to set coordinate origins and, more recently, the offset between extruders.

The table I pulled together a year ago may be helpful to avoid collisions, but it's not a complete list of all the CNC dialects out there.

Recycling G10 for retraction probably won't end well...

[Curtis Menard]

I've updated the firmware again to fix the SD card detection upon insert and removal. Also made the button below the sd card function.

You will however need to move two wires on the board for this work properly. The pin moves are so that other LCD's wouldn't need changes in the firmware to function with Rambo. Trying to keep things inline with upstream Marlin changes.

Differing from MakerGear's instructions:
Yellow wire from EXT2 pin 15 should land on EXT2 pin 14. Black wire
from EXT2 pin 13 should land on EXT2 pin 20.

The latest version can be grabbed from here:
https://github.com/cmenard/Marlin/archive/MakerGearM2.zip

[Dale Reed]

Curtis,

I did a git clone of your firmware repository to my local hard drive on Wednesday (-ish).  I was having trouble compiling -- an error about an LCD related header file being missing...  and since I don't have the Viki LCD, I just commented out the main #define for the LCD.

After installing my 24v fans (and a couple trios of LEDs in series, paralleled with the extruder fan, and  after some testing today with the 24 volt fans I bought, I changed the temperature limit for starting the fan to 5 deg (so it always runs) and enabled the soft PWM and set the output to 220 (out of 255), which I found is a nice value for the fan I'm using so it doesn't sound like it's taking off, but flows enough air to keep things cool.  So far so good.

Ran the autotune on the PID temperature control for the extruder.  Numbers look similar to the ones you have in Configuration.h --- makes sense.  Mine are Kp=27.38, Ki=2.11, Kd=88.82.  The extruder temperature trend chart's looking pretty sweet.  So I typed my numbers into Configuration.h to make them the defaults (flash, not just EEPROM).  Noice.

So now I'm trying the autotune on the bed temperature.  I got the bed most of the way up to temp so it doesn't time out.  Then it cycled a couple times.  I get the message "PID Autotune finished! ......" but NO VALUES for Kp, Ki or Kd are reported!!!

I noticed that the #deffine for PIDTEMPBED is commented out.  Is that something you haven't played with, or did you try it and have some issues?  (Anyone else tried building the M2 firmware with #define PIDTEMPBED enabled?)   If nobody's found a good reason not to try it, I'm going to give it a whirl and see what I get.

Now, as regards the fans:

I have the HP3245A at work for fan testing.  I'm going to take some other test gear in over the weekend and run the fans through their paces.  In testing the 12 volt fans today (using the 3245 but no voltmeter to check), they didn't seem to run particularly fast, even with (assumed) 12 volts applied.  Nice think with the 3245 is I can select square wave, amplitude, voltage offset (so I make the amplitude 12 volts and the offset 6 volts so it goes from 0 to 12, not -6 to +6), frequency (from millihertz up to 100 kHz) and DUTY (PWM %) directly on the keyboard, any where from 5 to 95%.  Yay!  So I'll be going in over the weekend to run a bunch of fans through their paces.    I ran some preliminary tests on the 24 volt ball bearing fans I bought on Amazon, and when PWMed at 120 Hz, I can reliably run the fan from 25% duty to 95% duty (and, of course, on DC) and get nice smooth speed change over the range.  I printed a new fan bracket so I can use two of the 40mm fans, and the bracket is deep enough to stick on two 3-LED strips (in series).  The few fan bracket is two screws on the extruder fan and two screws on the bed fan, and I cut the angle to 40 degrees instead of 45 --- definitely no running into the binder clips for the bed.

SO.....   photos and details to follow!

Curtis: Many thanks for your work on the firmware.  I'll probably have to track my changes and then roll in your latest.  Wanted you to know about the LCD header file glitch -- probably, though, it was just that you had saved at an intermediate point when I grabbed it, instead of a "final".    (I haven't checked my SD card to see if it works -- I've been printing from USB just fine.)

Dale

On Wednesday, March 19, 2014 10:07:40 PM UTC-4, Curtis Menard wrote:

For those that like to try new stuff, this firmware package has.....t

[Jin Choi]

I am running with PIDTEMPBED enabled. It is fine.

[Curtis Menard]

That's good stuff Dale!

To fix the compile error you can do the following:

In the Arduino IDE if you get a compilation error looking for LiquidTWI2, go to Sketch/Import Library/Add Library and browse within the downloaded firmware to Marlin\ArduinoAddons\Arduino_1.x.x\libraries\LiquidTWI2 and add the library. The firmware should compile and flash to the RAMBo without further error.

At this point your SDCard reader is probably not going to work. You'll need to uncomment line 492 in Configuration.h like this <b>#define SDSUPPORT</b> to enable it again.

[Dale Reed]

Got it.  Thanks!

BTW, I enabled PIDTEMPBED and started the autotune of the bed temperature with it fairly warm.  When I went to start a print, it took "FOREVER" to come up --- I may just go back to non-PID (bang-bang) control for the bed.  But good to know how.  Based on that first attempt, I doubled the integral gain and tried it and it worked much better.

For everyone else's information:  You surely don't need FIVE significant figures on the tuning constants!  You can tweak these things by doubling / halving --- that's how we do the initial tuning of industrial control loops.  Per the math, taking a loop that is limit oscillating on proportional control (critical gain around the loop) and halving the proportional gain of the controller will take you to quarter-amplitude damping (gives overshoot, but the errors cancel out, if you're worried about integrated error instead of momentary error.  Dividing that proportional gain by 3 gives you "Lambda tuning" -- which takes longer to get to setpoint, but guarantees no overshoot (which is just exactly what you want for the extruder temperature!).

We're talking factors of 2 or 3 here, not a few percent.  If the autotune gives you an integral gain of 2.30 and it's too slow to get to setpoint, 2.40 won't be noticeably faster.  Try multiplying it by 1.5 or 2!  If it gets to unstable oscillation, take the proportional gain from 28.34 down to 14, not 25 or 26.  Autotune gives you "exact" numbers based on the floating point math, but they're based on a temperature from a 10- or 12-bit A/D conversion at best.  If you run the autotune again, you'll get similar, but different numbers because of a number of factors -- air flow in the room might affect it negligibly --- the primary difference would be what temperature you started from.   Start the autotune with the bed and extruder fairly close to ambient and tune to the temperatures you usually run -- like 220 C for the extruder and 70 C for the bed for my black PLA.  Starting at ambient lets the autotune see the overshoot on the initial ramp up -- especially for the extruder -- and account for it.  For the bed, you may have to pre-heat some just so the autotune doesn't time out.  (It only allows some number of minutes to get to setpoint on the initial ramp up.)

That was the long story.  Sorry to bore you.

   The short story:  Thanks, Jin!  Thanks, Curtis!

Dale

[Jamie Frost]

Just wanted to post my thanks for the work on the custom firmware! 

Works like a charm, does what I need it to; The rambo having a very cryptic pinout is difficult to figure out how to rewire the sd pins but now I have that figured out it's a blast!  Just need to tweak my z-motor torque (keeps slipping and dropping down while trying to move upward) up a bit.

Thanks again!
[virtual beer]

[WayneN]

Thanks again for your work.

I'm having trouble (even after reading your post on adding the library, and uncommenting line 492) getting the sd card reader in my VIKI to work with this firmware.

Anyone else having this problem?

[WayneN]

Got it- I wasn't getting a good connection on black pin 20.

Another question though- how can I slow down the extrusion speed in VIKI?  Its too fast for filament changes without pausing.

[WayneN]

On Sunday, March 30, 2014 8:12:06 AM UTC-4, WayneN wrote:

Got it- I wasn't getting a good connection on black pin 20.

Another question though- how can I slow down the extrusion speed in VIKI?  Its too fast for filament changes without pausing.

UPDATE* With this new firmware the VIKI manual extrusion is actualy very SLOW now- where can that be changed?

Thanks 

[WayneN]

NM- I found the setting.  Line 240 in configuration_adv.h  Was set to 60mm/min, I'm using 280mm/min.  300 should be about perfect for changing filament using manual VIKI controls. 

[John Barnhardt]

Curtis, is there any particular reason why "#define TEMP_STAT_LEDS" is commented out in Configuration.h by default? I'd like to enable this unless there's some reason not to. Thanks very much for your work on this firmware.

-John

[John Barnhardt]

Curtis, et al - I got your Marlin fork installed last night. It works great in my initial testing (at least once I remembered to comment out the Viki support since I haven't hooked my Viki up yet) with one small odd behavior. See the attached screen shot from Repetier-Host. It appears to be reporting temps for a phantom 2nd extruder or something along those lines. Any thoughts on how to eliminate the extraneous data? I don't think it's a Repetier setting that is causing this, but I could be wrong. I will re-verify all my printer setup info in RH tonight but thought I'd toss this out in case anyone has suggestions. Thanks,

-John

[Jin Choi]

I think if you set HEATER_1_PIN and TEMP_1_PIN to -1 in pins.h lines 2005/2006, that should go away. As I recall, those pin definitions are used even if EXTRUDERS is set to 1.

Remember you did that when you get a dual extruder.

[Tony Shulthise]

Curtis...

Having some issues.  I posted details here...http://forum.makergear.com/viewtopic.php?f=3&t=42

Any help appreciated.

I'm trying to wean off of this forum and keep discussions over there if possible.

Thanks,

T