Search Results for 'robox head'

[Omega64Participant]

@gid you wrote << It’s not actually the Z-axis force that I’m worried about… the Z axis sensor (or Z+? I get the two confused… the one that senses head tilt) prevents any issue there. >>

Not so. For example, raise the head well up, then issue a G28Z command. While it goes down, if you break contact (Z- Probe) then it will stop and home there (Z=0 becomes ~that point). All right so far.
Now repeat everything, i.e. make it home correctly to the bed, then raise the head well up. This time, instead of issuing a G28Z command, issue a G0Z0 one. It will start a new trip to the bed, just like before, but with G0 instead of G28. Now you will notice that if you break contact, the Robox will continue to travel downwards and won’t stop till Z=0, which is potentially very dangerous. Hence my suggestion to @chrisyt to fix this in the firmware (the only place where it can be done correctly).

Regarding the other point you made, X is quite torquey so you should never load the probe laterally. Simply do it from above, i.e. raise Z safely, place at next X/Y coordinate, lower Z till contact, then raise it again safely before reaching next X/Y point.
Slow? Sure. But safe, too.

Have a nice day,
Fabio

[gidParticipant]

It’s not actually the Z-axis force that I’m worried about… the Z axis sensor (or Z+? I get the two confused… the one that senses head tilt) prevents any issue there.

My worry is that of lateral forces on the head. For scanning to work with an object with deviations that are more than gradual, the head needs to be fitted with a long probe. I made a quick fitting to plug an inch-long bolt to the head. First thing that happened, the printer tried to home, and ripped off the probe.

Fortunately I’d made the adaptor weak enough for it to just come straight off. No damage done to the Robox, bed or head, but it could have gone the other way. It made me wonder about things like the effect on the head of twisting around the Y axis if the probe is butted on the X axis: the long probe would increase the torque, and I just don’t want to push the limits of my Robox at this time. It was an interesting idea, but I’ll leave it to someone else to develop.

@click : this is what I was trying with your rbx tools on last week Once I finally got the Java side working, the problem of how to deal with the return information arose, so I just ended up writing a quick script in Node.js instead: the asynchronous model makes it a natural fit for serial comms, and writing the gridding loop was trivial.

Tom Gidden -- Bristol, UK -- New Roboxer? Check out the wiki, and add yourself to the map! http://roboxing.com/user_locations

[Omega64Participant]

Make sure the main connector and the pins on the gantry make good contact. Look at here:

https://robox.freshdesk.com/support/solutions/articles/1000089433-n-a-showing-for-current-nozzle-temperature-or-head-unknown-

[Omega64Participant]

You can’t damage the nozzle/head by forcing it down a lot: you’ll rather damage the carriage, Z axis and so on.

And you can’t even damage it by homing via repeated G28 Z, as the Robox will stop pushing downwards (during a Z homing operation) when it senses the loss of contact on the upper X bar.

The only way to fool it would be to place something (unexpected, i.e. after G28 Z) on the bed, or by raising the dangerous G92 command to fool the Robox and permit it to go “underground”.

So a lot of care should be used in these 2 situations. You could easily map a bed by first issuing G39 to clear the autoleveling data then by accumulating M113 results after X/Y positioning and G28Z, at worst you lose 0.001mm precision each time, which is not too bad. The other technique (to save that 0.001mm’s) would be to use G92 to gain a couple of mm’s underground, and then sense the Z probe, but it would be darn slow via PC (due to latency in “go down on Z, sense the Z probe, and loop again”), this technique would be much faster if it was a firmware function.

But you ain’t going to have to worry about the head or nozzle, as the Z axis don’t have enough force to damage those, it’s much more likely that they have it to damage themselves or the PEI bed or whatever.

I would like to advice @chrisyt to modify the firmware so that if the loss of contact on the upper carriage is unexpectedly sensed (i.e. not only during a Z homing operation) it should stop pushing Z downwards. It’s far from unneeded or a fancy feature for users that want to Z map a bed: it may happen for example that an user is printing something, then he stops it (or it stops by itself due to an error), and the user by mistake commands AutoMaker to go Z down by 10mm. That will destroy the printed part and, if solid enough, put a lot of stress on the mechanics.
Instead if the firmware was modified to react to unexpected loss of contact on the upper X bar (Z probe), it would avoid to push against a colliding object. You should NOT recalibrate (i.e. re-home) Z on such events, just don’t push down if the Z probe says you should not, because something unexpected got under the head.

Kind regards,
Fabio

[hexmanParticipant]

Thanks @bhudson, These were ABS using Cura, I expect that Slic3r would be even more of a mess. I’ve been using ABS exclusively since I got the Robox and I’m confident there is no PLA in the head.

The first layer is still a concern, a solid surface should print as a solid surface regardless if it affects the print. The separation between the perimeter walls is also an issue as it seriously weakens the prints. Even at this state where there’s insufficient extrusion the printer still makes a mess of small detailed items where it appears to over-extrude and sometimes eventually knock these detailed parts over.

This issue for me seems to come and go, I suspect it’s a hardware. The last time I’ve had this problem I ended up removing the extruder for a clean - it ended up not needing one, but after replacement i got a few hours of solid prints, but than back to insufficient extrusion.

Now if i could only got some reply from support or the local distributor for my support tickets…

[gidParticipant]

I was thinking about this today, as I was toying with the idea of using Robox to “scan” an existing custom shoe insole, so I can print one per pair, rather than the ~£200 for new ones.

The idea being to use the Z-delta capability: Robox would be sent “G28 X Y Z” to return to home to get an origin location; moved to the scan point (“G0 X100 Y80 Z100″); Z-homed (“G28 Z”) which drops the head until it contacts the bed or something else (ie. the insole); then “M113″ to display the Z-delta, ie. the difference in height between the G28 commands. The script itself is simple.

I got it working in principle, but the geometry of the Robox head vs. the insole and the fact that I don’t want to prang the mechanics accidentally has stopped me from trying. Instead, I’ve ordered a contour gauge and some metal rulers, and am going to survey the insole manually by taking a contour at each point of a grid, taking a picture / flatbed scan of the gauge; do some image analysis to extract the contour; and then reconstruct it as a point cloud to 3D print.

Anyway, the Robox Z-Scanning idea above should work pretty well for surveying the bed. It should be able to sense the relative height between two points on the bed at sub-millimetre accuracy.

Tom Gidden -- Bristol, UK -- New Roboxer? Check out the wiki, and add yourself to the map! http://roboxing.com/user_locations

[BHudsonParticipant]

@jgarrett a dial indicator is an instrument used to measure the difference between two points of a surface: http://en.wikipedia.org/wiki/Indicator_%28distance_amplifying_instrument%29

They are usually readily available on eBay for around 50.00 and can be had more cheaply if you know where to look. You can probably borrow one from a local machine shop . They may actually be interested in watching you use it. If you decide to go that route, I will post the STL file for the mount I designed to fit the Robox. The allowable deflection in the bed is .025 inches, or about .635mm. If you are careful and find a good precise ruler, you can measure by hand also, just make sure you are measuring from the same reference point for all the measurements. Record the position of each measurement and the measurement to get a profile of your bed. That will tell you if the bed is out of tolerance.

My beds don’t have any give relative to the base plate of the Robox. They are solid and don’t move. Check that there are not debris under the bed somewhere.

If the head is going down farther in the corners that indicates the corners are lower than the center. This is expected as the manufacturing process causes the edges and corners of the bed to be slightly lower than the center. CEL is working on that but for now have not figured out a solution.

I am not affiliated with CEL; I operate two Betas and one Production Robox.

[BHudsonParticipant]

@jgarrett That is the problem that the 9-point bed survey is supposed to address. I would try something: Make sure that the bed is seated well in its clips. I have found that if the PEI sheet is not pulled tightly against the bed, it will cause this type of issue. I had the problem with one of the clips sticking up too high. I found that when I pushed on the PEI, it would move a little. That was enough to defeat the bed survey. I was able to adjust my clip by taking the bed out and pushing down on the top of the clip.

If the PEI is tight to the bed, I would get a dial indicator and print out the mount that I designed to h0ld it and do a survey of the bed without the PEI installed. That will tell you if the bed is hugely out of true. I suspect that it is probably a loose clip.

I did find one other problem - watch the head and gantry when the Robox is doing its level sensing. The spring on one of my heads was too stiff and it was not activating the head limit switch at the right time. I removed the spring and it seemed to help quite a lot. When doing the sensing, the gantry should move no more than 1mm more than the head before the contact on the head is pulled off the top bar and activates the limit switch.

I am not affiliated with CEL; I operate two Betas and one Production Robox.

On just about everything I print on my commercial blue Robox the outer printed wall does not adhere to what appears to be the wall of the inner fill material. It doesn’t matter if it is my own design from Sketchup or a free stl download. The wall thickness is ~0.3mm and there is a ~0.1mm gap between that and the fill irrespective of the fill density.

The bottom of any printed object is usually pretty smooth but the top layers usually form a mesh of 0.3mm filaments. It is not a solid plane: am I expecting too much?

When I print a brim, and I usually do print a 3mm brim, the brim lines do not amalgamate into one piece.

I’m printing Chroma Green ABS. I’ve calibrated the head height a few times with little difference (apart from the gouge in the PEI). It’s currently 0.4 for the 0.3 nozzle and 0.37 for the 0.8.

Print head ceased

Look at the crap inside the head - NO WONDER!

 

It jammed the motor. I had to cut it all away; what a nightmare.

I am about to create a new full time position in my company; “Robox Supervisor” (may need 2 assistants).

So what is my alternative seeing as it is going to clog up again… get a replacement head, again?

Attachments:

You must be logged in to view attached files.

[SeveranceParticipant]

Nice to hear.

I too chose the Robox after a lot of research into design and capability. I apparently have a new print head due in in Monday, and hope it resolves things.

It’s a great design, it just needs work on the support end. A lot of work.

Since my last printhead was leaking I got a replacement from CEL and finally I got some time to use my Robox again.
But unfortunetaly I don’t have much luck :-(. The results are really bad!
(see attached images). I printed using the original Robox filament PLA orange. My Automaker Version is 1.01.01. I used the Cura slicer and draft settings. The only thing I changed is infill 100% to make sure to get a solid printed part.
The printer still makes this fast tock, tock, tock, tock, tock noise almost all the time. Often under extruseion happens, there are gaps in the perimeter. The paths of perimeter often do not touch so there is a gap. Also the the infill looks wierd. It is irregular. The paths of infill also do not touch each other so there is not 100% infill, it looks like 80%.
Please take a look at the bottom of the picture now. There you can see another printed object. But he top layer is neither smooth nor closed clean surface.During the print often (5 times or more) the ‘Slipping detection’ message comes up!

These are my current problems:

1. Fast tock, tock, tock noise
2. Underextrusion
3. Bad perimeter and bad infill
4. Slipping problem

Is there any hope that I can fix this?

• This topic was modified 2 weeks, 6 days ago by  René.

Attachments:

You must be logged in to view attached files.