Cameras
-
I don't think a second ESP is a good solution, that's buying more hardware when you have a perfectly good ESP sitting there doing very little during a print.
It seems as though with resistor pull ups, you can have 200pF of cable capacitance on I2C. That'd be around 15 feet with this cable, for instance:
https://www.wireandcabletogo.com/uploads/file/bel9841.pdf
I've done both SPI and I2C over the types of distances we're talking here (a meter or so). While I agree the high speed SPI would likely be affected, a slower bus should be fine. I think interfering with the UART isn't a good idea, since that makes it harder to do ESP firmware updates.
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
-
Hmm, I hope I don't come across as rude, but why would a 3D printer need a built-in camera? Seems like too many systems tacked onto the wrong hardware. I've found that any PC with a webcam works well, and is more versatile. I only see drawbacks to trying to add a webcam to the 3d printer controller.
-
Lots of reasons - time-lapse, remote monitoring, etc. It is a really popular feature, otherwise Octoprint wouldn't have it.
Why tie up a PC, and spend the energy running the PC, when there's hardware on the controller that is sitting nearly idle?
What is the drawback to adding a webcam to a 3D print controller, exactly? Its maybe 5 cents to add a header to the board, free to do the routing, and even if Tony/David don't want to spent time writing code for now, at least it can be added later.
-
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
Which ones would you want on a header?
-
I understand the use of a camera, but it is nearly entirely separate from the other functions of the control board. The web interface is not publicly exposed, so it doesn't really make sense.
I'm all for adding features to a controller board, but I fear that some people are losing sight of the important aspects: reliability, accuracy, fundamental features of a motion control system. A webcam serves no purpose whatsoever. Why does a webcam need to be tied into the system that controls stepper motors? It doesn't, and shouldn't be.
-
I have some sympathy with bot's view. A streaming remote view of the printer might have some value, and I can already get that from the £20 wireless IP camera that I purchased recently. But I don't think a static image refreshed every few seconds adds much to the web interface.
We're getting very close to the point at which we need to freeze the hardware design. Any changes we make at this point should be for the sole purpose of addressing issues that arise during the beta test phase. That said, I am not against adding a 5V pin to the ESP comms header, or adding the 3 spare ESP GPIO pins to that header if there is room for them.
-
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
Which ones would you want on a header?
Any that are unused, for future proofing - at least enough for i2c. All the SAM's pins are used/brought out to either do things or sit on an expansion header, so why not do the same on the ESP?
@bot:
I understand the use of a camera, but it is nearly entirely separate from the other functions of the control board. The web interface is not publicly exposed, so it doesn't really make sense.
The web interface can be publicly exposed if you forward the port on your router, but even if you don't do that, being able to watch the print from within the LAN is useful. Personally my printers are in a closet (in the same room as me), with a closed door for noise reasons. Having a video stream lets me watch for print failures easily while sitting at my desk. I can even bring it up on a laptop if I walk to another room to work.
@bot:
I'm all for adding features to a controller board, but I fear that some people are losing sight of the important aspects: reliability, accuracy, fundamental features of a motion control system.
No one is losing sight of anything, all I'm suggesting is that the pins are brought out to a header so at least it can be developed later if people need it. Things are very close to a hardware design lock, at that point there's no more "oh I wish for xyz". At least by bringing the pins to a header it can be developed in software at a later time. It would take about 5 minutes in KiCAD, that isn't a significant diversion in resources.
@bot:
A webcam serves no purpose whatsoever. Why does a webcam need to be tied into the system that controls stepper motors? It doesn't, and shouldn't be.
I have outlined my personal use for a webcam above, but if nothing else having webcam functionality will be an attractive feature on the Duet Wifi to help it stand out further amongst its competitors. In my opinion there is no reason not to do it, the hardware is sitting there nearly idle otherwise. It doesn't take away from the stepper motor control, since that's all handled on the SAM.
-
Your use of the webcam indicates no reason it should be tied into the controller board. Yeah, I use webcams too for my printers, but I do not need the image of that camera to be processed by the tiny controller board running a very sensitive process.
If it's a matter of adding some trivial changes, okay, fine. If you ask me, these kinds of things (including wifi itself) should be specifically left OFF the board, to prevent potential unforeseen problems.
Also, exposing the web interface publicly (at this point) would be amazingly stupid, unless you don't care about your house burning down or you can trust everyone who may come near your wireless network with 100% certainty.
-
Why should someone have to buy more hardware when there's a perfectly good ESP8266 sitting on the board not doing anything else during the print besides updating a handful of numbers, none of which are time sensitive? I'm not sure I understand your argument, since the ESP is totally separate from the motion control system - they just happen to be on the same PCB. You could drill a hole through the ESP8266 mid print and the Duet would happily print away.
If you don't want to use a camera with the Duet Wifi, no harm no foul. If the header isn't there, then no one can use it ever. Additionally, all the pins of the SAM are brought out, why not do the same for the ESP chip - they could be used for something other than a camera even. All I'm suggesting is to bring the pins out for now, worry about the rest later if it ends up being desired/feasible.
How would someone burn your house down with access to your printer? If the printer is powered up you should be on the premises, and your maxtemp settings should be such that no fire can be auto ignited - otherwise you're just a typo away from "burning your house down". I think Duet Web Control has password protection anyway?
I believe I saw elsewhere you use Teamviewer for your prints - are you aware of the security issues they've had?
-
The ESP8266 is the only means to control the printer if you do not have a paneldue, it is simply not worth compromising (any further) for sub-par camera functionality, when better functionality is already built-in.
You already have to buy a camera, so your point of additional hardware is moot.
You can change all the firmware settings, which IIRC, include max temperatures and the like. I could set the e3d to melt down, could I not?
Thanks for the heads-up about teamviewer. It is still worlds more secure than simply exposing the duet web server to public ports.
-
You both have valid points but ultimately different goals. I think that adding a few extra pins off the ESP for elmoret's uses would be a decent idea if there is board space. They want to use it locally and not compromise the "all in one" solution that the duet is. Bot's points about everything are also valid, but you two seem to have different uses/view points and those who share common ground with the both of you can go their respective ways. I tend to agree with bot but I'm sure a few extra pin headers won't cause either of us much trouble.
-
When in doubt, break out the pins. An unpopulated through-hole would be fine for now I think. Just break out ANYTHING you might ever consider using. Nobody's ever been upset that the board had a few extra pins broken out. Particularly with an ESP8266, which people LOVE to hack on. It's a no-brainer to include the capability for future feature development, even if not for cameras.
David has strong authorial control of the main fork and is sensitive to both performance and security – I don't think any major degradation due to feature bloat (like we've seen in Marlin) is likely here.
-
@bot:
The ESP8266 is the only means to control the printer if you do not have a paneldue, it is simply not worth compromising (any further) for sub-par camera functionality, when better functionality is already built-in.
I still don't understand what the compromise is so far, or what the compromise would be to add a header for possible further development? What is the downside here? For reference, the ESP8266 alone has more horsepower than the Duet 0.8.5's main CPU.
@bot:
You already have to buy a camera, so your point of additional hardware is moot.
To clarify: It would be the difference between a ~$5 camera module and a ~$50 IP camera.
@bot:
You can change all the firmware settings, which IIRC, include max temperatures and the like. I could set the e3d to melt down, could I not?
I would say there's a greater chance of a FET failing on than someone having into your 3D printer. One would have to:
1.) Figure out an IP and port that had a 3D printer on the other end. There are ~4 billion IPv4 addresses out there, plus the ports.
2.) Figure out a way to hack through DWC's password protection.
3.) Figure out how to change the maxtemp setting in config.g
4.) Hope that the end user has left their printer powered on, left the house, and isn't using the default heater cartridge - a 30w E3D heater cartridge can't get hot enough to melt the heater block or auto ignite any commonly used polymers.If you deem that to be a likelihood worth losing sleep over, I assume you have no furnace or air conditioning in your home, as there are 7200 HVAC related fires reported per year.
-
Getting back on topic, after doing some research it seems there are 3 options for cameras:
1.) SPI. Difficult because it would have to share with either the ESP's flash chip, or the data link between ESP and SAM processors. Would be fastest, 30fps at good resolutions would be possible.
2.) I2C. I can't find any cameras that use pure I2C - the OVxxxx series seems to use I2C for configuration, but an extra 8-10 pins for data transfer.
3.) UART. Slow. Like 1hz best case scenario slow. Would have to be shared with the firmware update functionality.
The other problem is that there's not a whole lot of room around the ESP8266 at the moment. It might be possible to break out 6 pins or so with a small (1mm pitch) header. Even if they aren't ever used for a camera, there's no reason not to bring unused pins out to a header where possible.
-
So do you think that adding camera functionality is trivial? There is no chance that this will interfere (with the already interfered) method of controlling the printer?
As you may have become aware, I already have a huge problem with the fact that the web interface is only accessible through wifi. I feel this is a huge step backwards in terms of reliability, security, and best practices. I'm willing to forgive it. I'm not willing to forgive the addition of unneeded hardware functionality. Why not add a displayport? Some USB ports? A RAID controller? Because none of these things are essential for OPERATING A 3D PRINTER, the only thing this controller board should do.
Every day that goes by, I realise that the new Duet is drifting further from being a viable industrial motion controller, and closer to being a gimmick-packed piece of electronics for consumer-junk toy printers.
And what, to save $15 or $30? You want to compromise (potentially) a lot of reliability to save $15 and make things slightly more convenient (for you). Weird.
-
@bot:
So do you think that adding camera functionality is trivial? There is no chance that this will interfere (with the already interfered) method of controlling the printer?
I never said adding camera functionality was trivial, I said adding a header for future expansion was trivial. I say this as someone that has written code for cameras and other sensors on similar platforms, so I'm not just making this up.
@bot:
As you may have become aware, I already have a huge problem with the fact that the web interface is only accessible through wifi. I feel this is a huge step backwards in terms of reliability, security, and best practices.
I don't understand this perspective either. My 2D printer is connected via wifi, and it has had exactly 0 problems in the 4 years I've owned it. I use it daily.
@bot:
I'm willing to forgive it. I'm not willing to forgive the addition of unneeded hardware functionality. Why not add a displayport? Some USB ports? A RAID controller? Because none of these things are essential for OPERATING A 3D PRINTER, the only thing this controller board should do.
Because a display port, USB ports, and RAID controllers aren't sitting unused on nearly idle chips. Do you also have a problem with all of the pins of the SAM (including two SPI buses) being brought out to the expansion header? How is it any different to bring out the pins of the ESP8266?
@bot:
Every day that goes by, I realise that the new Duet is drifting further from being a viable industrial motion controller, and closer to being a gimmick-packed piece of electronics for consumer-junk toy printers.
As someone that has designed and used $50k motion platforms I disagree.
@bot:
And what, to save $15 or $30? You want to compromise (potentially) a lot of reliability to save $15 and make things slightly more convenient (for you). Weird.
How would reliability be compromised? Even if the potential camera code is incredibly buggy, you could just leave it disabled via config.g, and it would be as though it never existed.
Plus this isn't about me, it is something lots of folks are interested in judging by Octoprint discussions - camera functionality was one of the first features implemented.
Out of curiosity, are you a beta tester and/or pre order customer?
-
You use so many logical fallacies in your defense that I can't spend too much time here.
If you cite octoprint as an example of the success of your ideology, then I'd ask you to look into the thousands of user reports of problems setting it up, without even a webcam. Then look into the problems added on top trying to use the odd types of cameras you are talking about. The best success seems to be had from typical USB cameras.
Just because you CAN do something doesn't mean you should. Have the creators of the duet not already stated there are potential performance issues just by exposing the pins? Did I misread the beginning of the thread?
I am a pre-order customer. I am a 0.8.5 user. I was going to pre-order two borads, but held off on one in hopes of a wired ethernet version happening. Hopefully a split-off would allow the cameras, wifi, and other consumer nonsense to remain on the wifi stream, while others can get a more stripped-down "essentials" version that has all of the performance benefits of the "wifi" version, but without the wifi.
-
I have added an item to the list of production hardware changes for consideration, to add additional pins to the current 3-pin ESP_SERIAL header to break out the spare ESP8266 pins.
-
@bot:
If you cite octoprint as an example of the success of your ideology, then I'd ask you to look into the thousands of user reports of problems setting it up, without even a webcam. Then look into the problems added on top trying to use the odd types of cameras you are talking about. The best success seems to be had from typical USB cameras.
I cited Octoprint as an example of the demand for cameras.
Thousands? That seems a bit hyperbolic. Anyway I can find lots of folks having trouble setting up the 0.8.5, does that mean its a bad board? Same for iPhone, or really any other electronic device more complicated than a toaster. It just means that folks have questions when doing something they've never done before.
@bot:
Just because you CAN do something doesn't mean you should. Have the creators of the duet not already stated there are potential performance issues just by exposing the pins? Did I misread the beginning of the thread?
There are potential issues exposing the high speed SPI pins. I'm not asking for those. So again, what exactly is being compromised by simply bringing some otherwise unused signals out to a header?
Anyway, I'm sorry for causing such a fuss about this.
