Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Duet3 Incorporation with Roll2Roll Manufacturing

    Scheduled Pinned Locked Moved
    General Discussion
    3
    10
    569
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Fickertundefined
      Fickert
      last edited by Fickert

      Hi guys,

      So our development engineer has been tasked with adding a dispenser to our Roll2Roll line. Being experienced with hobbiest motion control outside of PLC he asked for my help. (I am not super familiar with PLC, neither is the engineer, so if were barking up the wrong tree please let us know).

      In an essence, we will be adding a dispenser to travel across the Roll2Roll web (web direction will be -X, +X dispenser direction will be -Y, +Y), but we want to be able to link the dispenser speed with the line speed to assure the speed and dispensing rate will be adjusted to speed changes of the Roll2Roll line.

      Our initial thoughts are to use Labview, but he is saying the stepper motor control incorporation is difficult to setup. Additionally I introduced a Duet3 into our large testing Cartesian robot so adding another seems tempting after I showed the ease of use and the quality of the board is.

      Sorry for the rambling. To summarize, does this seem possible? Requirements we have found are:

      • Control a single axis direction with a dispenser (Should work out the same as a CNC motion and spindle speed control for dispensing rate?)
      • Take encoder information from Roll2Roll line, and adapt motion speed and dispensing rate.
      • Expandable to possibly add an axis for a full X,Y direction.

      Any suggestions would be greatly appreciated.

      Thanks

      T3P3Tonyundefined 1 Reply Last reply Reply Quote 1
      • T3P3Tonyundefined
        T3P3Tony administrators @Fickert
        last edited by

        @fickert how is the encoder information from the R2R line provided?

        www.duet3d.com

        Fickertundefined 1 Reply Last reply Reply Quote 0
        • Fickertundefined
          Fickert @T3P3Tony
          last edited by

          @t3p3tony I believe there isn't an encoder on our system as it stands. if it does have one, it is embedded into the PLC system that it runs off of. I assume we'd not want to tap into that.

          So which ever type of aftermarket encoder that is best suited with Duet is ultimately what we'd want to link to the speed and dispensing rate.

          T3P3Tonyundefined o_lampeundefined 2 Replies Last reply Reply Quote 0
          • T3P3Tonyundefined
            T3P3Tony administrators @Fickert
            last edited by

            @fickert I think we need to think about this a bit. To be clear:

            1. The rate of the "X" axis movement is outside the control of the Duet system, but must be monitored by the Duet system (probably via an encoder) in order to synchronise the Y axis and dispenser?
            2. The Y axis is under control of the Duet system and moves relative to some gcode input AND the X axis?
            3. Is the dispenser metered? if so is the Duet controlling the dispensing rate, if so, how?
            4. A potential future expandability where X speed would be depending on both the R2R "X" movement (not under control of the Duet) and a secondary "X" axis under control of the Duet.

            My initial thoughts is this would require a new kinematics as well as supporting the encoder reading. We have a closed loop expansion board that reads an encoder and controls a stepper driver under development however it would need custom firmware to acheive your goals.

            Can you let me know how fast the R2R axis moves and how accurate the dispenser positioning would need to be (so we can get an idea of the encoder requirements).

            www.duet3d.com

            Fickertundefined 1 Reply Last reply Reply Quote 1
            • o_lampeundefined
              o_lampe @Fickert
              last edited by o_lampe

              @fickert
              A workaround could be to use a simple microcontroller to read in the encoder signals and send step/dir signals directly to the Y-motor and dispenser drivers based on the encoder information.
              I've developed a similar thing, when I prototyped a DC motor controller, that works like a stepper driver. The program runs on a ATtiny44. (much cheaper than a Duet3, but no fancy web-based adjustment)

              1 Reply Last reply Reply Quote 0
              • Fickertundefined
                Fickert @T3P3Tony
                last edited by Fickert

                @t3p3tony I apologize for the delay.

                To answer your questions:

                1. Exactly

                2. Sort of, we prefer the Duet to completely manipulate the gcode it has been given by using the encoder sensor to as closed loop feedback for the x-axis. The Duet in theory will always have the X-axis in motion (or the way we want to manipulate it to see) since the R2R line is continuous.
                  My thought was the gantry can travel to Y0 (home) and Set X0 with a command before starting the operation. Then it would just be a rinse and repeat operation. A better comparison is to how the belt style 3D printers operate, just not at a 45 degree angle.

                3. The dispenser for the time being I believe is pretty crude, in that its all manual adjustments. Talking with the development engineer, the speeds of the line will vary, but by small margins and as of now it wouldn't be that big of an effect. If dispensing volume and flow become of concern, we will upgrade to a newer system.

                4. Yes but this is not the important aspect as of now, but something to keep in mind.

                I should clarify, if looking directly down on the R2R web in a 2D space, the Y-axis will be at an angle to the web direction, not perpendicular. This kinematic setup is a setup we have used previously in testing with manual control, we're simply trying to put a controller on it and manipulate it via a program. If you have suggestions for this as well I am all ears.

                As for firmware, would it not be possible to remap inputs as necessary? Or do you mean in regards to the kinematics being unique?

                Encoder = Duet "X-axis"
                Y-axis = Duet Y-axis
                Dispenser Flow Rate = Duet Extruder Flow Rate (use stepper driver input as Dispenser input?)

                T3P3Tonyundefined 1 Reply Last reply Reply Quote 0
                • T3P3Tonyundefined
                  T3P3Tony administrators @Fickert
                  last edited by

                  @Fickert

                  Thanks for clarifying. The point here is that this is not a closed loop system on X as the controller (the duet) is not in control of that axis. It is a unique kinematics implementation in my view because RRF will need to modify the movement of the Y motor, based on the input from the X encoder. If it did not do that then any variations in X speed would lead to the Y "line" not being straight.

                  Its not necessarily complex, just not something that we have implemented up until this point.

                  For the dispenser, is the dispense rate controlled by a stepper motor or something else?

                  www.duet3d.com

                  o_lampeundefined Fickertundefined 2 Replies Last reply Reply Quote 0
                  • o_lampeundefined
                    o_lampe @T3P3Tony
                    last edited by

                    @t3p3tony If they'd pretend that the encoder represents closed loop signals of the Y-axis, they only have to invert the counter measures => More pulses from the encoder increase Y speed instead of lowering

                    That"ll work when X-motion and Y-motion have fixed ratio.

                    Fickertundefined 1 Reply Last reply Reply Quote 0
                    • Fickertundefined
                      Fickert @T3P3Tony
                      last edited by

                      @t3p3tony said in Duet3 Incorporation with Roll2Roll Manufacturing:

                      @Fickert

                      Thanks for clarifying. The point here is that this is not a closed loop system on X as the controller (the duet) is not in control of that axis. It is a unique kinematics implementation in my view because RRF will need to modify the movement of the Y motor, based on the input from the X encoder. If it did not do that then any variations in X speed would lead to the Y "line" not being straight.

                      Its not necessarily complex, just not something that we have implemented up until this point.

                      For the dispenser, is the dispense rate controlled by a stepper motor or something else?

                      Tony,

                      Thanks for keeping tabs on this. Yes the kinematics are definitely not "traditional", but yes the Y-axis will need to be manipulated in respect to the X-axis position (which will be in a continuous direction).

                      As for the dispenser, it is currently using compressed air, and a few basic dials on a controller. Once we have the kinematic part of the system in place, we can look further for absolute control of the dispenser. This output would more than likely be controlled similar to a cnc spindle or laser than an extruder. But using a stepper for dispensing control isn't out of questions currently.

                      1 Reply Last reply Reply Quote 0
                      • Fickertundefined
                        Fickert @o_lampe
                        last edited by

                        @o_lampe said in Duet3 Incorporation with Roll2Roll Manufacturing:

                        @t3p3tony If they'd pretend that the encoder represents closed loop signals of the Y-axis, they only have to invert the counter measures => More pulses from the encoder increase Y speed instead of lowering

                        That"ll work when X-motion and Y-motion have fixed ratio.

                        Thats what sparked this idea, but hoping we could gain more freedom than having the ratios between the two axis similar, or fixed.

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA