Duet3 Incorporation with Roll2Roll Manufacturing
Fickert last edited by Fickert
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.
@fickert how is the encoder information from the R2R line provided?
Fickert 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.
@fickert I think we need to think about this a bit. To be clear:
- 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?
- The Y axis is under control of the Duet system and moves relative to some gcode input AND the X axis?
- Is the dispenser metered? if so is the Duet controlling the dispensing rate, if so, how?
- 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).
o_lampe last edited by o_lampe
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)
Fickert last edited by Fickert
@t3p3tony I apologize for the delay.
To answer your questions:
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.
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.
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?)
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?
o_lampe 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.