Cameras
-
For my desires a dedicated Pi would work really great, but I can see why you would want it all in one. I was just adding another viewpoint into the convo in case you/someone else hadn't of thought of it like I have.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
ITs not the cost, its the adding a header into the SPI circuit which may degrade the speed achievable even if nothing is plugged in. The UART would not be an issue from that perspective, however it would be rather slow.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
ITs not the cost, its the adding a header into the SPI circuit which may degrade the speed achievable even if nothing is plugged in. The UART would not be an issue from that perspective, however it would be rather slow.
Yes, I know about the length/speed relationship on SPI - I've done board/firmware design with SPI in the past. That's why I asked about the second SPI block on the ESP chip, and whether it was available. If it is not, then I'd suggest i2c.
-
The second SPI block on the ESP8266 is used to read the code from the flash memory chip. So it's not free, and although I understand that it can be shared, adding 1m or so of cable to it would not be a good idea (and adding a camera to my delta would need more than 1m of cable to the electronics).
I2C is also intended for very short distances. It relies on pullup resistors, so adding more than a small amount of capacitance on the bus degrades its maximum speed.
So UART is the most practical option. The highest resolution supported by the Adafruit camera is 640x480. So I took one of my photos of my delta printer looking down on the effector and resampled it to 640x480. The file size was then 100Kbytes. If we can use 115200 baud (the maximum supported by the Adafruit camera) without dropping characters - which isn't necessarily the case - then it will take about 10 seconds to upload an image, if the camera uses about the same Jpeg quality/compression compromise.
A 640x480 image is actually rather large to fit in the existing slot in DWC, so an miage with lower resolution might be acceptable.
-
While i get the intent to make a self contained solution, I think video might be a step too far. If the ESP can server SPI video well if there is a spare SPI port then how about using a second ESP for the video?
-
While i get the intent to make a self contained solution, I think video might be a step too far. If the ESP can server SPI video well if there is a spare SPI port then how about using a second ESP for the video?
Which brings us back to this solution http://johan.kanflo.com/building-a-low-cost-wifi-camera/ that Tim linked to in his original post.
-
yes, that would work - but effectively we are making an IP cam. I suppose we can add a bit if we allow trigger via UART so we could get good timelapse recording.
-
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.
