> Juha did all of the mechanical engineering
The V-wheel and MakerSlide are designed By Bart Dring; the design and the need for underside wheels is just a copy-paste from his.
Good points on the instructions, much appreciated. Thank you! I will update those when I get back to the office. (I'm currently out, will be back on Friday, although there are some issues accumulated...) Also, some new plates will be done based on your feedback.
> It might be best to attach the luer lock AFTER completely assembling the pnp head.
On the other hand, installing it requires some force, and it is difficult to do that if the tube is in place.
> Is it a bad idea to use the 24awg pair that shares a shield for the limit switches?
Yes, I think this would lead to noise issues.
Mawa already commented on the need for reset if limit switch triggers. Those are my views as well.
so far so good...
-
- Posts: 198
- Joined: Thu Jul 16, 2015 12:18 am
- Location: Washington State, USA
Re: so far so good...
I don't understand.mawa wrote: Well the TinyG keeps track of all positions and when you hit any limit these positions are invalid and any continuation is impossible.
In the minimum direction the limit switch is the homing switch, so exactly the opposite is true: hitting the limit switch is when you are MOST certain about the position!
In the maximum direction you just need to make sure that the limit switch triggers before anything goes mechanically wrong (like parts smashing into other parts).
Regardless, requiring a re-homing would be a much better solution than requiring the user physically press the reset button on the TinyG, then disconnect/reconnect to it from the software (which sometimes crashes the software, which then requires quitting and restarting the software....). Not everybody has both their keyboard and TinyG reset button within arm's reach from a single location.
- Adam
Re: so far so good...
If a limit switch triggers in normal operation, the machine is not even near where it think it is, so I think some kind of exception procedure should be done. Even though it knows the position at the switch, some of the previous operations were done way out where those should have been.
Currently TinyG goes into alarm state, and needs a reset to get out; that is not easy to change.
Btw, it is a good idea to have an safety switch in a moving machine! I have a big red button connected to the TinyG reset, and I'm glad I do. I think an actual power cutting switch is required in some countries/states?
Currently TinyG goes into alarm state, and needs a reset to get out; that is not easy to change.
Btw, it is a good idea to have an safety switch in a moving machine! I have a big red button connected to the TinyG reset, and I'm glad I do. I think an actual power cutting switch is required in some countries/states?
Re: so far so good...
TinyG uses the limit switches in different modes.
During homing cycle, they serve as a reference for setting zero - determining exact position of the gantry or head.
Once homing is done, TinyG uses it's own system of reference - X,Y,Z,A coordinates. And as the machine size is known, the host should never move the machine outside the safe boundaries. This means, not going negative on any of the axis and not going beyond the maximum size either.
So limit switches must never be tripped. If they are, that definetley is an exception as the machine is obviously not where TinyG assumes it should be.
Simply put: switch during homing = reference, switch during normal operation = fatal error
Btw, I have suggested two features which could reduce user error - enforcing homing if position is not known for sure (just powered up, motor power cut, TinyG communication lost) and limiting Z-travel to safe limits as well:
https://github.com/jkuusama/LitePlacer-ver2/issues/8
https://github.com/jkuusama/LitePlacer-ver2/issues/3
During homing cycle, they serve as a reference for setting zero - determining exact position of the gantry or head.
Once homing is done, TinyG uses it's own system of reference - X,Y,Z,A coordinates. And as the machine size is known, the host should never move the machine outside the safe boundaries. This means, not going negative on any of the axis and not going beyond the maximum size either.
So limit switches must never be tripped. If they are, that definetley is an exception as the machine is obviously not where TinyG assumes it should be.
Simply put: switch during homing = reference, switch during normal operation = fatal error
Btw, I have suggested two features which could reduce user error - enforcing homing if position is not known for sure (just powered up, motor power cut, TinyG communication lost) and limiting Z-travel to safe limits as well:
https://github.com/jkuusama/LitePlacer-ver2/issues/8
https://github.com/jkuusama/LitePlacer-ver2/issues/3
Re: so far so good...
Well, I am not sure about other countries but if you are in Europe and use the machine professionally (or even have employees who use it), a safety switch which cuts power to the machine is definetely required by law. If you take the regulation seriously, a circuit breaking switch is not even enough but you have to use a combination of redundant relais and control circuitry which fulfills a lot of additional safety functions. See EN ISO 13850 for details.JuKu wrote:Btw, it is a good idea to have an safety switch in a moving machine! I have a big red button connected to the TinyG reset, and I'm glad I do. I think an actual power cutting switch is required in some countries/states?
I have installed both a reset switch for TinyG (quite handy as TinyG is mounted at the back side of the machine) and a kill switch which cuts power to all lines that supply moving parts (emergency stop) but leaves my computer and screens alive.
-
- Posts: 198
- Joined: Thu Jul 16, 2015 12:18 am
- Location: Washington State, USA
Re: so far so good...
I think these two changes are a great idea, and would likely eliminate all of the non-homing limit-switch-triggering situations I've run into.mrandt wrote: Btw, I have suggested two features which could reduce user error - enforcing homing if position is not known for sure (just powered up, motor power cut, TinyG communication lost) and limiting Z-travel to safe limits as well:
I suggest it would also be wise to use the max limit switches to detect the machine size (but only once during calibration, not on every startup) to avoid user confusion/error.
Ah, I see. Something about this just seems so.... I don't know... so open loop to me. This is definitely not my area of expertise, and I'm probably wrong about this, but it just seems wrong to assume that the motors are that accurate over long periods of time. Even if they really are that accurate, they're designed for moving, not measuring. It seems like you'd want some sort of separate mechanism for accurately detecting the actual motion resulting from a request for motion. Like a potentiometer built into the motor (I think this is called a servo?). Since we have cameras there are other possibilities too, like a laser line or dot shined onto the work surface, or a Vernier pattern printed on the table. But I've spent very little of my life thinking about these things and people who've dedicated their careers to CNC and robotics haven't gone this route, so there's probably a darn good reason for itmrandt wrote: Once homing is done, TinyG uses it's own system of reference - X,Y,Z,A coordinates. And as the machine size is known, the host should never move the machine outside the safe boundaries.
- Adam
Re: so far so good...
They really are that accurate. They are stepper motors, and if you drive them within spec, they don't lose steps. Instead of a linear motor, think it as programmable tooth gear mechanism.
Re: so far so good...
Hi everyone,
I thought I'd post some info on my build....
I've previously built 3d printers and also converted a Sieg X1 mill to CNC using HobbyCNC and CNC Fusion, so I have some basic experience. However, this is an iterative trial & error project.
Assembling the mechanical parts took one long day. Soldering test harnesses & testing stuff took another day.
As power supply a choose an old school configuration:
If all motors/coils are on concurrently, current consumption would be 5.7 Amp (X:2A, Y:2A, Z:1.2A, A:0,5A as per stepper motor specs) but according to the TinyG wiki, this would never be the case.
From the 3d printer world I would say that it is all about smooth movement, so I'm definitively not going to use unbraided UTP/STP Cat5/6. Based on the current ratings I've ordered some shielded cable:
And for the for the limit switches I'm going to use 2/4/8*0,14 mm2 phone chord cables.
As controller box connectors I use 4-pin "aero"/"microphone" connectors. They are 0.90€ per m/f pair at Reichelt.
https://www.reichelt.de/Microphone-Conn ... rtnr=B+604
And a D-Sub 37 for the limit switches etc.
The cable chain's radius is IMHO way to big to get smooth movement and I suspect that dragging the chain behind a force gauge would produce a rather nice saw-toothed chart. Whether it has an impact on functionality, I don't know, but I'm currently checking whether I could fit the cables and a 4 mm air PVC tube inside a 10x15 R10 chain... Other option would be to have all harnesses hanging from some construction 50 cm above the machine.
http://www.igus.com/wpck/3812/designing ... ation?C=US
http://www.instructables.com/id/Selecti ... /?ALLSTEPS
Todos:
Br,
Christian
I thought I'd post some info on my build....
I've previously built 3d printers and also converted a Sieg X1 mill to CNC using HobbyCNC and CNC Fusion, so I have some basic experience. However, this is an iterative trial & error project.
Assembling the mechanical parts took one long day. Soldering test harnesses & testing stuff took another day.
As power supply a choose an old school configuration:
- 160VA 17V/9A toroid 19€
- 15A bridge rectifier 1€
- 56000uF/40V capacitor 16€
- 2K5W bleed resistor 1€
- fuses on both primary and secondary side 1€
- el cheapo Chinese current shunt & ditto LED display 9€
If all motors/coils are on concurrently, current consumption would be 5.7 Amp (X:2A, Y:2A, Z:1.2A, A:0,5A as per stepper motor specs) but according to the TinyG wiki, this would never be the case.
From the 3d printer world I would say that it is all about smooth movement, so I'm definitively not going to use unbraided UTP/STP Cat5/6. Based on the current ratings I've ordered some shielded cable:
- LAPP 4 * 1mm² for the X and Y axis each
- LAPP 8 * 0,75mm² for the Z and A axis
And for the for the limit switches I'm going to use 2/4/8*0,14 mm2 phone chord cables.
As controller box connectors I use 4-pin "aero"/"microphone" connectors. They are 0.90€ per m/f pair at Reichelt.
https://www.reichelt.de/Microphone-Conn ... rtnr=B+604
And a D-Sub 37 for the limit switches etc.
The cable chain's radius is IMHO way to big to get smooth movement and I suspect that dragging the chain behind a force gauge would produce a rather nice saw-toothed chart. Whether it has an impact on functionality, I don't know, but I'm currently checking whether I could fit the cables and a 4 mm air PVC tube inside a 10x15 R10 chain... Other option would be to have all harnesses hanging from some construction 50 cm above the machine.
http://www.igus.com/wpck/3812/designing ... ation?C=US
http://www.instructables.com/id/Selecti ... /?ALLSTEPS
Todos:
- there is way too much wobbling on the Y-axis that need to be fixed
- replace the cameras as per Malte's suggestion
- vacuum vessel
- further testing and verifying functionality
- Install everything on (and under) a 40 mm laminated MFD table
Br,
Christian
Re: so far so good...
Hi Christian - welcome to this forumkvide wrote:Hi everyone,
I thought I'd post some info on my build....
Thank you for posting your experience so far!
Judging by the links to suppliers you posted I guess you are also located in Germany or a neighbouring country?
You are rather fast I would saykvide wrote:Assembling the mechanical parts took one long day. Soldering test harnesses & testing stuff took another day.
I am sure this will work - probably even more stable than a cheap switching PSU.kvide wrote:As power supply a choose an old school configuration [...]
As an an additional benefit you might get a nice humming 50hz sound when you switch on your machine - depending on the quality of the toroid
I would argue that. For PnP it is all about positional accuracy - i.e. not loosing steps; given the open loop control. Contrary to 3D printing, smoothness of linear movement is not that critical.kvide wrote:From the 3d printer world I would say that it is all about smooth movement [...]
In 3D printing you are constantly extruding material, so any change in speed (even small variation) leads to over- or underextrusion in that particular spot.
For PnP, you "only" have to accurately position the machine in a specific spot for pickup or placement of a component.
Of course, less friction makes it easier to not lose steps as motors will need less torque - but even with the kit setup with Nema17 steppers you have quite a bit of power to spare.[/quote]
I agree to that. I appreciate that RJ45 plugs and ready-made cables might make cabling LitePlacer easier, especially if you have nice PCBs (the "hat" and "backpack") with mating connectors. However none of the patch cables I have seen so far are made to be moving constantly... I would recommend to get properly rated cables.kvide wrote:so I'm definitively not going to use unbraided UTP/STP Cat5/6.
If money is a concern, Pollin in Germany often has proper cables for cheap:
http://www.pollin.de/shop/dt/MDM3NzM0OT ... hwarz.html
Interesting. I would be concerned with the PVC mantle. All cables I know which are rated for constant movement and small bending radius have PUR mantles... But the small diameter is definetely a pro.kvide wrote:Actually, I found and also ordered a rather interesting alternative; Tasker TAS-C8075 for the Z&A axis and TAS-C4100 for the X&Y axis. This cable is only rated for 49V, which makes the insulation thinner as well as the overall diameter smaller than "regular" 300V hi-flex cables.
Don't forget USB for the camera (and maybe future controllers)! Either use another 4x 0.15 (or larger diameter) shielded cable or, if you want to save yourself some soldering work, get a good USB extension cable.
After a testing a lot of trash cables I found these to work nicely:
http://www.amazon.de/gp/product/B00008A92G
While these cables are probably not intended for constant movement, they are shielded properly and have low enough resistance to properly supply and interface common devices even with a 3 or 5m long cable.
I also think that USB failure will be pretty easy to recognize and debug - stepper problems (like missing steps) because of internally damaged cables are much harder to pin down...
I don't have Juha's drag chain so I cannot comment on that - but I doubt that dragging the chain will cause issues. The saw-toothed force chart probably applies to any drag chain but as I pointed out in the beginning, it does not matter for PnP as long as steppers have sufficient torque to overcome the friction.kvide wrote:The cable chain's radius is IMHO way to big to get smooth movement and I suspect that dragging the chain behind a force gauge would produce a rather nice saw-toothed chart. Whether it has an impact on functionality, I don't know, but I'm currently checking whether I could fit the cables and a 4 mm air PVC tube inside a 10x15 R10 chain... Other option would be to have all harnesses hanging from some construction 50 cm above the machine.
There is also a tradeoff between cramming too many cables + tube into a small chain and thus making cable damage more likely vs. using larger and heavier chains.
If I built my LitePlacer again, I would go for a much wider drag chain for the Y-axis to make my life easier and extend the life of the cables at the same time. You can mount the Y-chain inverted (one end at the back of the machine, bend at front) so it properly rests on the table surface.
For X-axis I would try to avoid a chain dangling in the air and try Adam's mod instead. Depending on Z-axis motor this might require modifications to the X-carriage front end back plate though
See discussion here:
http://liteplacer.com/phpBB/viewtopic.p ... lit=flying
Are you planning to add support to the maker slides or what do you mean?kvide wrote:there is way too much wobbling on the Y-axis that need to be fixed
I guess you found some info about the cheap but good Logitech C270 for the upwards camera.kvide wrote:replace the cameras as per Malte's suggestion
I published a 3D printable mount for it's barebones here:
http://malte-randt.de/improved-3d-print ... era-mount/
That mount nicely fits a hexagonal LED light, gerbers can also be found on my blod - I also have a few spares left. Let me know if you want a set:
http://malte-randt.de/hexagonal-led-light/
For the down camera I switched to "Andonstar Digital Microscope V160" originally recommended by thereza:
http://www.andonstar.com/e_products/dig ... 160-2.html
It is available from eBay for about EUR 60.
Make sure to get this version with 2MP CMOS cam, not it's predecessor which only has 0.3MP crap sensor.
To mount the cam to LitePlacer, the best option I found is using a 12mm linear rod mount.
Misumi part SHSTA12-15 even fits the original camera location:
http://de.misumi-ec.com/vona2/detail/11 ... SHSTA12-15
The camera has LED light which might be sufficient. I still made a LED ring light for it which I have not had time to document yet. Will post something about it at some point.
There was a lot of discussion about "pneumatic capacitors" - i.e. some sort of reservoir like a steel bottle. While my pneumatic system is totally overengineered, I would still recommend something like that.kvide wrote:vacuum vessel
As a word of caution: Glueing standard ESD mattes to the table surface is an expensive and terrible mess. Mine is slowly but surely delamitating and causes trouble due to it's surface not being level.kvide wrote:Install everything on (and under) a 40 mm laminated MFD table
I will replace my table top with a new MDF to which I will permanently bond a thin sheet (0.5 or 0.8mm) of magnetic stainless steel (EN 1.4301).
I hope to get several advantages from that:
- ESD safe
- perfectly level
- durable and easy to clean
- magnetic; so I can easily attach tools like 3D printed board holders, component feeders, etc. with small neodym magnets
I limit myself to 0603 and am currently more keen on finer pitch IC and BGA - but I guess accuracy is good enough for 0402 passives if you go slow; especially as these tiny parts self-align during reflow.kvide wrote:Eventually I hope this machine will be able to pick & place 0402s and rapid prototype boards for some new RF ideas in the 2-9 GHz range.
Have fun and please keep us posted about your progress!
Best regards
Malte
-
- Posts: 198
- Joined: Thu Jul 16, 2015 12:18 am
- Location: Washington State, USA
Re: so far so good...
Hi Kvide,
Would you care to elaborate on why this:
Personally for the Z axis I've tried both the cheapest Cat5 STP on Amazon and excellent quality high-end Igus Chainflex PUR-jacketed shielded cable with a stress liner, and at $zvm=2000 with $zjm=800 there was no difference in smoothness of movement. Any higher jerk on the A/Z-axes is a bit pointless since you'll just send parts flying off the head, and the axis itself doesn't have enough travel for a maximum speed above 2000 to make any meaningful difference in placement times. I'm still using the Chainflex for the X axis.
Is there some sort of experiment you can suggest to demonstrate the need for beefy cable on tiny motors like this? Some sort of "torture test" (within the reasonable duties of the Z axis, of course) that would demonstrate in a very obvious and repeatable way the shortcomings of the Cat5 STP wiring?
Would you care to elaborate on why this:
... implies this ...kvide wrote: I would say that it is all about smooth movement
... for the small motors on the Z&A axes? Specifically for STP Cat5 which is shielded cable and always twisted (there is no such thing as "untwisted shielded twisted pair"). I certainly agree that Unshielded UTP is a bad idea, and I also certainly agree that Cat5 is not big enough for the X+Y axes.kvide wrote: so I'm definitively not going to use unbraided UTP/STP Cat5/6.
Personally for the Z axis I've tried both the cheapest Cat5 STP on Amazon and excellent quality high-end Igus Chainflex PUR-jacketed shielded cable with a stress liner, and at $zvm=2000 with $zjm=800 there was no difference in smoothness of movement. Any higher jerk on the A/Z-axes is a bit pointless since you'll just send parts flying off the head, and the axis itself doesn't have enough travel for a maximum speed above 2000 to make any meaningful difference in placement times. I'm still using the Chainflex for the X axis.
Is there some sort of experiment you can suggest to demonstrate the need for beefy cable on tiny motors like this? Some sort of "torture test" (within the reasonable duties of the Z axis, of course) that would demonstrate in a very obvious and repeatable way the shortcomings of the Cat5 STP wiring?
These are nice, and widely available; I'm switching my X motor over to use them.kvide wrote: As controller box connectors I use 4-pin "aero"/"microphone" connectors. They are 0.90€ per m/f pair at Reichelt.
Yes, I'm doing this, and it works -- but just barely. Photos are here; the small dragchain is a 10x15 and I just removed the old dragchain night before last. I mounted the tail end of the dragchain about 30mm higher in the air to get a slightly larger bend radius too. The 10x15 has in it:kvide wrote: The cable chain's radius is IMHO way to big to get smooth movement and I suspect that dragging the chain behind a force gauge would produce a rather nice saw-toothed chart. Whether it has an impact on functionality, I don't know, but I'm currently checking whether I could fit the cables and a 4 mm air PVC tube inside a 10x15 R10 chain...
- [li]- one Cat5-STP for Z+A motors[/li]
[li]- one USB cable for all the data except the daisy-chained limit switch wire[/li]
[li]- one 6mm OD vacuum hose (upgraded to Tygon tubing, it's worth it)[/li]
[li]- a 14-conductor unshielded ribbon cable to carry the odball +24v (solenoid), +16v (LEDs), +12v (more LEDs), and +5v (ADC) power supplies to the head unit[/li]
- Adam