Upgrading to ARM and 0.9 Steppers - Vertical Banding Issue

[mhackney]

Show off! Seriously, rub it in to those of us ARM-challenged!

That looks super fantastic!

(and oddly erotic)

[Maco]

Xnaron super nice print, have a question how is the simplify3d software? it really helps? it wortht to have it?

[xnaron]

Show off! Seriously, rub it in to those of us ARM-challenged!

That looks super fantastic!

(and oddly erotic)

Very funny as usual lol

[xnaron]

Xnaron super nice print, have a question how is the simplify3d software? it really helps? it wortht to have it?

Thanks. Yes I really like Simplifiy3d. I wanted a go-forward slicing path as KISS seems to be abandoned by its developer. KISS was my go to slicer and Simplify3d has quickly replaced it. It can do everything KISS can and so much more. For me it was well worth the money. I went in to it very skeptically. I was not impressed that they didn't have a demo. I even emailed them asking for one and was politely told no. I figured that if I bought it and it was complete crap I would fight for a refund. Happily I don't have to worry about that hassle.

[xnaron]

Here are some important things to know about the ramps-fd in case anyone is considering it.

I have that this one http://www.ebay.com/itm/281246436199" onclick="window.open(this.href);return false;. It works well but it is the first beta of the board. Unfortunately it is the only version out in the wild. It has some safety issues with the way the mosfet circuit is designed. If the arduino were to fail it is possible that the mosfet could switch a heater on. Other than that risk the board is working very well for me. Others have complained that the QA isn't very good with the boards and some have had issues with them.

Here are some important things to know. The arduino due does not have an eeprom. So in order to store the settings you need to add a $3 eeprom chip that connects to the i2c connector on the board. Wiring the eeprom to the board is really simple. The other thing to keep in mind is that the arduino due is 3.3v and not 5v. This means that the lcd and encoder won't work out of the box. You will need to add a board with level converters on it. I don't have it hooked up on min. The designer of ramps-fd made a design for an adapter board. I don't see anyone making it though. The design is all open source and you could send it to a pcb fab place to get the board made. You'll need to populate the components on it and some of them are SMD. They could be hand soldered but it might be a bit tricky.

Anyhow other than the above stuff it is working fine for me. There is another board out there called the RADDS. I have one coming to me. It may be better and have all the eeprom and lcd level converters built in. I need to take a closer look at it when it arrives.

The other thing you'll want to get is the drv8825 from polulu http://www.pololu.com/product/2133" onclick="window.open(this.href);return false; They will allow you to step at 1/32.

[lordbinky]

I really didn't need to read over this thread. I already had .9 steppers in transit right now, and a smoothieboard waiting for me to put in the connectors. I have new extrusions to install on the max, my stock ones are now less than straight which is completely my fault, but the new ones are black to match the rest of the rostock . Now I just have to complete the 3 other projects I have currently to bring these upgrades to the top of the queue. *sigh* One of these day though! One of these days....

[thenewguy]

Does anyone have the max working with the smoothieboard yet? I don't know much like if our current software will run with a few setting changes.

I still have the old Rambo with 1/8th stepping so I need this upgrade soon.

[xnaron]

Here is a video on the second driver shield I am testing called the RADDS (Reprap Arduino Due Driver Shield)

http://youtu.be/VKYRT1vvErc" onclick="window.open(this.href);return false;

[lordbinky]

Smoothieboard firmware is actually really easy to convert over too. I don't like the non-locking connections that they send with it though. Blew a driver because of that. You don't have the EEprom menu change settings on, but they give you G-code commands to change all the variables you want, then commands to dump your current settings, and there's a drag and drop config file I edit with Notepad++ after I'm done playing with settings in real-time. You can also set up a terminal session to interface with the board that way if that's your cup-O-tea to change settings with that.

As for being a drop in replacement, if you go with the stock connectors, unless you used some flexible wires for your power on the order of high strand silicone test lead wire, it's a very tight fit with a bend radii that would make an NEC acolyte faint. From what I understand, the Azteeg X5 has a smaller footprint that would fit better within the Rostock. Don't know if the standoff holes would align though.

[critical_limit]

Hi all,

having this banding issue as well, I decided to go the 0.9° road with a smoothieboard /azteeg X5. Magnetic ballarms are nearly finished and ready to install. Everything is upgraded to 24V as well. Removed the astrosyn dampers as well.
I installed 0.9° Stepper motors to my RM2 last night. Now waiting for my Azteeg X5. The Rambo is far too slow for that. Had stuttering movements above 30mm/sec.

Anybody here who installed a 0.9° stepper to the extruder as well? Or doesnt it make any sense? Should the extruder also with 1/32 microstepping? Or better to install 0.9° and use ½ step? What are you using?

thanx
Dirk

[Generic Default]

I'm just wondering, why did you take the dampers off when installing 0.9 steppers?

Also, you may want to consider switching to larger NEMA 23 steppers with 400 steps/rev for direct drive if you want to print your own cold end. You will have to modify the hobbed drive or get one with a different shaft size though.

[critical_limit]

I'm just wondering, why did you take the dampers off when installing 0.9 steppers?

Because I have much better prints without. I experienced that weeks ago with my old setup. Deinstalled the dampers and sharp corners and banding got better. Especially on higher print speeds the dampers add backlash to your drive system. Not much, but you can see it on the prints.

But back to the extruder motor. Anyone installed 0.9 steppers on the extruder?

cheers
Dirk

[teoman]

I am completely failing to see why the internal controller of the printer is burdened with the kinematics of the machine. I mean why would it receive references in X,Y,Z coordinate system and then work its ass of trying to calculate the inverse kinematics (calculations for: i want the nozzle to be at XYZ at what step count should my motors be) to generate position references for the motors?

There would be cases with other machines where this would be vital however with the rostock and stepper motors there is absolutely 0 feedback. All motors are just blindly following a predefined reference with zero chance of making and decision on that reference. The motors are stepper motors, you fire the signals to them and you have no way of knowing if they have moved or not. So why is the reference more complicated than it should be?

And the delta printer differs from cartesian printers here. The math to do the inverse kinematics on a delta are much more complicated.

If i had time and energy at the moment, i would try doing one of the following:

1- pre process the gcode on the computer. So you are sending the printer commands such as: Motor1 move 200, motor 2 move 300, motor3 move 250 and it follows them. If it is on a desktop or even laptop computer the whole sequence would not take more than a couple of seconds, and you could achieve maximum precision the mechanics would allow. This may involve a lot of dicking around on the computer and partially porting the rambo/repeiter code to the computer environment to obtain those results.

2- Since the rambo already does these computations, AND it has an sd card for storage. Get the rambo to first do the kinematics calculations as it would normally would but at maximum precision and instead of sending the generated position references to the motors it writes them to the sd card. Once it has finished, it still waits a few more minutes for the bed etc to heat up . Then when the print starts, it reads the preprocessed data from the file it just generated on the sd card.

can the Gcode for repetier accept commands for each motor?

[Polygonhell]

If i had time and energy at the moment, i would try doing one of the following:

1- pre process the gcode on the computer. So you are sending the printer commands such as: Motor1 move 200, motor 2 move 300, motor3 move 250 and it follows them. If it is on a desktop or even laptop computer the whole sequence would not take more than a couple of seconds, and you could achieve maximum precision the mechanics would allow. This may involve a lot of dicking around on the computer and partially porting the rambo/repeiter code to the computer environment to obtain those results.

2- Since the rambo already does these computations, AND it has an sd card for storage. Get the rambo to first do the kinematics calculations as it would normally would but at maximum precision and instead of sending the generated position references to the motors it writes them to the sd card. Once it has finished, it still waits a few more minutes for the bed etc to heat up . Then when the print starts, it reads the preprocessed data from the file it just generated on the sd card.

can the Gcode for repetier accept commands for each motor?

The first idea is how ALL of the original delta and SCARA printers were developed, it's much easier than modifying firmware. The issue with it is for any degree of accuracy the output is extremely verbose and the USB connection to the arduino combined with the tiny command buffer results in constant pausing when trying to print over USB.

The second idea doesn't work because if you assume that the kinematics are a substantial part of the time spent running the print, then you would have to wait at least that amount of time before the print could start.

Doing the kinematics on the controller has other advantages, it means that you don't have to know the kinematics of the machine when you generate the GCode.

Personally I think the mistake all of the firmware makes is using GCode to encode movement in the first place, I understand taking an existing standard.
There were a couple of possible options that I think were better .
The firmware could have been entirely trivial if direction and step pulses were calculated by the host, compressed and consumed by the arduino. I vaguely remember that this is what NopHeads firmware does.
The other better alternative IMO would have been to have the motion codes reference a printer specific configuration block, so the file could have been trivially passed between printers and "tweaked" after being sliced.

Delta kinematics aren't all that complicated, I don't happen to like the current approach of subdividing the paths into linear sections, but it's by far the simplest way to go, and it does asymptotically become equivalent to my solution. The fundamental movement of the delta carriages is quadratic, and I think the controller should deal with that directly as a part of motion control, i.e. instead of todays Bresnhams line step at the core of the motion control, use a 2nd order version. But it's not simple to implement and it's very delta specific.

[teoman]

It may be slow, but if it will make a significant improvement to your build then there are some here that would be all for it.