Concept: h.ORD

[canadianavenger]

A while ago a discussion came up about an H belt configuration on the Ord bot. Life got in the way and I unfortunately never got around to finishing the design. I finally found some time to get it past the last few hurdles to what should be a fairly workable initial concept.

Generally the design is the same as the original ORD bot. I've used the Quantum as the base of the design. The makerslide extrusions are all the same length as the Quantum, but I lengthened the Misumi section to 300mm, however as the steppers are no longer in an outrigger configuration, the overall width of the unit is still slightly thinner than the Quantum. This was done to maintain the same build size, the original length can be kept with a reduction in build area to about 100mm wide. I also did away with the different carriage plate, and reused the same plate I use on the Z rails, to minimize number of unique components [though some sort of bracket will need to be made to mount the extruder head]. I also modified the idler bracket to offset the roller so that one side will produce a straight belt path between the stepper gear and the idler. I also managed to lower the profile for the wheels, resulting in everything being a little tighter against the rails now. I don't plan on building this version myself, due to a lack of funds. However, if anyone wants further details, I'll be happy to pass them along. On the next pass I plan on making some more significant changes/refinements, while staying as true to the minimalist design as possible.

Here are some renderings I made of the design as it stands now... Introducing the Quantum H

[edit] Just noticed that the X rail is off to one side by 5mm, this is an error, I forgot to adjust it when I lengthened the Misumi rail. Just imagine that it is actually 5mm more to the left

[cybertech99]

I love the concept and design but the wiring seems like it may get tricky. I see that if both motors turn they lift and lower the carriage. If only one moves it can make it move on the x axis, but the other motor would be nothing but friction on the belt. Also can the stepper driver handle the voltage and amps the other axis driver would send during the opposing movement. I would test all the wiring before investing in the build.

[bdring]

The motors/driver/wiring should handle it just fine.

There are some control issues. You will need to modify the controller code quite a bit. Many H-Bot people simply rotate the work 45 degrees, but that is not really an option for X and Z. If there are no moves in X and Z at the same time, you might be able to do some logic or boolean hack to get it to work.

The other issue is the Z will fall if power is turned off. Many people disable the z motors at each layer. You will have to leave them on.

[cybertech99]

If you wire both motors to x and z drivers and just reverse the polarity of one of the z motors wouldn't that take care of it.
I havn't seen any g-code that moves z and x at the same time so I don't think that would be a issue.

[bdring]

wire both motors to x and z drivers

You can not do that.

If the G-code says go to some location and both X and Z are not at that location, it will do coordinated motion. With printing you will probably only see that at the beginning or end of a job. You might be able to tweak the job so that does not happen.

[butterfingers]

Given that in this configuration gravity is an inconvenient overhead, have you considered having the H sliders move the bed rather than the gantry? Then all the gantry has to to is move up and down.

[canadianavenger]

I see that if both motors turn they lift and lower the carriage. If only one moves it can make it move on the x axis, but the other motor would be nothing but friction on the belt.

Actually for control, of both motors turn in the same direction, you get X movement only, if both motors turn in opposite directions you get Z movement only. If you turn only one motor you get a combination X-Z movement, but at half the X & Z travel per step, thus you need two pulses to equal the distance travelled [per axis] in a single axis movement.

Here is a table for the movements, for the above design:
Cardinal:

Code: Select all

            Left    Right
            Step    Step
Right (X+)  CW      CW
Left  (X-)  CCW     CCW
Up    (Z+)  CCW     CW
Down  (Z-)  CW      CCW


The combined/secondary movements can be derived from the above table. If the rotations coincide for the two desired directions, that motor is turned, when they contradict, that motor is stationary.

Code: Select all

            Left    Right
            Step    Step
UR (X+Z+)   --      CW
DR (X+Z-)   CW      --
DL (X-Z-)   --      CCW
UL (X-Z+)   CCW     --


This configuration will require modified firmware, but certainly any two axis/channels of the driver can be used to run it. Alternatively it "may" be possible to pre-process the g-code to convert X & Z movements from the CAM processor into A & B controls, mapped onto the X & Z channels. The result will be pretty ugly G code, but may be sufficient to test the hardware.

[canadianavenger]

Given that in this configuration gravity is an inconvenient overhead, have you considered having the H sliders move the bed rather than the gantry? Then all the gantry has to to is move up and down.

I considered that, but wanted to stay true to the original ORD Bot configuration. Gravity is not really a problem while the unit is powered, only when unpowered.

[canadianavenger]

There are some control issues. You will need to modify the controller code quite a bit. Many H-Bot people simply rotate the work 45 degrees, but that is not really an option for X and Z. If there are no moves in X and Z at the same time, you might be able to do some logic or boolean hack to get it to work.

The other issue is the Z will fall if power is turned off. Many people disable the z motors at each layer. You will have to leave them on.

Yeah new controller code is required, as there are no X & Z motors, they are virtualized, and replaced by A & B. The un-powered problem between layers is a non issue, as there is no Z motor to turn on & off . [but certainly the gantry will drop when power is turned off, my plan is to add some rests to allow for the gantry to be "parked" when turned off]

[canadianavenger]

Is there a preferred firmware people are using with their ORD Bots? If there's a preferred firmware I'll concentrate on modding that.

I took a look at one, and the modifications for the trivial case of cardinal movements only would be easy. Dual axis moves would be more difficult.

I'm hoping someone has he time/resources/energy to try to make it. I wish I could do it myself, but at the moment my budget is trashed as I'm going through a separation.