jhinkle

I thought I had the solution by going back and releasing all of locks on the belts --- but that did not work. This whole axis alignment is under the premise that the two rods coming out of the extruder are at 90 degrees. I saw no adjustments to make sure the rods are exactly at 90. If they are off --- I would be experiencing the issue I have. I've checked the extruder box and all appears well there. Any ideas on how to move one of the rods in the extruder by a sub-angle amount? Thanks. Joe

Movement of the extruder is tight. I associated that with the resistance associated with the stepper motors. I can (with some effort) move the extruder to all corners of the printer. I believe all is as you suggested. The first pic two pics show the difference in alignment. Third is shot from front to back, forth is back to front. The right slider block does not want to move forward or backward. Moving the front and back moving blocks do not helps as they appear to be locked into position and not able to move relative to one another also. Comments/help -- all welcome. First Thanks. Joe

Thank you. I found the tool and its a lot better than 3B. My issue is I set the screw on the Back left pulley. Move the extruder to expose the set screw on the Back right pulley. Position left tool to set left position --- right side is now off. All pully screws except the Back left are loose BUT the system is VERY tight. It is very difficult to move the right sliding block to align it with the tool. Can you comment/ explain what might be done to loosen things up to be able to permit alignment. Thanks. Joe

I feel really stupid because the directions makes no sense to me and there is nothing posted in the forums. So it looks like I'm the only one not understanding. The assembly instructions say to use wood part 3D as a gauge between frame and the sliding block. If I measure Left and Right sliding block to frame at the BACK - there is an difference of about 1/16 inch. If I set the distance Back Left and then force Right back to be the same size (makes the extruder left/right axis parallel to back frame. Set both set screws (left/right on back axis) -- move extruder to the FRONT and measure gaps --- expecting to find no difference --- now I have about 1/8 difference. So --- I'm have a brain fart in that I just don't understand the directions and the theory being used to square the axis. Any help would appreciated. Thanks in advance. Joe

I've designed my own Stepper Driver board -- in layout now -- boards to be produced in a couple of weeks. My stepper driver AND control board is totally different from what David is doing. My stepper driver will be able to drive up to 256 micro-steps per motor's full step (compared to 16 in today's UM1 design). Timing analysis shows 256 micro-steps well with the system processing capabilities. My plan is to drive all 4 steppers at 256 micro-steps. From a control perspective -- I have implemented the stepper control process totally different from that used in Marlin. I will NOT have audio - Maybe USB drive. Control of the printer will be over a Network interface (internal Web Server). I'm hoping to have things in place by the summer. I will then run some print comparisons ... UM1 as delivered vs UM1 with my upgraded control system. Joe

I posted what I was doing in the "Alternatives" forum. Here's my post --- see the end. http://umforum.ultimaker.com/index.php?/topic/4048-is-there-a-need-for-a-100mhz-32bit-arm-controller/ Did NOT say they were Going --- I take their efforts as just good advanced R&D. Joe

My statement was flawed so I removed it ... Joe

One of my upgrades I am looking at, once I replace my controller, is to put some filament positioning feedback sensor in place. Feedback will allow me to see if the filament is moving or just grinding - but the feedback requires more controller resources --- hence my new controller. I already have an idea for the sensor -- just need the additional controller capability to manage it. Joe

I'm just trying to get an understanding of the UM1. Knowing how it works - where the strengths and weaknesses are will enable me to properly tune the machine and quickly start producing quality prints. It will also point out areas where I can play in the future --- in an attempt to better my machine --- the whole reason I purchased the UM1 over another machine. Joe

The actual length is not important -- I was a showing real-life example from the robot gcode file. Longer length beads still show the number of extruder steps to be about 20% of the steps in the longest axis. I understand that the flow of plastic will tend to smooth things out --- but if finer control was available --- it could only improve the result. Joe

I made another observation that I would like to confirm. From the config file: #define DEFAULT_AXIS_STEPS_PER_UNIT {78.7402,78.7402,200.0*8/3,760*1.1} // default steps per unit for Ultimaker This states that the step/mm associated with the extruder is 760 * 1.1 = 836 steps/mm. Flip that for .0011961 mm/step. When I look at a gcode segments for the "robot" that comes with the UM1 -- I see that the number of E steps is about 20% of those steps associated with the X or Y axis (whichever one has the most steps for that segment that has the most steps). Here are a couple of examples: line 149 ----ESteps 11.971534 Xsteps 60 E/X = 0.1995 line 608 --- ESteps 2.349161 Xsteps 11 E/X = 0.2136 That provides what I consider coarse control over the extruder This is a strong reason to move from 2.85mm filament to 1.75mm filament. Gcode line 149 above - the length of filament associated with that segment was .01432 mm The controller is expected to deposit that length of filament over the 60 steps of the X stepper. The volume of a cylinder = Pie*R*R*height. That means the volume of plastic in .01432 of 2.85mm filament is .0913532 cubic mm. That same volume of plastic using a 1.75mm filament gives a length of .03798mm. Given today's controller, the Extruder stepper would make 32 steps --- that is almost 3 times the number of stepper steps to control the flow at the print head's nozzle. Any comments of this observation are welcome. Joe

gr5: Thanks -- that helped. Joe

It was just a feeling. THAT is where my ignorance starts -- that relative magnitude. Once I can control the process, I will have a better feeling for the magnitudes --- Thanks for you input. Just your comment inferring that 20mm/sec jerk compared to a nozzle velocity of 30mm/sec is valuable feedback. Thank you again and I'm sorry if any of my questions were irritating in any way. Thanks to all for your insight and replies. Joe

Thank you. I had the correct understanding of what jerk is and when its applied. I was only commenting on the magnitude. Thank you again. I should be all set for now. Time to actually build the controller and test its performance compared to Marlin. Thanks again for everyone's replies. Joe

Just to clarify ... I must have looked like an idiot in my earlier post stating nozzle velocities in the 200 to 300 range. The UM1 specification clearly states print speeds 30 - 300mm/sec. Many of the posts I've read are talking about hi-end print speeds. The reason I asked the question ... 'how Fxxxx feedrate in the gcode would affect anything I'm doing.' ... was when I looked at Cura feed rates and compared those to what people are talking about --- there turns out to be a magnitude of 10 difference --- hence a sanity check. Also take in the "Marlin" (correct fishy spelling this time) - default JERK is 20mm/sec (most of the time they divide that by 2 --- so 10 - 20 mm/sec jerk is huge compared to printing at 30mm/sec. I am now comfortable with the magnitudes of the numbers which reassures my understanding of the system. Thanks again for your replies. Joe

Thank you -- that was a great reply providing exactly the information I was looking for. Joe

Thank you for your concern. The question I had was if the feed rate given by the gcode was 1200 for the "robot" model and that is in mm/minute which is converted to 20mm/sec segment velocity when passed to the planner --- that is a far cry away from the 300mm/sec I hear everyone talking about making prints on the UM1. If the "robot" print is to be printed at a max nozzle velocity of 20mm/sec -- that's fine as I'm just attempting to understand what the F gcode parameter is and confirm my understanding. Thanks. Joe

illuminari: The F parameter in the gcode is for FeedRate --- correct? I peaked in the Merlin source code to try to get an understanding of its use. It appears (please clarify) that the parameter is passed in the F argument is mm/minute. I say this because it is divided by 6o when passed to the planner --- making it mm/sec in the planner. When I look at F values in the gcode --- I see F1200 and F1620 being used when associated with G1 codes. This would be passed to the planner as 20mm/sec and 27mm/sec --- used as feed_rate in the planner. This is why I don't like to attempt to use/reverse engineer someones code because if you don't have a solid foundation in what they are doing ... understanding is difficult. The planner uses that value to derive segment time -- from there velocity values and rate value related to the segment. All of that then gets rolled into the trapezoid calculation ...... I'm asking because I don't see or understand the importance of this feed rate gcode value. So far - I have been ignoring it ... but I want to do a sanity check. Currently - what I do ... I don't need a feed_rate. I need a maximum nozzle velocity defined and a value for the constant acceleration. From those, I can calculate time and speed anywhere in the nozzle's path - always having the system attempting to accelerate and maintain maximum nozzle velocity. Given the view point I just explained --- I having an issue understanding how Fxxxx feedrate in the gcode would affect anything I'm doing. I may be missing something -- so please clarify. Thanks in advance for your reply. Joe

Question regarding Cura ... Cura generates gcode segments that defines a bead length. I'm assuming that Cura has decided the volume of material that is to be deposited in the creation of the bead and states that volume via the E gcode parameter. E length of 2.85mm filament equates to a specific volume of material to deposit as the bead. The controller's job is to be aware of the mechanical system and attempt to deposit THAT volume of material in the distance defined in the segment. THAT is what Cura is defining as the E parameter - correct? Thanks. Joe

Thank you for your comments. I totally understand and those are true for the control system implemented today in the Merlin. In the testing I've done so far (simulation - not actual hardware yet) - I've set max nozzle velocity at 300mm/sec. The process I have currently implemented (using 3000 mm/sec/sec acceleration) has the majority of nozzle speed around 200mm/sec with 10% peaks to 300. Move acceleration to 6000mm/sec/sec bring everything up to average around 250mm/sec with 20% peaks maxing at 300. When my UM is build and my controller can swap out the Ardunio, I'll do tests to see if my implementation has similar limits as Merlin. I appreciate you comments and concerns. Any statement or concern may be a fact that I'm not aware of that may dramatically change my direction. You don't know what you don't know. Again. Thanks for your comments. Joe

I an old EE. Actually had several classes on design using vacuum tubes --- that date's me! I understand the use of jerk. I use a recursive approach when I find a gcode segment that needs its starting or ending nozzle velocity to be zero or near zero (jerk). The "forced" results are recursively fed back into previously processed segments. the idea is the same as Merlin's forward and reverse planner but totally different. I want to do physical testing to see if I can get the wanted speed without much jerk as jerk produces artifacts in the print. I'm currently using the robot gcode that came with the UM1. In processing that gcode, I have had instances where I went back as far as 18 segments to smooth out the segment velocity transitions. That is what will be nice with the ARM I'm using - I will have memory for a very large segment buffer to be able to do recursive smoothing as the print is actively being printed. I'm also counting on the hardware floating point processor to keep performance up even with all the heavy floating point calculations I'm doing. I've got my embedded Ethernet TCP/IP stack as part of this. I want enough headroom to easily maintain network communications for control and debugging. When you retire - you have the opportunity to take the skills others use to pay you for and apply them aggressively towards a hobby. I'm looking forward to both using and modifying my UM1. Joe

Thanks for your response. The plot is not time on the Horz axis but gcode segments. Time is not shown. I was interested in visualizing nozzle velocity at the start of each segment and at the end of the segment and how they would smoothly move from one segment to the next. Acceleration is there - you just don't see it -- If only showing the start and ending nozzle velocity of each gcode segment. I am purposely not looking at the Merlin code. I find for me, going through the creation process allows me to do some out-of-the-box things. I'm hoping my work here will result is something as good or better. There are a lot of articles on real-time stepper systems -- most all quote the work of David Austin. They all speak to the trapezoid profile. They are interesting and insightful when working with a single stepper. Controlling a 3D print head involves 3 steppers - as you stated - tightly coupled. Currently I am controlling the X and Y steppers with the focus on nozzle velocity - not stepper axis speed. Nozzle velocity (as you stated for turning corners, etc) is critical. You have to manage acceleration and de-acceleration of both X and Y steppers to smooth nozzle movement. I've tested both 1/16 micro-step and 1/32 micro-step steppers. The results so far suggest it's a toss up if 1/32 will actually provide a noticeable result. 1/32 does provide for smoother operations because of the finer granularity --- but --- we'll see. Currently I'm using constant acceleration and limiting nozzle speed to a maximum velocity - 300mm/per to 550mm/sec. I tested accelerations from 3000mm/sec/sec to 9000mm/sec/sec. I was hoping the manufacturer would specify max acceleration rates but they don't. Hardware testing will provide me that. In pondering the extruder, I had a thought as to why the UM continues to stay with a 2.85mm filament instead of 1.75mm that tends to be more available here where I am (in the States). It has to do what you mentioned - pressure. For a given drive force on the filament, a 2.85mm filament will produce more pressure in the melting chamber than a 1.75mm because of the increased surface area. Depending on the volume of the heating chamber - this may be both good and bad. My current extruder system models the velocity profile of the nozzle - not the X/Y steppers - and attempts to move the amount of plastic specified in the gcode along the nozzle path taking into account nozzle velocity, melting chamber volume, nozzle opening, and head temperature --- hopefully producing a constant bead size., I know this has all been done before --- there is a good controller in the UM1 kit I just purchased. It seems the the Ardunio solution has been around awhile --- but everyone is using the same core. I'm hoping that by taking a fresh, non-Ardunio, approach --- I might just end up with something better. I very much appreciate your technical comments. Joe

My current direction, for beta, is to have the board connector level equivalent with the Arduino so I can interface with the existing controller board. It will provide a much faster cpu (120 mhz), 32bit hardware floating point, USB, ethernet, SD card. I'm developing the firmware now so the system control and user interface will be all brand new -- nothing like the current UM1 implementation. I've got the X/Y stepper subsystem pretty much done - now working on integrating the extruder control. Once done -- I'll test print quality by simple driving the UM with the Arduino or my board and make comparisons. Joe

Another questions for those technical users .... Besides building and tuning my new UM1 kit (just received), I decided to make my own controller board. I will simply swap out the Arduino board with my own design. Looking at the GCODE - the Extruder is simply told to push a specific amount filament during the duration of the GCODE segment. I've done some testing and plotted the print head velocity from start of segment to end of segment and then from one segment to the next. The print head velocity is the actual nozzle velocity derived from movements along both X and Y stepper sub-systems. See pics attached: Each vertical line is a GCODE segment with the line length being the start and ending nozzle velocity. The grid lines show nozzle velocity at 100mm/sec, 200mm/sec, and 300mm/sec. I'm in the process of developing the driver for my extruder stepper and hence where my question arises. How well does your existing system lay a bead as the print head moves? If the extrusion is not managed to track nozzle velocity, you can have a think bead when nozzle velocity is slow and a thinner bead when the nozzle is moving at at higher speeds. Any comments about your bead quality is appreciated. Thanks. Joe The plot if from the first layer of printing the robot that comes as an example with the UM1.

My question keeps going back to print quality. I agree that .005 is very small and having that obtainable step resolution my be in the mud of the hardware resolution. But .... when you step a stepper motor you actually induce an oscillation and error term into the mechanical displacement. Think no micro-stepping --- just cogging the motor at its rated angular rate of 1.8 deg per step. THAT would produce noticeable artifacts in the print. Print a straight line ... you will see the jogs. By decreasing the micro-step size - less energy is required because less of a distance has to be covered so the artifacts associated with that error term will decrease. So -- stepping at .005mm or .0025mm per step may still have a measurable resolution of .01 --- but the print surface may be noticeably smoother. Just looking for comments. Thanks Joe