Smoothie M2

[jimc]

ok i got my misumi slide today and installed it. i did a quick print of a hex with holes in each flat side before i changed it and after i ran the same exact gcode file. was the ringing improved...yes. did it make a massive difference...no. it did help print quality. i would say all the ringing marks are still there, just the depth of them was reduced. there is more improvement in the x axis. i would say overall it it was improved maybe 25%. everything helps i guess and totals up in the end. if thats worth the 90 bucks or not that is up to you. if your looking to replace one of your slides anyway then i would say order it. the part # i listed is a drop in replacement. took 10 min to swap out.

[innkeeper]

thanks Jim, good to know they seem to be higher quality replacements.
I'll probably give the other style a try at some point. just not ultra high on my list of things to do at the moment.
unless I happen to fall into a deal on them someplace that I cant pass up

[jsc]

I'm quite interested to see if the new breed of motion control firmwares is going to make a difference, namely the "constant jerk" (or better) http://reprap.org/wiki/Firmware/Linear_Acceleration. The only problem is, nobody has made it easy enough (for me) to use for 3D printers. I'm surprised.

I'm aware of TinyG, which has been making noise about supporting 3D printers for some time now but nobody's done it. And the BeagleBone T-Bone cape, which uses dedicated Trinamic motion controller chips, which seems like a good idea, but there has been zero information available since they got their campaign funded.

[jimc]

yeah i would say that it really shouldnt be on anyone's priority list as its a minimal improvement. i should also note that my machine has thousands of hours on it too but over that time the play in the slide never increased. i think most of these slides can handle as many miles as a good car tire. the play you get in the z stage components is so minimal its not funny but there are so many components that it adds up a little i guess. both my older printers had equal play if you grabbed the 2 front corners of the bed and slightly moved side to side. now the one i changed the slide on is way tighter. no doubt about it. still a touch of play but prob 75% of that is gone.

[Tim]

I'm quite interested to see if the new breed of motion control firmwares is going to make a difference, namely the "constant jerk" (or better) http://reprap.org/wiki/Firmware/Linear_Acceleration. The only problem is, nobody has made it easy enough (for me) to use for 3D printers. I'm surprised.

I'm well versed on that code as I am currently involved in my own project to port something like that to the Smoothie board.

The main problem with it is that it involves a lot of computation per step, and may be overload for the poor RAMBo. It was looking to be overload for the Smoothie, and that runs a lot faster than the RAMBo (the Smoothie's processor is a 100MHz ARM Cortex).

My pet project is to do better than "constant jerk" by implementing a cosine velocity curve. Theoretically, the cosine curve is infinitely differentiable. In practice, the cosine has to be approximated, so whether it can be as good as, or better than, constant jerk or linear pop remains to be seen. In my first implementation, it had serious bugs, and I have not been able to figure out how to connect the Smoothieboard into a gdb debugger. It's supposed to be possible, and is a huge benefit for the Smoothieboard, that you can single-step the firmware from a host computer. . . if you can figure out how. Meanwhile I have other projects getting in the way, so it may be a while before I get back to it. Anyway, that's how things stand.

Also it remains to be seen just how much you can reduce vibration by this method. Any time the firmware underestimates the amount of deceleration needed to change direction, it's going to cause shaking. And there are various ad-hoc methods in the firmware to determine how much to slow down. But if it's just a matter of deceleration, then I think that there would be some acceleration value below which all the rippling artifacts would go away. But it appears that with the current firmwares, the ripples remain no matter how much you slow things down (although they get a lot better, but they never disappear); that's my evidence that the discontinuous acceleration is the primary cause of the ripple.

[innkeeper]

I have not been able to figure out how to connect the Smoothieboard into a gdb debugger.

you have to connect though the uart not usb... see http://smoothieware.org/mri-debugging

[Tim]

you have to connect though the uart not usb... see http://smoothieware.org/mri-debugging

Yes, I'm aware of that. The UART is a lot more painful to communicate with than the USB. I don't have a serial port on my desktop, so I used a USB-to-serial cable and plugged the relevant signals (Tx, Rx, and Gnd) into the serial header on the Smoothieboard with jumper wires. Then I tried talking to the board through a terminal program, but all I get is non-ASCII data back. This looks like what you get with a baud rate mismatch, but I've tried every possibly relevant baud rate and I get more or less the same behavior. I'm a bit suspicious of the USB-to-serial cable, because the driver controls the signaling and I don't have as much low-level control over it as I would have on a simple serial port.

Have you tried communicating through the UART?

[innkeeper]

.Have you tried communicating through the UART?

[/quote]

yes, using an old usb mini 03 - if you remember those - its basically and ftdi chip ttl 5v out.
i have it set it for com5.

you dont need rts/cts , set flow control to none. make sure the baud rate in the config matches your terminal program and you should be all set to test it using a terminal program.

if you set it for 9600 you can see more of the startup as its the defualt until it reads the baud rate line.
if your using a terminal program, know it doens't echo. but you sould be able to see it boot up.

on my chinese knockoff board, rx and tx are exchanged. so watch out in case rx is tx.

all i have connected is rx, tx and gnd.

[innkeeper]

Tim, how did you make out?

[Tim]

Tim, how did you make out?

I was on vacation most of this week, followed by moving my household next week. So don't hold your breath. It is likely to be a few more weeks before I get around to looking at it again. But from your description, it sounds like I was doing everything right. I had once or twice tried reversing Tx and Rx, but while one way receives unidentifiable data, the other way does nothing, so I figured the Rx and Tx lines were most likely correct when I was getting some data through. More likely an issue with what the USB cable is doing, although I was using an FTDI-chip based cable, and setting it up under Linux for raw mode, no TXON/TXOFF, etc.

Mostly these things just get discouraging when there is no evidence that it has ever been done before. You have given me that evidence, if I can just get the stars aligned right.