Cameras
-
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.
