Layer shift detection?
-
Have not used a MarkForged machine, but I believe Stratasys has a similar system used with their Dimension (and would assume uPrint) line of printers. During a print (specifically with model material and support material) the machine can detect a layer shift (or more specifically any unexpected print head movement) during the material/nozzle switch. The print head travels to one end of the Y axis to toggle the nozzle switch mechanism, where there is also an optical endstop. If it detects a shift, it kills the print and throws an error.
-
YIKES.
"Dislocations" = skipped steps.
I do realize that things can happen... blobs, collisions, prints not sticking to the bed... and detecting those might (MIGHT) have some merit. It turns out to be really challenging to actually do that. For example, Stall detect covers only true "jams", and will almost never find anything more subtle. If the print pops off the bed and the head pushes off the edge, and the nozzle is printing on air, it is going to be very difficult to sense that.
Given many, many, scenarios like that, IMHO, a human taking a glance at the printer every hour or so, via direct or camera, covers a LOT of ground that auto sense does not.
Other than the few things that are major, and therefore quite often not recoverable... The entire concept of compensating for skipped steps, instead of chasing down the reason for the skips and resolving them is, to use a precision engineering term, icky poo.
-
Also, the 'real' way to do this is closed loop...
-
@Danal I think the "real" way is to use what you have and not what you don't. We do have endstops, and we don't have closed loop drivers.
The difference between using a closed loop driver and using the endstops to check for layer shifting is, at most, a single layer worth of time and material, plus extended print time due to rehoming at every layer. Precise endstops are much cheaper than closed loop drivers - the optical endstops I used cost $10 for three of them, and normal printer configuration sets them up. When closed loop drivers are that cheap and easy, that will definitely be the way to go because it won't extend the print time.
Neither re-homing nor a closed loop driver will detect a print coming off the bed, unless it somehow jams the X or Y mechanism and causes a shift. Rehoming will detect shifting caused by bad configuration (excessive acceleration or jerk) or caused by a warped print interfering with the motion of the mechanism.
I don't have problems with layer shifting in my prints from any cause, but there certainly are a lot of people who do. I also don't have problems with prints coming off the bed, but a lot of people go to the trouble and expense of adding extra motors and drivers to auto tram the bed so that prints will remain stuck (though I suspect many don't realize why they're doing it).
Maybe using the endstops to detect layer shifting is too simple and cheap?
-
I'm a little surprised by your conclusion. Many of your posts, including most of this one, seem to say "get things physically right, don't paper inaccuracies over with software". Homing between each layer is a particularly egregious example of papering over.
-
@Danal I don't think it's "papering over" anything. It's simply stopping the waste of time and material on shifted prints. It's still up to the operator to correct the problem that caused the shift, whether it's poor configuration or a warped print (change temperatures, use some glue on the bed, etc.). The Venn diagram of well built machines and experienced operators contains a pretty small overlapping area. A well built printer and experienced operator don't need autotramming or shifted print detection. Autotramming and shifted print detection are for everyone else.
The shifted print detection would also detect shifts caused by loose belts or other electrical or mechanical failures.
-
Not my field of expertise but I'd have thought that a Piezo attached to the hot end mount should detect a collision and forewarn of an impending layer shift, without the hassle of re-homing every layer. Maybe those with smart effectors or Piezo Z probes could employ that to detect knocks or bumps during a print?
Edit . That won't work is the cause is loose belts - only if the nozzle collides with the printed part.
-
Doing some math: if re-homing adds 20 seconds to a print layer, and there are 5 layers per mm, that's 100 seconds per mm of print height. A 150 mm tall print would have 4 hours and 10 minutes added to the print time due to the re-homing. Of course, you could rehome every 10th layer, which would give a more reasonable increase in print time, but I dunno... probably not worth the extra time added to each and every print.
-
People
wasteadd more time to their prints for things like time lapse videos that move the print head out of the way, so I don't think the time aspect is really an issue. If it was reliable enough to detect some failures and save you the mess, potential hotend damage, or material wastage ($$$, PEEK, etc), it could definitely be worthwhile. I can see why markforged would add it, their carbon inlay materials are not cheap. -
A stepper motor like this one could detect missed stepper steps. It has a rotation encoder with 1000 counts per revolution and could detect an angle mismatch between actual and expected.
Edit: a printer with a stepper like this could not only detect but also correct for missed stepper steps.
-
@zapta You need a matching driver that can do something with the encoder output.
Endstops need to be there anyway and are dirt cheap.
-
@mrehorstdmd, yes, that's correct. I wonder what are the use cases for those steppers with rotational encoders.
-
@Phaedrux When I saw the demo I thought they seemed to be printing pretty slowly, too- it looked like it topped out at maybe 50 mm/sec. Maybe for industrial customers, print quality and reliability of the process are worth the extra time. Their materials certainly aren't cheap either. I hadn't considered something like PEEK. You would definitely want to stop a print if a layer shifted with that stuff.
-
@zapta A closed loop motor/system wouldn't be able correct for all errors. If a print warps and stands up and blocks the nozzle, a closed loop system is going to try to force the nozzle to the correct position. That could cause problems.
I think a closed loop stepper is best used in a system where an object has to move to a target location, like maybe a pick and place machine, as opposed to something that is moving continuously along a specific path.
-
I know this will not help any current user but I wonder if someone will push a controller board that utilize closed-loop stepper drivers.
I have some experience with leadshine and some other proprietary closed-loop stepper drivers and I really like how they work. They take step/dir/en input and can easily be used with any available control board but it's waste of money to have 5-6 drivers on board that you are not using and just bypassing them to use external drivers. In addition you can't control any of the fancy features (current, type of operation etc).
What I'd love to see is a controller that utilize existing (or new) open source closed loop drivers. For e.g. this one looks good:
https://github.com/makerbase-mks/MKS-SERVO42Bthis one looks less powerful but could be cheaper option:
https://www.ustepper.com/what-is-ustepper/Imagine for example Duet3 board, with duet toolboard's that have MKS-SERVO42B driver or something similar for each axes? Or for example duet3 that have 3 TMC's and 3 MKS-SERVO42B and optional can-fd toolboards with MKS-SERVO42B in addition to existing TMC ones ...
maybe just create toolboard with MKS-SERVO42B ?
-
@arhi said in Layer shift detection?:
maybe just create toolboard with MKS-SERVO42B ?
Potentially it could fit the Duet CAN bus architecture. A small toolboard next to each close loop stepper with 4 wires for power and data. Silicon is getting more capable and less expensive.
-
Yes, could probbly be another can-fd tool in the chain. Question is more about support. Whatever driver is chosen it would have to be integrated with RRF so that current and other settings can be set trough g-code like tmc is configured now. I'd like to see then a DUET3LITE that has no integrated drivers, just a can master and some IO (heaters, extruder encoder and STEP/DIR/ENABLE for the 6 onboard drivers that exist now)
-
I might be thinking of a different printer, but their higher-end machines use a laser profilometer for in-process inspection. Detecting a 'dislocation' would likely be possible this way.
https://markforged.com/blog/in-process-inspection-improving-3d-printed-parts/
EDIT: Not to hijack this thread, but I just came across their patent application (pending) for the technology I linked
https://patents.google.com/patent/US20190009472A1/en?assignee=markforged&oq=markforged&page=3
-
@mrehorstdmd said in Layer shift detection?:
@zapta A closed loop motor/system wouldn't be able correct for all errors. If a print warps and stands up and blocks the nozzle, a closed loop system is going to try to force the nozzle to the correct position. That could cause problems.
I think a closed loop stepper is best used in a system where an object has to move to a target location, like maybe a pick and place machine, as opposed to something that is moving continuously along a specific path.
Sorry but this is so much misinformation.
I can´t help but disagree with that. The print head (with a servomotor) will always try to reach the position given by the microcontroller, and as long as the printhead is held up it will stay there, and as soon as the dictated direction changes and the print head can "slip by" it will go to the new correct location.
Also, all servos can throw out an alarm when there is a specified lag behind the commanded position. I have configured my JMC servo to throw an error if either a specified Amp draw is reached (in my case 9A) or it lags at least 200 steps behind the commanded position. It will throw an alarm and stop, and wait for a reboot.
You can connect the alarm to a free endstop and configure that as an E-stop.I have long said that steppers are long overdue for being phased out, with servos coming down in price so drastically.
Just take this for example, this is the servo i`m using.It´s a 180W nema 23 size servomotor with an included onboard driverboard.
It costs 106 € including shipping (70 without, for when buying multiple)
Now, considering that a good quality stepper already costs 40€ plus the stepper driver (I dont know how much, maybe 10-20€ for the chip?) which equals to 50-60€, you begin to question the reason behind steppers, apart from "it´s always been steppers".
Just some of the benefits:- Closed loop
- Automatic e-stop when an alarm is detected, within microseconds, not at the end of the layer and without homing
- You only need to route power, step and direction to the servo, which means you can share power lines.
- You won´t get als much electrical interference due to inductance like with steppers. Which means you can run thermocouple lines closer to the rest.
- They can rev much higher than steppers, the nema 23 can do 3000 rpm with full torque up to 2000 rpm.
- They have a very smooth motion profile from the start, no 256-interpolation necessary. You can configure them with up to 160.000 steps per revolution if you wish. Not necessary though, i run mine with 5000 steps per rev.
- Dramatically lower power consumption, the servo only consumes power when you accelerate it or turn a load.
Steppers always consume the specified amperage x voltage. - You can configure the servos to deliver more power for a shorter period of time (duty cycle). They are rated for example for 180W at 100% duty cycle. You can run them at 540W, or 300% for a duty cycle of 10% Which means normally 1 minute running at 300%, then 9 minutes cooling off at reduced load.
- (added) They are DEAD SILENT. Not a whisper coming from them, even going at 400mm/s or accelerating at 5g. No stealthchop necessary.
I could list some more, but i think that is enough for now.
Also, you can get the nema 17 version for 62€.
I have long asked dc42 why he focuses so much on integrated stepper drivers.
A cheaper board with no stepper drivers and only the pinouts for external drivers would be a real seller.
I am so happy with my nema23 servos, my next printer will have all axes equipped with it.
The servo is so powerful, it can accelerate my 5kg gantry with 5g (~50.000 mm/s²) if i want it to, and not a single skipped step in sight.I think it´s a shame that the industry is moving towards linear servomotors already, and we can´t even adapt normal rotational servomotors yet.
-
@NitroFreak said in Layer shift detection?:
I have long asked dc42 why he focuses so much on integrated stepper drivers.
A cheaper board with no stepper drivers and only the pinouts for external drivers would be a real seller.
I am so happy with my nema23 servos, my next printer will have all axes equipped with it.
The servo is so powerful, it can accelerate my 5kg gantry with 5g (~50.000 mm/s²) if i want it to, and not a single skipped step in sight.I think it´s a shame that the industry is moving towards linear servomotors already, and we can´t even adapt normal rotational servomotors yet.
I've had tons of discussions with people using servos who have never used an integrated stepper driver before. What they don't realize is that these integrated drivers already work close to how a closed loop system would, because they, pardon my Chinese, adjust the control parameters on the fly based on the back EMF and they are darn good at it. So good at it, that it's creepy.
You are right about servos, but integrated drivers have a place and are the cozy future. I'm impressed what they can do on my printer with Nema17. I think dc42 didn't think most people would try slapping multiple 10kg gantries onto them, and I think most people don't.
