read out height of extruder

edited March 2015 in Repetier-Host
Hi,
Would there be a way to read out the height of the extruder?

Situation: My delta is to big to work with a normal bowden extruder. The delays get to big. I ordered a flex3drive which is a kind of direct drive with a flexible driveshaft. The motorside of the driveshaft is mounted on the side of the printer the other half on the extruder. 
Problem: the shaft has to be as short as possible.
Solution: let the motorside of the driveshaft folow the extruder (vertically) so it stays all the time at the perfect height for the extruder. For that i would need the height of the extruder (or even better, get a drive command for one of the extra steppers :-)

EDIT: This would also be handy for people who wants a floating bowden setup on top of the extruder. In this way they could pull up the bowden setup when the extruder goes up and keep their bowden line as short as possible

Comments

  • That is nothing the host can do. It lags in time so it would not be fast enough. It would need to be done inside firmware but it is also a very complex operation here, so I doubt it would work on 8 bit processors very well. Maybe it is better and easier to mount the motor with some rubber bands between the 3 slides or with a spring loaded spool from the top so it follows but extruder does not need to take full weight.
  • In fact, there is no need for the motor to follow very accurate. It's just that my extruder has vertical travel of 1 meter. But the motor should only follow the extruder within +/-5 cm.
    If the firmware for instance had a variable which hold the height of the printed layer, which would only change on every next layer, i would expect this shouldn't slow down the processor a lot. It could even be a kind of counter which adds for every layer. If i know the thickness of the layer, i could calculate the height myself, and would change the height of the motor only on every new layer. In that way it could even be a variable in the host, because it only changes once for every layer.
  • You forget homing. During homing you move long values in z and even if you want to be insode +/-5cm you would need to update height during the move not every now and then.

    For deltays there are position counters for all 3 columns which are updated in realtime. You could use them and compute an average to define new height avery now and then. Maybe the error would be small enough. Or you extend movement to 6-dimensional moves (X,Y,Z,E, VirtualAxis,ExtruderHeight) in transformation with the 5th motor beeing your extruder height, whcih would be the most accurate solution. It's also quite easy to implement except you have to change dimensions at some places and add control for an additional motor.
  • Indeed, i forgot homing.
    On the other hand maybe it would be better to find a solution which is firmware independant. I could have a kind of rope from the extruder to the top of the printer. On top of the printer would be a wheel (optical rotary encoder?) which guides the rope back down with a counterweight. If the extruder goes up the encoder turns and controls the stepper motor. Would this be easy to implement?
  • How should the extruder go up without using the stepper first. I think there is a logic error. I guess you want a feedback system, but that is not easy and would currently reduce printing speeds very much. But that has nothing to do with extruder heights, so maybe you are thinking about something else I did not understand right.
  • The extruder moves by the normal stepper motors, nothing different there, but from the extruder would be a string going up to the top of the printer, there the string would be guided along a kind of pulley (with a rotary encoder) and go back down on the side of the printer with a counterweight. If the extruder goes up by the normal movement of printing (or homing) the rotary encoder in the pulley would turn around and could directly control the extra stepper for the external extruder motor.

    I am not sure if this is more clear :-)
  • No, not really clear. Why should a extruder need 2 steppers = normal + "extra stepper for the external extruder motor" ? And what do you want to do with the rotary encoder? When I move extruder up/down I know how much and do not need an additional encoder to know the distance.
  • I try to make it more clear:
    The first stepper motor is needed for extruding the filament (the standard one) and the other steppermotor is needed for moving the first stepper motor up and down. This first steppermotor is mounted on the side of the printer  and connected with rhe extruder via a flexible shaft. (flex3drive, mutley3d.com) Because of the height of my printer (z= 1meter) the first steppermotor has to move up and down roughly together with the extruder, otherwise th extruder is moving out of reach of the flexible shaft. This movement has mot to be very accurate, 
    Because you said in your first post it was too hard too calculate the height from the extruder i was looking for another solution and this brought me to the following idea:
    I was thinking to connect a string from the extruder to the top of the delta and guide this string through a pulley on the top  which has a rotary encoder enclosed, this pulley (rotary encoder) would turn everytime the extruder is moving up and down. This signal from the rotary encoder could be used by the second steppermotor to move the first tsepper motor up an down.

     but this motor is mounted on the side of the printer and connected with the head of the deltapr
  • Ok, now I understand. Well thats exactly the solution I said with the 6-dimensional bresenham algorithm adding a extra z axis to the existing col 1-3, e and virtual axis list. That extra dimension will control the z motor moving the extruder up and down. Once you have understood how bresenham and delta transformation work, you see that the implementation is straight forward and only requires medium programming skills (which I hope you have). 

    Main drawback is that DeltaSegment gets 2 bytes longer increasing overall memory usage, so it would be better to use a 32 bit board with more ram if you implement this.
  • Thanks, my programming skills are very rusty and in best case medium :-)
    I will check out the 6 dimensional bresenham algorithm and check if i can understand it.

    I was already in doubt to change my megatronics v2.0 for a 32-bit board, because of the bigger length of the delta arms i can't really reach high fluid speeds.

    After checking around i think the duet is the most flexible board available at this moment (except of the kind of stepperdrivers), but is there already a repetier branch for this board for deltaprinters? (beta?)
  • No duet is not supported. Try RADDS board on a due for 32 bit support. They also offer high resolution steppers. Then you can make use of the 64 bit math whcih is implemented in 32 bit repetier.
  • OK, Checked your suggestion for the RADDS board. This was new for me but it looks very promising. I would go for the UDOO-Quad combination. I googled for it an found some links in combination with Repetier, but none of them really clear.

    As far as i could find out. The Udoo Quad-RADDS combination should work with repetier. Is this assumption true, and have you any idea where i can find more specific info on this combination?
  • Didn't find the Edit button: but found out already. The Udoo Quad-RADDS should work.
  • Yes, it works. But I would prefer running Repetier-Server on the UDOO also I heard host also works. But server can print much bigger files and can remotely used by the next host release.
Sign In or Register to comment.